💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction — For Everyone Whose Calendar Looks Like Tetris

How many days a week do you answer "meetings" when asked what you did today? The GitLab async work handbook and Basecamp's Shape Up have been cited as the classic answers to this problem for years, and "reduce meetings" threads keep climbing back onto the front pages of GeekNews and Hacker News. There are two reasons this debate reheated in 2026.

First, the ubiquity of AI coding agents. With workflows where you hand multi-hour autonomous tasks to a tool like Claude Code now routine, the engineer's bottleneck has moved from "time spent writing code" to "time to think without interruption." The thirty minutes of focus needed to design a good instruction for an agent has never been more valuable — yet calendars remain shredded into thirty-minute fragments. Second, with remote and timezone-distributed teams now standard, the cost of "everyone gathers at the same time" has grown structurally.

This post is not a declaration that meetings are bad. Some decisions are overwhelmingly faster in a meeting. The point is to allocate sync and async **with explicit criteria** — and to turn the transition into a playbook a team can execute in four weeks.

The Cost of Meeting Overload — Start with Arithmetic

Persuasion starts with numbers. Let us compute an ordinary weekly meeting load for an 8-person team.

Weekly meeting cost (8-person team)

Daily standup: 15 min x 5 days x 8 people = 10.0 person-hours

Weekly planning: 60 min x 1 x 8 people = 8.0 person-hours

Sprint review: 60 min x biweekly(0.5) x 8 = 4.0 person-hours

1:1s (manager): 30 min x 7 reports x 2 people = 7.0 person-hours

"Sync" meetings: 30 min x ~6 per week x 4 ppl = 12.0 person-hours

----------------------------------------------------------------

Total: 41 person-hours per week

Hidden costs on top:

- Context switching: ~15 min prep/recovery around each meeting

-> add attendees x 0.25 hours per meeting

- 41 person-hours + ~15 person-hours switching = 56 per week

Available team hours: 8 people x 40 hours = 320 person-hours

-> 17.5 percent of all time goes to meetings and their overhead

-> equivalent to paying 17.5 percent of total payroll for meetings

Two things matter in this arithmetic. First, **meeting cost explodes with attendee count, not duration**. A 30-minute meeting with 8 people costs 4 person-hours; replacing it with one written document (1 hour to write) plus individual reading (10 minutes x 8) costs 2.3 person-hours. Second, the hidden tax of context switching. A 30-minute meeting at 2:30 p.m. does not cost 30 minutes — counting the dead zone starting at 1:50 ("no point starting anything big, meeting soon"), it kills over an hour. This is exactly why, on days when your calendar is riddled with holes, you go home feeling "busy all day, got nothing done."

Sync vs. Async — A Decision Matrix

The goal is not abolishing all meetings. You need criteria.

| Situation | Recommended mode | Why |

| --- | --- | --- |

| Information sharing (status, announcements) | Async | Few questions; the record matters |

| Simple QA | Async | A searchable record should remain |

| Complex design decision (many alternatives) | Doc first, meeting to close | Converge in writing, decide in person |

| Conflicting interests, negotiation | Sync | Needs nuance and real-time adjustment |

| Early brainstorm divergence | Async first | Avoids groupthink; includes introverts |

| Incident response, urgent issues | Sync | Cost of delay dominates |

| Feedback (sensitive, personal) | Sync | Tone evaporates in text; high misread risk |

| Onboarding, relationship building | Sync | Trust forms on high-bandwidth channels |

Compressed into one sentence: **schedule a meeting only when the issue needs three or more conversational round-trips AND the cost of delay is high.** Few round-trips means writing is faster; low delay cost means the archival value of async wins. To borrow GitLab handbook language, async is the "slower but deeper, leaves a record" mode, and sync is the "faster but evaporates" mode. Route to sync only the things that are allowed to evaporate.

The Async Transition Playbook

1. Standups in Writing — The Template

The first button to press: least resistance, fastest payoff. Replace the daily synchronous 15-minutes-times-everyone with a Slack thread or issue comment.

Daily async standup template (post by 10:00)

Yesterday: Merged PR 1042 (order API pagination).

Quarantined 1 flaky test in the deploy pipeline.

