Async communication mastery — writing for distributed teams.

01Why most async fails

The common pattern: someone sends "hey can you help me with X" in Slack, waits for a response, gets one, asks a clarifying question, waits again. Two hours pass to communicate what could have been one paragraph. They blame async; what failed was the writing.

Async works when each message contains enough context that the recipient can act on it. It fails when messages assume the recipient will follow up to fill in gaps. The discipline is front-loading context, not minimizing message length.

02Context-first messages

Bad async message:

hey, can you take a look at the deploy failure?

Recipient has to ask: which deploy? which service? what's the error? when did it happen? Six message round-trips later, they have the info they needed to start.

Deploy of user-service v2.4.1 failed at 14:32 UTC.

CI log: https://ci.example.com/run/abc123
Error: "connection timeout to database"

I tried:
- Re-running the deploy (same error)
- Checking the DB dashboard — looks healthy

I'm blocked until this deploys. Can you take a look,
or should I roll back to v2.4.0?

(I'll be at lunch 1-2pm UTC, otherwise online today)

Same request. The good version gives the recipient: what's failing, where to look, what's been tried, what's blocked, what the decision options are, when you're available. They can act immediately.

The template: situation, context, what you tried, what you need, availability. Five sentences, usually.

03Threads, channels, DMs — where to write

Choose the right surface for the message:

• Public channel: default for almost everything. Searchable later. Other people learn from the conversation. Avoids siloing.
• Thread on a channel message: for follow-up discussion on a specific topic. Keeps the main channel readable.
• DM: personal, sensitive, or genuinely 1:1. Avoid for technical discussion — it disappears into private silos.
• Long-form doc: for anything you'd expect to be referenced again. Decisions, designs, plans.

The single highest-leverage move: default to public channels. The "I'll just DM them quick" instinct buries knowledge that the rest of the team needs.

04Decision documents — the highest-leverage artifact

When a decision matters — architectural choice, hiring rubric, project go/no-go — write a decision document. Five sections, half a page each:

# Decision: [Short title]

**Status:** Proposed / Decided / Reversed
**Author:** [name]
**Date:** [YYYY-MM-DD]
**Stakeholders:** [people who need to weigh in]

## Context
[What's the situation? Why is this decision needed now?]

## Options
1. [Option A] — what it is, pros/cons
2. [Option B] — what it is, pros/cons
3. [Option C] — what it is, pros/cons

## Decision
[Which option, and why]

## Consequences
[What changes, what we're trading off,
what we're committing to]

Decision docs aren't just for big decisions. Anytime a discussion has gone on for more than a day, write the doc. The act of writing forces clarity. The doc becomes the record. Future you, six months later, will need it.

05Meetings that should be async

Most recurring meetings are async-shaped problems that have ossified into calendar invitations. The question to ask of every meeting: could a written document replace this?

Meetings that should be async:

• Status updates. Daily standups, weekly check-ins. Written updates take 5 minutes; meetings take 30 minutes per person.
• Information broadcasts. "Here's what's happening with the project." If only one person is talking, write it down instead.
• Read-only review meetings. A senior wants to look over a junior's work. Async with comments is better than a live walkthrough.

Meetings that should stay live:

• Brainstorming with multiple participants contributing. Live energy beats turn-taking in async.
• Hard interpersonal conversations. Voice and body language matter when the topic is sensitive.
• Real-time pair programming on a hard problem. The interactive loop matters.
• Incident response. Time-critical, multi-party coordination.

06The async standup format

Replace daily standups with a written daily update in a team channel. Each engineer posts:

**Yesterday:** finished the payment retry logic, deployed to staging
**Today:** writing tests for the retry edge cases
**Blockers:** none right now

(notes anything someone else should know about — e.g., breaking changes, decisions made yesterday)

Three minutes to write. Anyone can scan the channel in two minutes to know what the team is doing. Blockers get picked up async or in a follow-up. No one has to be online at the same time.

The format matters less than the consistency. Pick one and stick with it.

07Loom and async video — for what's hard to write

Sometimes writing is the wrong medium:

• Walking someone through a UI
• Showing a bug visually
• Demoing a feature
• Explaining a concept that's easier shown than described

Async video (Loom, recording in Zoom, screen recording with voiceover) fills this gap. 5-minute video, watched at 2x speed by 8 teammates across time zones, replaces an hour-long meeting that some of them couldn't have attended anyway.

Rule: video is best when there's a visual. If you're just talking, write it instead. Audio-only async is the worst of both worlds — slower to consume than text, harder to skim, not searchable.

08Response time expectations

Async only works if everyone agrees on the response time bar. Without explicit agreement, people fill the gap with anxiety — "did they see my message?"

Reasonable defaults:

• Slack DM/mention: same business day, typically within 4 hours
• Public channel mention: same business day, lower urgency
• Email: 24 business hours
• Long-form doc comments: 2-3 business days
• Urgent / blocking work: escalate to phone/SMS/page — not buried in Slack

Important corollary: if it's truly urgent, don't async it. Call, page, escalate. Async is for non-blocking work. Treating everything as urgent destroys async culture.

09Writing for the searcher in 6 months

Most async communication is read once and forgotten. But the few that get searched later determine whether your team has institutional memory or rediscovers the same answer monthly.

Habits that help future searchers:

• Use specific keywords in messages. "We decided to go with Postgres over MySQL because [reasons]" beats "we picked one of them."
• Include the question, not just the answer. "Why did we choose Postgres? Because..." is searchable; "We chose Postgres because..." isn't.
• Pin or archive important decisions. Slack threads disappear. Notion docs, GitHub READMEs, or pinned posts survive.
• Link decisions back to discussions. When a doc summarizes a discussion, link to the original conversation. Future readers want both the conclusion and the context.

10Anti-patterns to recognize

"Quick question..." If it's quick, just ask. The preamble adds nothing and trains people to dread your messages.

Send a Slack message, then a follow-up, then a third message. Each gives the recipient a fresh notification. Compose one complete message instead.

Voice memos in chat. Forces everyone else to listen at your pace. Not searchable, not scannable. Use only when video adds clear value.

Async messages that demand immediate response. "@channel can someone help" at 11pm. The opposite of async culture. If it's that urgent, page someone.

Meetings without docs. If you're going to meet, write the agenda first. The meeting becomes a discussion of the doc, not an unstructured ramble.

∞The compound

Async communication is a skill that compounds over a career. Engineers who write well at distance become the people who can lead distributed teams, write the design docs that get adopted, and contribute across organizations. Engineers who can't are increasingly limited to in-person contexts.

Practice the patterns. Front-load context. Write decision docs. Replace meetings with documents. The investment is small, the dividend is enormous — and the teams who do this well outpace the teams who don't, especially as work continues distributing across geography and time.