Async Communication¶

Async communication is the foundation of remote-first work.

When you can't tap someone on the shoulder, you write instead. When teammates are in different time zones, you stop waiting for synchronous responses and start communicating in ways that don't require presence. This isn't a limitation—it's a superpower. Async-first teams move faster because they're not blocked on availability. They make better decisions because ideas are documented, not lost in conversation. They're more inclusive because everyone can participate, regardless of when they work.

But async doesn't happen by accident. It requires intention: clear expectations, good writing habits, and systems that make written communication effective.

What problem this solves¶

Without intentional async communication:

• People in different time zones are second-class citizens.
• Important decisions happen in meetings that not everyone can attend.
• Information lives in people's heads instead of in writing.
• People are constantly blocked waiting for responses.
• Work happens in fits and starts, driven by whoever is online.

Async-first communication creates an equalizer. Everyone has access to the same information. Everyone can participate.

When to use async vs. sync¶

The default should be async. Use sync when:

The rule of thumb: If it can wait 24 hours and be written down, it should be async. If it requires nuance, relationship, or real-time interaction, make it sync.

Roles and ownership¶

Everyone owns async culture. It only works if everyone participates.

Async communication norms¶

1. Write for a stranger¶

Write as if the reader has no context. Because eventually they won't—a future teammate, your future self, or someone on another team.

Include:

• Context: Why does this matter? What's the background?
• Ask: What do you need? What's the decision or action?
• Deadline: When do you need a response?
• References: Links to docs, tickets, or previous discussions.

Good async message:

"We're deciding whether to use Service A or Service B for the new integration (context: [link to RFC]). I've documented pros/cons in [this doc]. I'm leaning toward Service A because of X and Y, but want input from anyone with experience on B.

Could you review the doc and add comments by EOD Thursday? If I don't hear concerns, I'll proceed with Service A on Friday."

Poor async message:

"What do you think about the integration?"

2. Default to long-form¶

Slack is great for quick exchanges. It's terrible for decisions, context, or anything that needs to be referenced later.

Use Slack for:

• Quick questions with quick answers.
• Social communication.
• Synchronous discussion (knowing it's ephemeral).
• Pointers to longer content: "I posted the proposal here: [link]"

Use documents for:

• Proposals and decisions.
• Project updates and status.
• Anything that needs to be findable later.
• Anything complex enough to need structure.

If a Slack thread has more than 5 messages, consider moving it to a document.

3. Respect response time expectations¶

Not everything is urgent. Most things can wait. Set clear expectations:

Never expect instant responses. If it's truly urgent, use the agreed urgent channel (phone, PagerDuty, @here with explanation).

4. Close the loop¶

Every request should have a clear resolution:

• "Decision: we're going with Option A. See notes in [doc]."
• "Thanks, this answered my question."
• "No longer needed—we solved it another way."

Don't leave threads hanging. The asker should know if their request was received, whether it was answered, and what happened.

5. Use status signals¶

Make your availability visible:

• Calendar: Keep it updated with working hours, focus time, PTO.
• Slack status: Use it. 🎧 Focus, 🏖️ OOO, 🌙 Done for the day.
• Working hours: Communicate your schedule to the team.

Let people know when they can expect a response without having to ask.

Writing for async success¶

Structure for scannability¶

People don't read; they scan. Make it easy:

• Headlines and sections: Break up long content.
• Bullets and lists: For multiple items.
• Bold key points: Guide the reader's eye.
• TL;DR at the top: For longer documents.
• Clear ask at the end: What do you need from the reader?

Be explicit about actions¶

Don't bury the ask. Make it obvious:

• "I need a decision by Friday."
• "Please review and approve."
• "FYI, no action needed."
• "Can you answer these questions: 1... 2... 3..."

Provide context without requiring homework¶

Link to background, but summarize the relevant parts. Don't make people read five documents to understand your message.

Anticipate questions¶

Think about what the reader will wonder and answer it proactively. This reduces back-and-forth.

Async decision-making¶

Decisions don't require meetings. Here's an async pattern that works:

1. Propose in writing¶

Create a document with:

• Problem statement.
• Options considered.
• Recommended option with rationale.
• Trade-offs acknowledged.
• Open questions.

Share it with stakeholders: "Please review by [date]."

2. Collect feedback async¶

Stakeholders comment on the document. They can:

• Ask clarifying questions.
• Raise concerns.
• Express support.
• Propose alternatives.

3. Synthesize and decide¶

After the deadline, the decision owner:

• Addresses questions and concerns.
• Updates the proposal if needed.
• Makes the decision.
• Documents it clearly: "Decision: [what] because [why]."

4. Communicate the outcome¶

Share the decision with everyone affected:

• What was decided.
• Why (brief summary).
• What happens next.
• Where to find the full context.

When to escalate to sync: If comments reveal fundamental disagreement or confusion, schedule a short meeting to discuss—then return to async to document the decision.

Async rituals¶

Some rituals work well async:

Async standup¶

Instead of daily sync meetings:

🟢 **Done**: [What you completed since last update]
🔵 **Today**: [What you're working on]
🔴 **Blocked**: [Anything blocking you, or "None"]

Post by a consistent time (e.g., "by 10am your local time"). Team members read and respond to blockers.

Async weekly update¶

For visibility without meetings:

## [Name] Week of [Date]

### Highlights

- [Key accomplishment]
- [Key accomplishment]

### In progress

- [What I'm working on]
- [Expected completion]

### Blockers / Needs attention

- [Anything you need help with]

### Coming up

- [What's next]

Async feedback rounds¶

For decisions, RFCs, design reviews:

• Share the artifact with a clear deadline for feedback.
• Stakeholders comment directly on the document.
• Owner synthesizes and responds to all comments.
• Decision is documented.

See Principles: Decision-Making for more on structured decision-making.

What good looks like¶

A team with strong async practices:

• Decisions are documented. You can find the rationale for past choices.
• Information is accessible. New team members can ramp up by reading.
• Meetings are rare and purposeful. They're for discussion, not information transfer.
• Time zones don't create tiers. Everyone can participate regardless of location.
• Response times are respected. No one expects instant replies; no one waits endlessly.
• People aren't always online. Deep work is protected because async reduces interruptions.

Failure modes and mitigations¶

Copy-pastable artifact: Async communication SLA¶

# [Team Name] Async Communication Expectations

**Last updated:** [Date]

## Response time expectations

| Channel                  | Expected response time                          | When to use                     |
| ------------------------ | ----------------------------------------------- | ------------------------------- |
| Slack DM                 | Within 4 working hours                          | Direct questions, quick asks    |
| Slack team channel       | Within 1 business day                           | General questions, FYI          |
| Slack @here/@channel     | Immediate attention                             | True emergencies only           |
| Document review requests | By stated deadline                              | Proposals, RFCs, decisions      |
| Tickets/PRs              | Per priority; acknowledge within 1 business day | Work requests, code review      |
| Email                    | Within 1 business day                           | External comms, formal requests |

## Guidelines

### For requesters:

- Include context, a clear ask, and a deadline.
- Choose the right channel for the urgency level.
- Don't use @here unless it's actually urgent.
- Follow up if you don't get a response within the expected time.

### For responders:

- Acknowledge receipt even if you can't answer immediately.
- Close the loop—don't leave threads hanging.
- If you need more time, say so.
- Use status to signal availability.

## Working hours

We respect that team members have different schedules and time zones.

- Don't expect responses outside working hours.
- Urgent after-hours issues: [method—e.g., PagerDuty, phone].
- Use scheduled send for non-urgent messages outside recipient's hours.

## When to go sync

Move to a meeting if:

- The topic is sensitive (feedback, conflict).
- A thread exceeds 5+ back-and-forths without resolution.
- Rapid brainstorming would be more effective.
- Relationship-building is the goal.

After sync: document decisions and share with those who couldn't attend.

Related pages¶

• Working Agreements — Where async norms live.
• Meeting Standards — When you do need sync.
• Cadence — How async fits into your rhythm.
• Principles: Decision-Making — Making decisions async.
• Rituals — Async versions of team ceremonies.