The short version
- Most advice about working in writing covers the writing. The failure is not in the writing, it is in what happens when the reader is not there.
- Two rules decide most of it: what must be in writing, and what may wait for a person. Teams that never state the second rule wait for people by default.
- Write to be answered in one pass. A question that needs a clarification has doubled its cost before anyone replies.
- State response times out loud. Uncertainty about when a reply comes is more disruptive than a slow reply.
Guides to working in writing are mostly about composition: be clear, over communicate, default to writing, use threads. All reasonable, and none of it addresses the thing that actually goes wrong.
Where it actually breaks
A well written question, sent to the right person, in the right channel, with all the necessary context. It is perfect. It sits for nineteen hours because its owner is asleep, and the sender spends those nineteen hours either waiting or doing something less useful.
No improvement in writing quality changes that. The bottleneck is not comprehension, it is availability, and writing advice treats availability as somebody else's problem.
This is why teams that adopt written communication enthusiastically often feel slower six months in. They removed the meetings and kept the dependency on people, so now they have the latency of writing plus the waiting of absence.
The two rules
Write both down. Most teams have a version of the first and almost none have the second.
| Rule | Covers |
|---|---|
| Must be in writing | Decisions and their reasoning, commitments to anyone outside the team, current state at the end of each day, anything a person in another zone needs to continue |
| May wait for a person | Disagreements, feedback on someone's work, anything about performance, first conversations in a new relationship |
The second rule is what stops the team from trying to do everything in writing, which is its own failure mode. A difficult conversation conducted in a thread over three days does more damage than a thirty minute call at an inconvenient hour.
The rule that follows from both: if it is not on the second list, nobody should be waiting for a person to answer it. That reframes the whole problem, because most teams discover a large volume of waiting that fits neither category.
Write to be answered in one pass
Across a time gap, every clarification costs a day. So the standard for a question is not clarity, it is answerability.
- Give the options. "A or B" rather than "what do you think".
- Give your recommendation and why. It lets the reader reply with one word, and they will correct you if you are wrong.
- Give the deadline and the default. "If I do not hear by Thursday I will do A." Silence then becomes a decision rather than a delay.
- Put the ask in the first line. Context after. A reader who has to work out what is wanted from paragraph four will postpone it.
The default is the one that changes the arithmetic most. It converts every waiting item into a moving item with a checkpoint.
Say when a reply is coming
Most of the felt cost of working in writing is uncertainty rather than delay. A reply in six hours is fine if you knew it would take six hours. The same reply is disruptive if you checked four times and considered whether to escalate.
Agree the numbers and write them down. Something like: chat within one working day, tagged questions by the end of your next working day, incidents within an hour via the on call route. Then hold to them, because a stated expectation that is not met is worse than none. See putting response times in writing.
What is left over
Do all of the above properly and there is a residue: questions that are not decisions, not disagreements, and not covered by any document, arriving while their owner is offline. Where does this stand. What did we agree. Why is it set up this way.
These are the largest category on most teams and they have no home in a written communication policy, because the answer exists only as something a person knows.
This is what StandIn is built for. At the end of the day each person spends about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work that already happened. When they are offline, their StandIn answers from that brief, in their words, with a source under every answer. It never guesses, and when the answer is not in the record it says so and names who to ask. The questions that may legitimately wait for a person still wait. Nothing else does. See working across time zones and written practices that survive a deadline.
Common Questions
Should we ban meetings entirely?
No. The second rule exists precisely so that some things keep a live slot. Teams that ban meetings tend to reinvent them badly as very long threads.
How do we stop threads from sprawling?
Put a decision and a deadline in the first message. Sprawl is usually a symptom of a thread with no stated endpoint, so it continues until everyone is tired.
Is video a good middle ground?
For explaining something visual, yes. For anything that will be referred to later, no, because it cannot be searched at the moment of a specific question.
What if half the team is in one office?
That is the hardest configuration, because the office half keeps deciding things in conversation without noticing. The rule to enforce is that a decision is not made until it is written, whatever was said in the room. See becoming written first when the team runs on chat.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.