Today: Implement retry logic for the order event consumer.

Address design doc v2 review comments in the afternoon.

Blocked: Need staging DB permissions — @infra-team (ticket INFRA-301)

Focus: 14:00-17:00 deep work block (slow replies, thanks)

Three operating rules. First, the "Blocked" item must carry **a mention and a ticket number**. Unblocking is the entire reason standups exist, and it is the first thing to get buried when you switch to writing. Second, the manager commits to **reacting to blocked items within 2 hours** (without this commitment, the belief that "nobody reads written standups" collapses the practice within a month). Third, the "Focus" item has each person declare their unavailable hours for the day in advance — by design, the standup doubles as a deep work protection mechanism.

2. Decisions in Documents — RFCs with Comment Deadlines

For issues that need a decision, write a short decision document (RFC) instead of calling a meeting. The crucial ingredient is the **comment deadline**.

Decision doc: Should we move order search to OpenSearch?

Status: Collecting comments (deadline: Friday June 19, 17:00)

Decider: Youngju Kim | Advisors: A (search), B (infra), C (PM)

Proposal (3 sentences)

Move order search from PostgreSQL LIKE queries to OpenSearch.

Rationale: search p95 is 4.1s; monthly search volume growing

22 percent. Cost: 3 weeks setup + higher monthly infra cost

(estimate in appendix).

Alternatives compared

(table: keep current / pg_trgm index / OpenSearch)

Comment rules

- To object: use the format "objection + evidence + alternative"

- No comments by the deadline = treated as agreement

- Within 24h after the deadline, the decider records the

conclusion in this document

Where this format beats a meeting: every participant can think deeply on their own schedule, the conclusion and its rationale are archived automatically, and "wait, did we actually decide that?" arguments disappear. One requirement: **name exactly one decider.** Async discussion without a decider becomes an infinite comment loop. If there is no convergence by the deadline, then book a 30-minute meeting — making the meeting an escalation path rather than the default.

3. Recordings + Timestamps

Whatever must happen synchronously (customer meetings, design debates) gets recorded — and shared with a timestamp index, always.

Design debate recording (47 min total)

Just want the conclusion: start at 41:20, 5 minutes

- 00:00 Problem framing (current search latency)

- 08:15 Alternative 1: pg_trgm review and limits

- 19:40 Alternative 2: OpenSearch cost debate <- key segment

- 33:05 Migration risks

- 41:20 Conclusion and action items

"I uploaded the recording" is not async. Demanding people watch 47 minutes is worse than attending the meeting. The timestamp index plus one "just want the conclusion" line is what turns a recording into a genuine async asset.

When You Do Meet, Meet Well

Meetings that cannot go async should get denser. Four rules.

1. **No agenda, no attenda**: codify "invitations without an agenda are politely declined" in the team norms. Sample decline: "Happy to join if you add the goal and agenda to the invite. If it can be resolved in writing, I will reply in a thread." Awkward for two weeks; then the agenda culture sticks.

2. **Attendee diet**: only people required for the decision are mandatory; everyone else is optional plus minutes. People invited "just in case" are half of all meeting cost.

3. **Designate a notetaker**: assign at the start, publish to the shared channel immediately at the end. A meeting without notes exists in as many versions as there are attendees' memories.

4. **Enforce an action item format**: an action item without "who, what, by when" is not an action item.

Action item format at the bottom of minutes

|---------|-------------------------------------|-------|-----------|

| Youngju | OpenSearch cost estimate doc | 6/16 | DOC-88 |

| A | Share pg_trgm benchmark results | 6/17 | PERF-12 |

| B | Set up staging cluster | 6/19 | INFRA-305 |

Designing Deep Work Blocks — Defending the Calendar

The goal of the async transition is not fewer meetings per se, but **unbroken chunks of time**. As Cal Newport laid out in Deep Work, cognitively demanding work requires contiguous blocks of two-plus hours, not a pile of 30-minute fragments.

Personal defense techniques:

1. **Put deep work blocks on the calendar first**: e.g., three times a week, 9:30 to 12:00, fixed. An empty calendar gets invaded. Occupy it before the meeting requests arrive.

