Home / Guides / Asynchronous Communication: What It Actually Requires
Asynchronous Communication: What It Actually Requires
Asynchronous working is widely recommended and rarely practised, because most organisations adopt the vocabulary without the discipline. The result — chat messages expecting instant replies, decisions made in calls and announced nowhere — is worse than either extreme done properly.
What async actually means
Not "we message instead of meeting". It means work proceeds without both people being present at the same moment.
For that to hold, several things must be true:
Context travels with the request. A message reading "can we discuss the API thing?" is synchronous — it requires the other person to be there. The async version contains the question, the relevant background, what you have already tried, and what decision you need.
Decisions are recorded where they can be found. Not in a channel that scrolls away. A decision that exists only in someone's memory of a call has not been made in an async organisation; it has been discussed.
Response time is agreed. "Async" without a stated expectation means everyone assumes something different and half of them are anxious. Twenty-four hours is a common norm. What matters is that it is stated.
Urgency has a separate channel. If everything arrives through the same route at the same priority, people monitor constantly, and you have real-time work with extra latency.
The writing burden is the point
Async communication costs more effort from the sender and less from everyone else.
Writing a request properly takes fifteen minutes. Asking it in a call takes two — for you, plus the interruption to someone else, plus the scheduling, plus the absence of a record.
Organisations fail at async by refusing to accept the sender's cost. People write "quick question" and expect the reader to reconstruct the context, which pushes the work back onto the reader and produces a synchronous conversation in a written medium: the worst of both.
What stays synchronous
Not everything should be written. Async is a default, not a rule.
Disagreement. Written disagreement escalates. Two people who have exchanged three sharpening messages should get on a call.
Ambiguity. When nobody yet knows what the question is, conversation is faster.
Difficult personal matters. Performance concerns, bad news, anything with an emotional dimension.
Early creative work. The generative phase benefits from interruption.
The rule that works: if you cannot write down what you want to discuss, you need a conversation. If you can, you probably do not.
The practices that make it work
Decision records. A short standard note: what was decided, by whom, when, why, what was considered and rejected. Findable. This single habit does more than any tool.
Written proposals before discussion. The proposal circulates, people comment in their own time, the meeting resolves the remaining disagreement rather than presenting from scratch.
Status in writing, always. No meeting should exist to transmit what happened.
A stated response time, published, honoured by managers first.
Meeting notes with decisions separated from discussion. The discussion is context; the decisions are the artefact.
The failure to watch for
Async done badly produces a specific pathology: everything is written, nothing is decided.
Long threads, many opinions, no conclusion, and eventually someone calls a meeting to resolve it — which is fine, except nobody records the outcome, so the thread continues.
The fix is naming a decider for each thread and a date. Async discussion without a decision point runs indefinitely.