⏱ 5 min read
Intro
You may be doing async suboptimally. Not because you’re using the wrong tools, but because you’ve kept all your synchronous instincts and just added a delay. Sending a Slack message and expecting a reply within twenty minutes, feeling anxious when a thread goes quiet for two hours, or keeping three “quick syncs” that could’ve been a paragraph are signs of delayed sync — not true async.
This guide gives a working system you can implement: not a philosophy or a list of apps, but a structure. Async communication means both parties don’t need to be present simultaneously, and crucially, the communication is designed with that assumption from the start. You can’t just send messages at odd hours and call it async; the messages themselves must be built for someone who will read them later, without you there to clarify.
What async is—and isn’t
Async is not necessarily slow, a ban on meetings, or ignoring people. Some situations require real-time conversation: tense client negotiations, rapid creative brainstorming, or difficult personnel conversations. The goal is to make async your intentional default in remote communication, not a dogma that eliminates judgment.
Three common symptoms
- Response-time anxiety: The sender refreshes the thread; the receiver feels guilty. Both people silently agree on an unstated expectation.
- Incomplete messages: Messages written as conversation openers instead of complete thoughts — “quick question” with no question attached, or context spread across five sequential pings.
- Decisions that stall: Decisions that could be made in writing stall because the written communication never established enough context for someone to act.
Why it matters
Interruptions cost time: research suggests recovering full focus after an interruption can take tens of minutes, and repeated interruptions disrupt deep work. Combined with timezone friction, distributed teams can end up effectively synchronous during a small overlap window, which is inefficient. The fix often requires structural changes rather than a single retro or offsite.
The communication stack (by function)
Think of your communication stack not as a list of tools but as a set of functions, each with a different job.
1. Long-form writing
Handles decisions, context, and documentation. The tool matters less than the habit: Notion, Confluence, Linear, Google Docs — any of these can work if the team actually writes in them. Include anything a new team member would need to reconstruct your thinking: project briefs, decision logs, onboarding docs, meeting recaps.
Before publishing, run the “future reader” test: could someone who wasn’t in the room understand what was decided, why, and what the alternatives were? If not, the document isn’t done.
2. Threaded messaging
Handles questions, updates, and lightweight collaboration. Prefer threads over channels when possible; respect status indicators. Avoid @here for non-emergencies — it erodes trust. A simple rule: write the full message, not the opener. “Hey, got a sec?” is synchronous behavior wearing async clothing. Write the question, include relevant context, and state what you need.
3. Video and voice
Loom, Vidyard, or a voice memo can communicate nuance and reduce ambiguity without calendar coordination. A three-minute video walkthrough of design feedback often beats many written paragraphs. Don’t record things that genuinely require back-and-forth in the same session; if you’ll need a reaction to a reaction, schedule the call.
4. Shared source of truth
One place where project state lives reduces interruptions. When people know where to look, “just checking in” messages decline. Tools are the easy part; consistent use and clear documents are the harder skills.
Writing messages that work async
Async communication lives or dies on message quality. A well-chosen tool with poor message construction still produces a slow, frustrating loop. The principle that fixes most problems immediately is BLUF: Bottom Line Up Front. Share a Loom walkthrough for clarity. Record your first Loom for free.
- BLUF: State the ask or decision needed in the first sentence. Context comes second. Example: “I need your approval on the revised budget by Thursday.”
- Completeness over extreme brevity: Anticipate obvious follow-ups. Include relevant context inline rather than forcing the reader to hunt in other threads.
- Explicit deadlines: “Whenever you get a chance” is not a deadline. State dates or response windows.
- Label intent: Separate FYI from action-needed messages, either structurally or with a simple label at the top.
- Pre-send edit: Before you send, ask: what question will this generate? If the answer is obvious, answer it in the message.
Response-window norms
Make response windows explicit and agreed upon by the team. Example norms you can adapt:
- Threaded messaging: 2–4 business hours during overlap.
- Email: 24 hours.
- Project-management comments: 48 hours.
The specific numbers matter less than everyone agreeing on them.
Formalize norms and escalation
Async systems often fail when norms are implicit. Write them down and agree on them. Three norms worth formalizing:
- Response windows by channel type.
- Escalation path: What counts as an emergency that breaks async protocol, who defines it, and how to reach someone when it happens?
- Meeting criteria: What requires synchronous conversation (emotional stakes, rapid iteration, relationship-building)? Everything else is a candidate for async.
For freelancers and client work
Include async expectations in onboarding documents or contract addenda. A client told upfront that you respond within four business hours during weekdays is less likely to expect a 9pm Sunday reply. If you don’t set expectations, clients will construct their own.
For employees proposing async to a team, frame it as a lightweight working agreement: “How we work best together” lands better than “new rules.” Keep it short — a single page is often enough.
A simple experiment: seven days
Pick one channel (probably Slack or your primary messaging tool) and apply the complete-message principle for seven days. Write the full thought before you send: include context, state the ask, and note the deadline. Observe changes in follow-up messages, your anxiety about response times, and the quality of replies.
Conclusion
Async done well isn’t about being less responsive. It’s about being more deliberate. Tools are the easy part; writing clear messages and formalizing shared norms are the hard parts. Do that consistently and you become easier to work with at a distance — the work stops requiring you to push it forward at every step.