2. **Give blocks concrete names**: "Design event consumer retries" survives invasion far better than "Focus time." A vague block is treated as a movable block.

3. **Turn Slack off during blocks**: set a status like "deep work, replies after 14:00." With the response SLA agreement below in place, there is no guilt involved.

Team-level norms are even stronger:

1. **Core focus blocks**: agree on team-wide windows like "no meetings on Tuesday and Thursday mornings." A block the team set together is invaded far less than blocks individuals defend alone.

2. **Declare meeting-eligible windows**: the inverse approach — restrict meetings to, say, Mon/Wed/Fri 13:00-17:00. When meetings cluster, deep work time clusters too.

3. **Beware the no-meeting-day trap**: declare all of Wednesday meeting-free and Tuesday and Thursday often become meeting hell — the balloon effect. Without a total cap (max meeting hours per week), a no-meeting day is just redistribution.

Notification Hygiene — Agreeing on Response SLAs

Meetings are not deep work's only enemy. The research by Gloria Mark (UC Irvine) showing one interruption costs roughly 23 minutes of refocusing is famous. Two layers: personal settings and team agreements.

Personal settings:

1. **Split channels into 3 tiers**: immediate alerts (incidents, direct mentions) / checked 3 times a day (team channels) / weekly sweep (company announcements, banter). Use Slack sidebar sections to make the split physical.

2. **Minimal keyword alerts**: your name and the systems you own, nothing more. Broad keywords like "deploy" are the gateway to notification hell.

3. **Batch your checking**: do not read messages in real time; process them in batches at fixed times like 10:00, 13:00, 16:00.

For these personal settings to work guilt-free, the team needs a **response SLA agreement**.

| Channel | Expected response time | Use for |

| --- | --- | --- |

| Phone, pager | Immediate | Production incidents only |

| Slack mention | Within 4 hours | Things needing an answer today |

| Slack general message | Within 24 hours | Ordinary discussion, questions |

| Issue, doc comments | Within 48 hours | Things needing deep review |

| Email | Within 72 hours | External, formal communication |

The power of this table is that channel choice becomes a declaration of urgency. The complaint "I Slacked you three hours ago, why no reply?" exists because no SLA exists. With the agreement in place, "posting in a 24-hour channel and then nagging after three hours" becomes the norm violation. If it is truly urgent, call — and because calling carries a real psychological cost, people reserve it for things that are truly urgent.

The Timezone-Distributed Team Scenario

If your team spans Seoul, Berlin, and San Francisco, async is not a choice — it is physics. Overlap is at most one or two hours a day. Operating principles for this case:

1. **Overlap hours are sync-only golden time**: spending that one hour on information sharing (which works async) is waste. Reserve it exclusively for work that genuinely requires synchrony — negotiation, sensitive feedback, relationship building.

2. **Document the handoff**: leave a handoff note at end of day — "state of things + what the next person picks up + what is blocked" — and the timezone gap becomes a relay. A well-run distributed team gets 24-hour development; a poorly run one gets a 24-hour delay on every decision. The difference is a single documentation discipline.

3. **Share the meeting-time pain**: never let the same region always absorb the 6 a.m. calls. Rotate quarterly, or make attendance itself optional via recording plus timestamps.

Resistance and Responses — The Case to Make to Managers

The biggest barrier to the async transition is not tooling, it is anxiety. Typical objections and the counter-case:

**"I will lose visibility into what the team is doing" (manager)** — the truth is the opposite. Spoken standups evaporate; written standups become a searchable timeline. What is visible in meetings is presentation skill; what is visible in documents is actual output. The pitch to the manager: "Let us pilot for four weeks and measure together whether unblocking speed and output tracking improve."

**"The culture will get cold" (team members)** — a valid concern. Asyncify everything and small talk and bonding disappear. The response is deliberately preserved sync time: one agenda-free team coffee chat per week and one offsite per quarter, explicitly marked "exempt from the async transition." The purpose of going async is reducing coordination costs to leave more energy for relationships.

**"Urgent things will get slow"** — the SLA table is the answer. The emergency channel (pager) becomes clearer, not weaker. In an environment where everything was urgent, true urgency was getting buried.

The 4-Week Transition Plan

Big-bang transitions fail. A week-by-week incremental plan:

