Async First

The default in most companies is synchronous communication. Got a question? Tap someone on the shoulder. Need alignment? Schedule a meeting. Want an update? Send a Slack message and wait for an immediate reply. This default is wrong. It does not scale, it fragments everyone's attention, and it penalizes deep work.

Async-first means the opposite: write it down instead of scheduling a meeting. Post your question in a channel instead of DMing someone. Do not expect a response for hours, not minutes. Escalate to synchronous only when async has failed or when the situation genuinely requires real-time interaction.

This is not about eliminating meetings or being anti-social. It is about choosing the right communication mode for the task and defaulting to the one that respects everyone's time.

Why Meetings Do Not Scale

A 30-minute meeting with 6 people costs 3 person-hours. But the real cost is worse than that. Each person had their flow interrupted, which means the cost includes context-switch time on both sides of the meeting. A realistic estimate is 4-5 person-hours of productivity lost for a 30-minute meeting.

Meeting cost calculation:
- 6 people x 30 minutes = 3 person-hours (direct)
- 6 people x 15 minutes context-switch = 1.5 person-hours (hidden)
- Total: ~4.5 person-hours for a 30-minute meeting

If that meeting could have been a document:
- 1 person x 30 minutes to write = 0.5 person-hours
- 5 people x 5 minutes to read = 0.4 person-hours
- Total: ~0.9 person-hours

The document is 5x cheaper. And it produces an artifact that can be referenced later, shared with people who were not in the room, and searched. A meeting produces nothing unless someone writes notes, and those notes are always incomplete.

Meetings also create a coordination problem. Finding a 30-minute slot where 6 people are free often means the meeting happens 3 days from now. The async version happens immediately.

When Async Works

Async is the right default for most communication. It works especially well for:

Status updates:          Write a summary, post it, people read when they can
Decisions with context:  Write an RFC or proposal, collect feedback over days
Code reviews:            Asynchronous by design
Questions:               Post in a channel, answer comes when someone is free
Announcements:           Written once, read by many on their own schedule
Feedback:                Thoughtful written feedback is better than improvised verbal feedback

Async communication is inherently more thoughtful. Writing forces you to organize your thinking. You cannot ramble in writing the way you can in a meeting. The act of writing often clarifies the question enough that you answer it yourself before posting.

When Sync Is Better

Some situations genuinely need synchronous communication. Recognizing these prevents the failure mode of forcing everything into async and making people miserable.

High-emotion conversations:    Feedback, conflict resolution, difficult news
Complex negotiations:          Multiple parties with competing interests
Rapid brainstorming:           Ideas building on each other in real time
Urgent incidents:               Production is down, coordinate in a call
Relationship building:          1-on-1s, team bonding, new hire onboarding
Ambiguous problems:             When nobody knows the right question yet

The pattern: use sync when the communication requires rapid back-and-forth, emotional nuance, or relationship context. Use async for everything else.

A good heuristic: if the conversation would take more than 5 back-and-forth messages async, it might be faster synchronous. But most conversations are 1-2 exchanges, not 5.

Writing Async Messages That Work

The failure mode of async communication is vague messages that generate unnecessary back-and-forth. A message like "Hey, can we chat about the API?" forces the recipient to schedule a meeting to find out what the question actually is.

Bad async message:
"Hey, quick question about the deployment."

Good async message:
"I'm deploying the payment service update (PR #847) and I'm not sure
whether we need to run the migration before or after the deploy. The
migration adds a nullable column, so I think it's safe to run before.
Can you confirm, or point me to whoever owns this? No rush, tomorrow
morning is fine."

The good message includes:

• Context (what you are working on)
• The specific question (migration ordering)
• Your current understanding (you think it is safe)
• Who can help (or ask for routing)
• Timeline (tomorrow morning is fine)

The recipient can answer in 30 seconds without a meeting. The bad message would have required a meeting or 4-5 follow-up messages to extract the same information.

Slack Hygiene for Async

Slack (or Teams, or whatever your chat tool is) can be synchronous or asynchronous depending on how you use it. Most teams use it synchronously by default, which turns it into a firehose of interruptions.

Async Slack practices:

- Use channels, not DMs. Channels create shared knowledge. DMs create silos.
- Use threads. A thread keeps a conversation contained instead of flooding
  the channel.
