- A precise definition of async communication — and why "slow" is the wrong framing
- A decision ladder for choosing async vs real-time for any given exchange
- How to write messages complete enough to avoid follow-up round-trips
- How to set response-time norms that protect focus without dropping the ball
When teams went remote, most didn't redesign how they communicate — they took office habits (walk over and ask, call a quick meeting, expect an instant answer) and pointed them at chat apps. The result is a workday sliced into fragments by a steady stream of messages that each expect an immediate reply. Asynchronous communication is the deliberate alternative: a way of coordinating that assumes people are not all available at once, and treats that as a feature rather than a problem.
What async really means
Async communication is any exchange that doesn't require both parties present at the same instant. A thorough message, a recorded walkthrough, a comment on a document, a ticket update — the receiver engages when it suits their schedule. The common misreading is that async means "reply whenever you feel like it." It doesn't. It means the timing is decoupled, while the clarity goes up, because you can't rely on an immediate back-and-forth to fill gaps.
Real-time communication is cheap for the sender and expensive for the receiver — it interrupts their focus on your schedule. Async flips that: it costs the sender a bit more effort up front (writing clearly) and saves the receiver's attention. Good async communication is a courtesy paid in advance.
Why async fits remote work
Distributed teams have three conditions that make async the right default:
- Time zones. When people span several zones, waiting for everyone to be online simultaneously wastes hours or blocks work entirely.
- Deep work. Remote work's main advantage is uninterrupted focus; a real-time-default culture destroys exactly that — see Deep Work Principles.
- A written record. Async communication is documentation by default, which compounds into the kind of searchable knowledge base described in Documentation-First Culture.
The async decision ladder
Not everything should be async, and not everything should be a call. Use a ladder: start at the top and only move down when the exchange genuinely requires it.
Writing self-contained messages
Async only works if messages don't spawn a chain of clarifying questions. A self-contained message has four parts:
- Context: what this is about and why it matters now.
- The ask: the specific decision, action, or answer you need — stated explicitly.
- Everything needed to act: links, options, relevant details, so the reader isn't blocked.
- A deadline: when you need it, so it can be prioritized honestly.
The test is simple: could the reader act on this without asking you anything? If not, you've pushed the work of clarifying onto them and guaranteed a round-trip. A minute of writing saves three exchanges.
Setting response-time norms
The anxiety that kills async cultures is uncertainty: if no one knows when a reply is expected, everyone assumes "now," and you're back to real-time. Make the norms explicit and written.
| Channel / marker | Expected response | Use for |
|---|---|---|
| Standard async message | Within one business day | Most questions, reviews, updates |
| Marked time-sensitive | Within a few hours | Blocking issues that can wait a little |
| Call / page | Immediate | Genuine emergencies only |
Publishing these norms does something subtle but powerful: it makes not replying instantly the accepted default, which is what finally lets people close chat and do focused work.
When sync is still better
Async is the default, not a religion. Real-time communication genuinely wins for:
- Sensitive or emotional conversations, where tone and immediacy matter.
- Highly ambiguous problems that need rapid, exploratory back-and-forth.
- Relationship-building and team cohesion, which text can't fully replace.
- True emergencies, where speed beats everything.
The full tradeoff, scenario by scenario, is laid out in Async vs Synchronous Communication.
A worked example
A ten-person distributed team ran three recurring status meetings a week and a chat channel where every question expected an instant reply. People complained they had no time to think. They made two changes: status meetings became a written async update posted by end of day Monday, and they published the response-time table above.
Within a month, two of the three meetings were gone, replaced by updates people read on their own schedule. Chat volume dropped because messages became more complete, and the "reply within a day" norm let engineers close Slack for their morning focus blocks. Coordination didn't suffer — the written record actually made it easier to follow what was happening.
- Async isn't "slow" — it decouples timing and raises clarity, protecting the receiver's focus.
- Use the decision ladder: default to written async, step down to a call only when the exchange demands it.
- Write self-contained messages: context, ask, everything needed to act, and a deadline.
- Publish response-time norms so instant replies stop being the anxious default.
Frequently asked questions
What is asynchronous communication?
Asynchronous communication is any exchange that does not require both people to be present at the same moment: a detailed message, a recorded video, a document comment, a ticket update. The recipient responds when it fits their schedule rather than immediately. It contrasts with synchronous communication like calls and live meetings, where everyone must be available simultaneously.
Isn't async communication just slower?
It trades instant response for protected focus, and for most work that trade is strongly positive. Real-time communication is fast for the sender but expensive for the receiver, because it interrupts deep work. Async lets people answer in batches without fragmenting their attention. Genuinely urgent items still use real-time channels; the point is to stop treating routine questions as emergencies.
How do I write a good async message?
Make it self-contained: state the context, the specific ask, any relevant links, and a clear deadline, so the reader can act without a back-and-forth. A good async message answers the questions the reader would otherwise have to ask. The extra minute you spend writing it clearly saves the several round-trips a vague message would trigger.
What response time should async messages expect?
Set explicit norms rather than leaving it ambiguous. A common workable standard is: routine async messages get a response within one business day, time-sensitive items use a marked channel with a few-hours expectation, and true emergencies use a call or page. Written norms prevent the anxious assumption that everything needs an instant reply.