Writing a message that does not need a follow-up call
Most async communication fails because the sender wrote as though the reader could ask a question. In another time zone, they cannot.
The characteristic failure of distributed work is not silence. It is the message that arrives at nine in the morning, is read at nine at night, and produces a reply asking what was meant — which is read the following morning. Two days have passed and nothing has been decided. For broader context on distributed asynchronous work, GitLab’s all-remote handbook is a useful reference.
Almost all of it comes from writing with the assumptions of a conversation: that the reader shares your context, and that clarification is cheap.
Front-load the decision
Co-located writing builds to a conclusion, because the reader is present and will stay with you. Async writing has to invert that: what you want, from whom, by when, in the first two lines. Everything else is supporting material for the people who need it. For a practical software-side reference on proactive work habits, read more adds useful detail.
A reader deciding within five seconds whether this concerns them is the normal case, not a rude one. Writing that respects it gets acted on.
If someone reads only the first screen on a phone, do they know what is being asked and whether it is theirs? If not, restructure before adding detail.
Include the context you have already absorbed
The largest source of round trips is the writer's assumed knowledge. You have spent a week on this; the reader last saw it in a meeting a month ago, or never.
Link the previous decision. State the constraint. Say what has already been ruled out and why. This is the part that feels tedious to write and is the entire difference between a message that resolves and one that generates three questions.
Anticipate the two most likely questions
Before sending, ask what a reasonable person would come back with. There are usually only two or three, and they are predictable: what happens if we do not, what does this cost, who else has seen it.
Answering them pre-emptively adds a paragraph and removes a day of latency. It is the highest-return habit in async writing and the one that takes the most discipline, because it means finishing a thought properly rather than sending and iterating.
Say what kind of message this is
A reader cannot tell from tone alone whether they are being informed, consulted or asked to decide. Label it. FYI, no action needed. Decision needed by Thursday. Want a second opinion, not blocking.
This single convention removes an entire class of confusion, and it protects both sides — the reader knows what is expected, and the writer stops being surprised that nobody responded to something they thought was urgent.
Give a real deadline, or say there is none
'When you get a chance' is unactionable across time zones, because the reader has no way to price it against everything else. It reliably produces either an interruption or a delay, depending on how conscientious they are.
A date and a consequence — needed by Wednesday so the release is not blocked — lets someone schedule it. And where nothing is urgent, saying so explicitly is a genuine kindness in a medium where silence reads as pressure.
Then keep it short
All of the above can be done in under two hundred words, and long messages are read diagonally, which defeats the purpose. Structure and brevity are not in tension: the structure is what allows the brevity.