1. **Week 1 — Measure**: change nothing; only measure. Total weekly meeting person-hours for the team, and the count of contiguous free blocks of 2-plus hours per calendar. These numbers are your baseline and your persuasion material.

2. **Week 2 — Asyncify the standup**: switch the daily standup to the written template. Keep one synchronous standup per week (say, Monday) to soften the sense of rupture. Start the manager's 2-hour reaction commitment at the same time.

3. **Week 3 — Meeting norms + SLA**: adopt mandatory agendas, the action item format, and the response SLA table as a written team norm. Audit every recurring meeting and classify: send to async / cut to biweekly / keep.

4. **Week 4 — Deep work blocks + retro**: introduce the team core focus blocks, re-measure the week 1 metrics, and compare. In the retro, honestly collect the things that got slower when moved to async, and move them back to sync — reverting is not failure, it is calibration.

The Tool Stack — Separating Channel Roles

The async transition is a norms problem, not a tooling problem — but when tool roles blur, the norms stop holding. The key is settling, once, "which kind of information lives where."

| --- | --- | --- | --- |

The most frequently violated rule in this table is the first row. The moment a decision gets made in Slack, it evaporates into the scrollback within two weeks. Make this team norm number one: "discussion in Slack is fine; conclusions must be moved to a document or issue." The person who moves it is the person who made the call — without that assignment of responsibility, nobody moves anything.

Automating the Standup Reminder — Code Example

The number one failure mode of async standups is forgetting. Do not rely on human memory; automate. Slack Workflow Builder works, but if you need customization, GitHub Actions does it in a few lines.

.github/workflows/standup-reminder.yml

name: Async standup reminder

on:

schedule:

- cron: '30 0 * * 1-5' # weekdays 09:30 KST (00:30 UTC)

jobs:

remind:

runs-on: ubuntu-latest

steps:

- name: Post reminder to Slack

run: |

curl -X POST "$SLACK_WEBHOOK_URL" \

-H 'Content-Type: application/json' \

-d '{

"text": "Standup thread. Post yesterday/today/blocked/focus by 10:00.",

"channel": "#team-standup"

env:

SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

One step further: attach a small aggregation script that tracks whether the manager reacted to blocker items within two hours.

// scripts/standup-stats.ts — weekly standup statistics

// Read threads via the Slack API and aggregate blocker response times

type BlockerStat = {

author: string

postedAt: Date

firstReplyAt: Date | null

}

function summarize(stats: BlockerStat[]) {

const replied = stats.filter((s) => s.firstReplyAt !== null)

const within2h = replied.filter(

(s) =>

s.firstReplyAt!.getTime() - s.postedAt.getTime() <= 2 * 3600 * 1000

)

console.log(`Blocker items: ${stats.length}`)

console.log(`Reply rate: ${((replied.length / stats.length) * 100).toFixed(0)}%`)

console.log(`Replied within 2h: ${within2h.length}/${stats.length}`)

}

Pipe these numbers into the weekly retro automatically, and the vague anxiety of "is the async standup actually working?" becomes a measurable operational metric.

What Happens to 1:1s and Manager Routines

The area to handle most carefully in an async transition is the 1:1. The short answer: a hybrid — **keep the 1:1 synchronous, but prepare its content asynchronously** — is closest to correct.

1. **A shared agenda document**: keep a shared doc where both sides add agenda items before each 1:1. The 1:1s that end with "nothing in particular to discuss" happen because no agenda doc exists.

2. **Banish status updates from the 1:1**: progress reporting is already handled by the async standup. Reserve the 30 minutes for things that are hard to do in writing — career, feedback, worries. Paradoxically, the better your async transition goes, the better your 1:1s get.

3. **Adjust frequency by agreement**: shifting from weekly 30 minutes to biweekly 45 is fine, but it must be an agreement, not an announcement. The moment a reduced 1:1 cadence feels like neglect, trust collapses.

Case Study — A 4-Week Transition Log from an 8-Person Team

For concreteness, here is the 4-week log of a fictional (but typical) 8-person backend team applying the playbook above.

Metric changes by week (8-person team)

Metric Week 1 (base) Week 4 Change

