Async is the default, not the apology
Distributed teams stall when every question needs a live answer, or when "ASAP" ignores whose night it is. Async communication is not silence. It is a contract: complete written requests, predictable response windows, and meetings reserved for decisions that actually need voices in the same hour.
This guide covers when to write vs meet, a status format people finish on a phone, response SLAs that survive real jobs, and how to split channels from calendar blocks. Timezone habits and handoffs live in timezone collaboration without chaos. Fair scheduling math: find fair meeting times across timezones.
Decision tree: write, meet, or wait
| If the need is… | Default | Live meeting only when… |
|---|---|---|
| Information someone can read later | Written update or doc comment | Never, unless they cannot access the artifact |
| Approval between two clear options | Written brief with A/B and recommendation | Options are genuinely ambiguous after writing |
| Unblock with one owner | Blocker update with verify steps | Pairing is faster than another round of screenshots |
| Alignment across three regions | Relay + handoff | Overlap is thick and the exit criterion needs voices |
| Status for its own sake | End-of-day note | Cancel the recurring sync |
When in doubt, write first. A ten-line message now beats five partial answers over three days. If writing exposes that nobody knows the next move, fix the action before you book thirty minutes.
Status format that gets read
People forgive slow days. They stop trusting vague days. The standard is four buckets: Done, Open, Blocked, Next. Full guide: write an end-of-day status update. Client-facing shape: client status update template.
Weak
Made progress on checkout. A few blockers. Will sync tomorrow.
Strong
Done
- PR #482 merged; preview deploy green for happy path
Open
- Webhook failure path still red in preview (ticket PAY-218)
Blocked
- @sam: preview webhook secret in vault (need before 14:00 UTC)
Next (me, before Berlin overlap)
- Set secret, redeploy, comment pass/fail on PRThe strong version transfers state. The weak version transfers anxiety.
Daily vs weekly rhythm
| Cadence | Audience | Length |
|---|---|---|
| End of day | Team or client | Four buckets, under two minutes to read |
| Start of week | Team | Three outcomes for the week + known waiting |
| Midweek | Client | Done + one decision ask |
| Friday | Team | Done + first move Monday |
Do not paste the same paragraph into chat, email, and a doc. Pick one canonical place (ticket, doc, or channel thread) and link to it.
Response SLAs that respect sleep
"Always available" is a bad system. Publish windows instead.
| Window | What it means | What it does not mean |
|---|---|---|
| Overlap hours (team-agreed) | Chat pings are fair; aim for same-day reply | Instant reply |
| Outside overlap | Complete written request; reply next overlap | Ignoring the message |
| Urgent | Named channel or phone for true production down | Every "quick question" |
Map overlap with the Team Time Zone Planner. Put the agreed window in the team wiki, not only in someone's head.
SLA examples that work
Engineering triage: P1 production down gets a reply within one hour inside overlap. P2 gets next business day in the requester's zone. Everything else is written with a deadline in UTC.
Client freelance: Email checked twice on workdays (11:00 and 16:00 local). Slack only if contracted. Weekends off unless on-call is paid and scoped.
Product + design: Decisions in the doc by EOD Tuesday; comments async; one 25-minute live slot Thursday only if two options remain tied after writing.
Write the SLA where new hires will see it. Revisit after DST and when the roster changes.
Channels vs meetings
Meetings are expensive: they synchronize attention across zones and rarely leave a searchable artifact. Channels and docs are cheap storage if people write complete messages.
| Use chat for | Use docs/tickets for | Use meetings for |
|---|---|---|
| Quick clarifications inside overlap | Decisions, specs, handoffs | Pairing, conflict, sensitive feedback |
| Links to the canonical artifact | Blockers with owners | Reviews that stall without live debate |
| "I am back online at …" | Status at end of day | Nothing that could be a two-option written brief |
Rule: If the meeting has no exit criterion ("we leave with A or B chosen"), cancel it and send a written update for two weeks. See what breaks. Most standing syncs exist from habit, not need.
When ownership crosses a night, use a handoff, not a longer meeting. Structure: leave work someone else can continue.
Worked example A: EU / US product team
Cast: product in Berlin, engineering in Austin, design contractor in Chicago. Shared overlap Berlin–Austin is roughly three hours mid-European afternoon.
Monday async: Product posts a one-page brief in the ticket: problem, two options, recommendation, deadline for comments (Wednesday 12:00 UTC).
Tuesday: Engineering comments in the ticket with feasibility notes. Design drops links in the same thread. No meeting.
Wednesday overlap: 30 minutes only if options are still tied. Exit criterion on the invite: choose option A or B and assign owner.
Thursday–Friday: Build async. End-of-day notes in the ticket using Done / Open / Blocked / Next.
What they stopped doing: Daily 45-minute "sync" that repeated what was already in chat.
Worked example B: Support follow-the-sun
Cast: Tier 1 in Manila, Tier 2 in Dublin, engineering in Denver.
Handoff Manila → Dublin: Use the four-field handoff (state, proof, next move, blockers). Not "see Slack."
Escalation to engineering: Blocker template with reproduce steps, customer impact, and deadline before Denver's overlap ends.
SLA: Customer gets first human reply within 4 hours; internal engineering gets a complete escalation within one Dublin shift.
Meeting budget: One weekly 25-minute review of repeat escalations, not daily war rooms.
Async request checklist
Before you ping or @mention:
- Link to the artifact (PR, doc, ticket)
- What done looks like in one sentence
- Decision needed vs action needed
- Deadline in UTC or named zone
- Who owns the next move
If you cannot check four boxes, you are not ready to interrupt someone's focus.
Tradeoffs
| Pressure | Cut first | Protect |
|---|---|---|
| "We need faster answers" | More meetings | Clearer requests + SLAs |
| Fear of missing context | CC everyone | One canonical thread |
| Client wants your morning | Instant chat all day | Batched windows + status template |
| Heroic midnight replies | Praise for speed | Sustainable overlap + handoffs |
What to refuse
- Meetings with no written pre-read
- "Quick call?" without an exit criterion
- Status meetings that duplicate what tickets already say
- Async messages that are only "thoughts?"
- SLAs that pretend sleep does not exist
Async communication is a skill, not a personality type. Write complete requests, publish response windows, replace one recurring meeting with a written update, and ship the end-of-day note before you close the laptop.