- Set expectations in your status: "Checking messages at 10am and 3pm"
- Do not expect instant replies. If it is urgent, say so explicitly.
- Use reactions to acknowledge without creating noise. A thumbs-up means
  "I saw this" without generating a notification for everyone.
- Disable notifications during focus time. Check messages on your schedule.
- Write complete messages. Do not send "Hey" and wait for a response before
  stating your question.

The "Hey" message deserves special criticism. It is the worst async pattern because it forces synchronous behavior. The sender waits for a response, the recipient responds with "What's up?", and now both people are sitting in Slack having a slow real-time conversation. Just write the whole question in one message.

Building Async Culture

Switching from sync-first to async-first is a cultural change, not a tooling change. It requires explicit norms and leadership modeling.

Norms to establish:

1. Default to writing.
   Before scheduling a meeting, ask: "Could this be a document?"

2. Set response time expectations.
   Most messages: within 4 hours during working hours.
   Urgent messages: within 30 minutes (use @here or similar).
   Everything else: within 24 hours.

3. Meetings need agendas.
   No agenda, no meeting. The agenda forces the organizer to think about
   whether a meeting is actually necessary.

4. Record decisions in writing.
   If a decision happens in a meeting, it does not count until it is
   written down and posted where affected people can see it.

5. Respect focus time.
   Do not schedule meetings during team focus blocks.
   Do not expect responses during someone's focus time.

The hardest part is that managers and senior engineers must model the behavior. If a manager schedules a meeting for something that could be an email, the team learns that meetings are the norm. If a manager writes a clear async proposal and collects feedback in comments, the team learns that writing is the norm.

Documentation as Communication

The most scalable form of async communication is documentation. A well-written document communicates once and serves every future reader. A meeting communicates once and is gone.

Types of async documents:

RFCs / Design docs:     Propose a change, collect feedback
ADRs:                   Record a decision and its reasoning
Runbooks:               How to handle common operational tasks
Onboarding guides:      What a new team member needs to know
Post-mortems:           What went wrong and what we learned
Weekly updates:         What happened this week, written once, read by many

The investment in writing a document pays compound interest. Every person who reads it instead of asking the question in a meeting is time saved. Every future hire who reads the ADR instead of asking "why did we choose Postgres over Mongo?" is institutional knowledge preserved.

Async Across Time Zones

Async-first becomes essential when your team spans time zones. A team in San Francisco and Berlin has about 2 hours of overlap. If you need synchronous meetings for every decision, you are either excluding someone or forcing someone to work at unreasonable hours.

Time zone practices:

- Record every meeting. Not for surveillance, for the people who were asleep.
- Decisions go in writing, not in meetings.
- Handoffs are explicit: "I'm done for the day, here's where I left off,
  here's what needs attention."
- Use async standups (written in Slack at start of each person's day)
  instead of synchronous standups that require everyone online.
- Overlap hours are sacred. Use them for the things that actually need sync.
  Do not waste overlap on status updates.

Common Pitfalls

• Async in name, sync in practice. Saying "we're async-first" while expecting instant Slack replies is worse than just admitting you are sync-first. Expectations must match reality.
• No escalation path. If something is genuinely urgent, there must be a clear way to escalate from async to sync. Without this, people default to sync for everything "just in case."
• Writing walls of text. Async does not mean verbose. A 10-paragraph Slack message is not async communication -- it is a bad document. Keep messages concise. Move long-form thinking to actual documents.
• Losing decisions in chat. A decision made in a Slack thread is invisible to anyone who was not in the thread. Move decisions to a permanent, searchable location.
• Treating all channels the same. Some channels (incidents, on-call) need fast response times. Most channels do not. Make the expectations explicit per channel.

Key Takeaways

• Default to async, escalate to sync. Most communication does not require real-time interaction.
• Meetings are expensive (4-5 person-hours for a 30-minute meeting with 6 people) and produce no artifact. Writing is cheap and permanent.
• Write complete messages with context, a specific ask, and a timeline. Do not make the recipient ask follow-up questions to understand your request.
• Set explicit response time expectations. "Within 4 hours" for normal messages, "within 30 minutes" for urgent ones.
• Use sync for high-emotion conversations, rapid brainstorming, urgent incidents, and relationship building. Use async for everything else.
• Async-first is a cultural change. Leaders must model it. Norms must be explicit and documented.