Weekly meeting person-hours 41 26 -37%

Focus blocks (per person/wk) 2.1 5.4 +157%

Median time-to-unblock 9.5 hours 6.0 hrs -37%

Decision lead time 5.2 days 3.1 days -40%

"Uninterrupted time" survey 2.4/5 3.9/5 +1.5

It was not all smooth. In week 2 came the complaint that "nobody reacts to the written standups" (resolved by the manager's 2-hour reaction commitment). In week 3, one senior engineer turned every topic into a document and the team drowned in comments — the inverse failure (resolved by adding a threshold: "only issues worth 2-plus person-hours get a decision doc"). In the week 4 retro the team moved two things back to sync: sprint planning (estimation debates were slower in writing) and onboarding pairing for new hires. Again: reverting is not failure, it is calibration.

Frequently Asked Questions

**Q. We are B2B and customers demand "a call right now."** Keep the external interface synchronous and asyncify only the inside. A customer-response rotation — "today's sync person" absorbs external interrupts while everyone else keeps their deep work — is the realistic structure.

**Q. Will juniors get neglected in an async environment?** The most valid worry of all. Apply shorter response SLAs for juniors (mentions: 1 hour) and keep a daily synchronous check-in for the first month of onboarding. Async is the default, not the totality.

**Q. Leadership reads fewer meetings as "going soft."** Speak with the numbers from the metrics section. The decision lead time data in particular builds the frame "async = a faster organization." The counter-evidence to softness is not vibes — it is lead time.

Antipatterns — Beware Async Maximalism

For balance, the new pathologies the async transition creates:

1. **Async maximalism**: trying to handle conflict mediation or sensitive feedback in writing almost always makes things worse. Text carries no tone, and misunderstandings amplify asynchronously. Adopt the "three round-trips rule": when a comment thread crosses three heated round-trips, switch to a call immediately.

2. **The document graveyard**: when unread decision docs and stale handbooks pile up, "did you read the doc?" becomes the new blame-shifting. The discipline of pruning documents is harder than the discipline of writing them. Hold a cleanup day each quarter to archive stale documents.

3. **Exploiting response latitude**: when "well, we are async" becomes an indulgence for procrastination. The SLA is a ceiling, not a target — if a 4-hour SLA degrades into "let every mention sit for 4 hours," team velocity dies.

4. **Unequal writing burden**: async culture favors fast writers. For non-native speakers and juniors it can be a barrier to entry. Templates and an explicit policy welcoming AI writing assistance are practical mitigations.

The Tone of Async Writing — How Not to Sound Cold

The most common complaint about async culture is "messages feel cold." Text carries no facial expression or intonation, so the warmth that flows naturally in a synchronous conversation must be added back deliberately. The cost is nearly zero.

1. **Attach one line of context to requests**: "please review this PR" lands differently from "this needs to make the Friday deploy — could you review this PR?" Same request, very different pressure.

2. **State intent with negative feedback**: a written "this approach has problems" reads twice as cold as the same words in person. One intent-marking line — "I think there might be a better way, so here is a suggestion" — defuses defensive reactions.

3. **Emoji are the facial expressions of async**: the notion that emoji are unserious in work messages is a liability in async environments. A single acknowledgment reaction removes the anxiety of being left on read.

4. **Questions instead of assumptions**: when a message is ambiguous, ask "I read this as meaning X — is that right?" before interpreting it badly. Most async conflict comes from filling ambiguity with assumed malice.

The Weekly Calendar Audit — A 15-Minute Routine

As a way to start measuring without building a grand dashboard, I recommend a 15-minute calendar audit on Friday afternoons.

1. Open this week's calendar and mark each meeting one of three ways: "was necessary / writing would have sufficed / did not need to attend."

2. Sum the person-hours of the "writing would have sufficed" meetings — that is next week's reclamation target.

3. For any recurring meeting marked "writing would have sufficed" two weeks in a row, propose an async conversion to the organizer.

One person can start alone, and four weeks of records become the data that persuades the whole team.

Metrics — Numbers, Not Vibes

Metrics to judge whether the transition is working. All trackable with a calendar API or a spreadsheet:

1. **Weekly meeting person-hours**: sum of meeting duration x attendees across the team. Target: down 30 percent within 4 weeks.

2. **Focus block count**: contiguous free blocks of 2-plus hours per person per week. Target: 5 or more each.

3. **Time to unblock**: median time from a "Blocked" item appearing in a standup to its resolution. It must not get worse after the transition — if it does, the transition is misconfigured.

4. **Decision lead time**: time from decision doc publication to recorded conclusion. Compare against the old "wait until the next meeting" pattern.

5. **A subjective metric**: one quarterly survey question — "I had enough uninterrupted time to do my work (1-5)."

Applying This in a Hybrid Office Environment

If your team is not fully remote but hybrid — in the office two or three days a week — async norms become more important, not less. When collaboration style flip-flops between co-located days and remote days, the culture inevitably regresses to "decisions get made by whoever is in the office."

1. **Decisions go to documents regardless of location**: conclusions reached in office hallway chat must still be moved into a decision doc or issue. The moment "the person who was not there that day" becomes an information second-class citizen, hybrid has failed.

2. **Make office days sync-concentration days**: pack the high-bandwidth activities — 1:1s, pairing, whiteboard debates — into the days you gather anyway, and design home days as deep-work-only. If people commute in just to sit on separate Zoom calls, the commute is pointless.

3. **The remote-participant-first meeting rule**: if even one person is remote, everyone joins from their own laptop — "one remote, all remote." It eliminates the asymmetry in audio quality and speaking opportunities.

Checklists

Personal:

1. Are 3 or more deep work blocks on your calendar this week

2. Are your Slack channels split into 3 tiers (immediate / 3x daily / weekly)

3. Do you batch message checking at fixed times

4. Have you declined an agenda-less meeting invitation yet

5. Have you tried the Friday calendar audit

6. Do you attach one line of context to your requests

Team:

1. Does the standup template include Blocked and Focus items

2. Is there a manager commitment on reaction time for blockers

3. Is a response SLA table agreed upon in writing

4. Do decision docs name a decider and a comment deadline

5. Do shared recordings carry a timestamp index

6. Is sync-only time (coffee chats, offsites) explicitly preserved

7. Are meeting person-hours and focus block counts being measured

8. Is the three round-trips rule (writing to call) agreed upon

9. If hybrid, is the one remote, all remote rule in place

10. Is a handoff note format agreed upon

Closing

Cutting meetings in half is not the goal; it is a byproduct. The real goal is reclaiming the team's most expensive resource — unbroken thinking time. In an era where AI agents write the code, the differentiated value of a human engineer is deep design and good judgment, and neither comes out of 30-minute fragments.

If you pick just one smallest first step for this week: calculate your team's weekly meeting person-hours and walk into the next retro with a single number. "We spend 41 person-hours a week in meetings — what if we experimentally move 10 of them to writing?" Change starts with that one sentence.

And remember: async is a tool, not an ideology. The right ratio for your team can only be found through experiment and measurement — and starting that experiment requires not a company-wide mandate, but a single written standup next Monday.

References

- GitLab Handbook — Asynchronous Work: https://about.gitlab.com/company/culture/all-remote/asynchronous/

- Basecamp — Shape Up: https://basecamp.com/shapeup

- 37signals — The company handbook: https://basecamp.com/handbook

- Cal Newport — Deep Work (official page): https://calnewport.com/deep-work-rules-for-focused-success-in-a-distracted-world/

- Gloria Mark (UC Irvine) — context switching research: https://www.ics.uci.edu/~gmark/

- Paul Graham — Maker Schedule, Manager Schedule: https://www.paulgraham.com/makersschedule.html

- GitLab Handbook — Communication and meetings guide: https://handbook.gitlab.com/handbook/communication/

- Shopify Engineering — calendar purge coverage: https://www.bloomberg.com/news/articles/2023-01-03/shopify-is-canceling-all-meetings-with-more-than-two-people

- Doist — asynchronous communication guide: https://blog.doist.com/asynchronous-communication/

- Atlassian Team Playbook — meeting and collaboration plays: https://www.atlassian.com/team-playbook

- GeekNews — async collaboration discussions: https://news.hada.io/

- Hacker News — meeting culture discussions: https://news.ycombinator.com/