Async communication fails when you write for yourself, not the reader. A practical guide to reader first async writing, message shapes, and remote team etiquette.
One of my engineers pinged me at 11pm from Dubai with "async isn't working for our team, we need more meetings." I asked him to forward the last five messages that had actually blocked him. Every single one was a wall of stream-of-consciousness text with the real question buried in sentence four, no clear ask, and a limp "let me know your thoughts" at the end. Async wasn't the problem. We were all writing for ourselves and billing the reader for it.
After six years running a small engineering team across Dubai hours, client hours in the US, and contractors somewhere in between, I've stopped believing "async doesn't work for us." It's almost always false. What's true is that people write messages that are cheap to send and expensive to read, then blame the medium when the reader can't act on them. Async communication is a writing discipline wearing a scheduling costume — and once you see it that way, most of your "remote team problems" turn out to be prose problems you can actually fix.
Most advice about async communication is about tooling and ritual. Use Slack threads. Write more docs. Do weekly written updates. Turn off notifications. Adopt the shiny new project tracker. All fine. None of it touches the actual failure.
The failure is that we tell people to be async without teaching them to write for a reader who is not in your head, not in your timezone, and not going to ask a follow-up before deciding what to do. Synchronous conversation forgives lazy writing because the other person can interrupt: "wait, what do you actually need from me?" Async removes that safety net. A vague message in a meeting costs one clarifying sentence. The same message in Slack costs a round-trip that might be eight hours long across a distributed team.
So teams try async communication, discover that their existing writing habits fall apart without the interrupt button, feel the pain, and conclude that async is broken. It isn't. Async is just the medium that finally makes the cost of bad writing visible. The remote-work era didn't create bad communicators — it removed the real-time crutches that were hiding them.
This is the mental model that changed how I think about every message I send. Every piece of written communication has two costs:
Bad async writing optimizes for sender cost. I dump my thoughts, I hit send, I feel productive. But if that message goes to five people and each of them spends four minutes decoding it, and one of them has to ask me a clarifying question tomorrow, I saved myself two minutes and spent twenty-plus of the team's minutes — plus a full timezone round-trip.
Good async writing does the opposite. I spend three extra minutes making the message unambiguous so that zero readers have to think hard and zero readers have to ask a follow-up. The math is brutal and it always points the same direction:
The sender pays once. The readers pay N times. Optimize for N.
On a recent project we audited why our two-day features kept taking four. A big chunk was coordination latency: someone would ask a question at the end of their Dubai day, the answer landed the next morning but was itself ambiguous, so a third clarifying message went out and another day evaporated. Roughly a third of our cycle time was not building anything — it was waiting to be understood. We weren't slow engineers. We were slow writers.
There's a useful way to picture this. Imagine a message that takes you 2 minutes to write and 1 minute per person to read cleanly. Now imagine the lazy version: 30 seconds to write, but 3 minutes per person to decode, plus a real chance one reader triggers a clarifying round-trip that costs a full day of latency.
Clear message -> sender 2m + (5 readers x 1m) = 7 min, 0 round-tripsLazy message -> sender 0.5m + (5 readers x 3m) = 15.5 min + a decent chance of an 8-24h latency round-trip
The "efficient" message is the slow one. Once you internalize that the reader is the expensive side of the equation, the tactical rules basically write themselves.
The single most common mistake I see in async communication is treating all messages as the same kind of object. They aren't. A message is doing one of three jobs, and each job has a different shape. If the reader can't tell which one they're holding, they don't know what response you need — and in a distributed team, "I wasn't sure if you needed me" is how work quietly stalls for a day.
A question needs an answer, and it needs to be answerable now — without a follow-up. That means:
Compare these:
Bad: "Hey, thoughts on how we should handle the offline sync conflict thing? It's kind of tricky."
Good: "Sync conflict resolution: I'm choosing between (a) last-write-wins and (b) server-authoritative with a merge queue. I lean (a) for v1 because our writes are rarely concurrent and (b) roughly doubles the work. Unless someone flags a case where two users edit the same record within seconds, I'll ship (a) by Thursday. Objections?"
The second one takes ninety more seconds to write. It also turns a multi-day thread into a one-line "agree" or a specific counter. That is the whole game. Notice what the good version smuggles in: the options, the reasoning, the lean, the deadline, and a default. The reader can act on it in five seconds or push back precisely — no round-trip required.
A decision isn't asking for input, it's recording an outcome. The reader's job is to know what changed and whether it affects them. Lead with the decision, then the reasoning, then the blast radius:
"Decision: we're dropping Realtime Database and standardizing on Firestore for the new module. Why: our query patterns need compound filters and RTDB was forcing us into client-side filtering. Impact: anyone touching the notifications service, your data access layer changes — see the migration note. No action needed from the web team."
That last clause matters more than it looks. Naming who doesn't need to act is as valuable as naming who does — it lets four people close the tab with confidence instead of half-wondering all afternoon.
An FYI needs no response and should announce that fact loudly, because an unmarked FYI makes five people wonder if they're supposed to do something. Prefix it. Literally write "FYI, no action needed" at the top. The kindest thing you can do for a reader is tell them they can stop reading. In async communication, a clear "you're done here" is a gift.
Writing is not talking. When I talk, I build up to my point because I can watch your face and course-correct. When I write async, building up to the point is a tax I'm charging every reader.
Put the ask in the first line. The context comes after, for the people who need it. This is the inverted-pyramid structure journalists have used for a century, and it works because it lets readers stop as soon as they have what they need. Front-loading is not dumbing down — it's respecting that different readers need different depths, and letting each one self-select.
My rule for the team: a reader should know what you want from them before they finish the first sentence. If your message starts with three sentences of background before the ask appears, rewrite it.
A concrete before/after from an actual standup update:
Buried: "So I was looking into the payment webhook thing and it turns out Stripe changed their API version and I spent a while figuring out why the signatures were failing and I think it's related to how we're reading the raw body in our middleware and anyway I might need someone from backend to look at the middleware config."
Front-loaded: "Need: 20 min from someone on backend to review our webhook middleware body parsing. Why: Stripe signature verification is failing after their API version bump; I've traced it to us mutating the raw request body before verification. Not blocked yet — I can keep going on the refund flow meanwhile."
Same information. One of them makes the reader dig for the ask; the other hands it over in six words. A lightweight template I hand new hires for anything that expects a response:
Need: <the single action you want, up front>Why: <just enough context to act, no autobiography>By when: <deadline or "no rush">Default: <what happens if nobody replies>
You don't need every field every time. But if you can't fill in "Need," the message isn't ready to send — you're still thinking out loud, and thinking out loud is a sender-cost activity you shouldn't outsource to five readers.
Not everything belongs in chat, and not everything belongs in a doc. Getting this container choice wrong is a quiet, expensive failure mode in remote teams.
Use a doc when:
Use a message when:
The failure I see most is the "long Slack message that should have been a doc." You know the one: 400 words, three sub-topics, five people @-mentioned, and now the discussion forks into replies that reference paragraph two while paragraph four gets ignored entirely. Threads can't hold structured disagreement. If you're writing more than roughly 150 words and expecting a response, stop and ask whether this wants to be a doc with inline comments instead — a doc gives each point its own comment anchor, so disagreement stays attached to the thing it's about.
The reverse mistake is quieter but real: burying a one-line decision in a 2,000-word design doc nobody opens. If the only thing that matters is "we're going with option B," that's a message. Don't make people mine a document for a single sentence.
A simple heuristic I use: chat is for the pointer, the doc is for the payload. Post the decision or the ask in chat, link to the doc for the depth. Readers who need only the headline get it in five seconds; readers who need the reasoning follow the link. This one habit collapses a surprising amount of async noise, because it stops forcing every reader through the full context just to learn whether they care.
Most "async is too noisy" complaints are really etiquette problems, and etiquette is just writing-for-the-reader applied to the channel instead of the message. Slack etiquette isn't manners for their own sake — it's throughput protection.
A few rules that cut our interrupt rate hard:
None of this is about being formal. It's about respecting that the reader's attention is the scarce resource, not yours.
Async is a default, not a religion. Defending it past its usefulness is its own kind of dysfunction, and I've watched teams spend three days writing paragraphs at each other over something a fifteen-minute call would have killed instantly.
There are three signals where I stop writing and hit call:
Notice that these are exceptions with clear triggers. The failure mode isn't calling too little — it's using "some things need a call" as an excuse to never build the writing muscle at all. And even when you do call, the discipline still applies afterward: the decision, the feedback outcome, the incident summary all get written up async so the people who weren't on the call aren't now dependent on someone's memory.
Fix the writing and most of your "async problem" disappears. It was never the calendar. It was the prose.