3 December 20257 min read
Every team that starts working across locations arrives at the same discovery in the same month: the thing that broke was not the meetings. It was everything that used to be settled in the four minutes after a meeting, standing by the door, which now happens nowhere at all.
The usual response is to write more. That is directionally correct and, done indiscriminately, produces a wiki of four hundred pages that nobody trusts because nobody can tell which pages are still true. The useful question is narrower: what specifically has to be written, and where does it go.
The default is wrong in both directions
Teams overwrite the things that change constantly and underwrite the things that almost never change. Status updates, restated three times a week in slightly different words, are a large volume of writing with a shelf life of two days. Meanwhile the reason the payment retry logic works the way it does, which has been stable for two years and will confuse every new joiner, is written nowhere.
Invert it. Write hard about the decisions and the reasoning, which are durable. Be brief about status, which is perishable and mostly visible in the ticket tracker anyway.
What actually has to be written down
- Decisions, with the reason and the options that were rejected. The rejected options are the valuable half; without them the next person reopens the same argument.
- Anything agreed verbally in a call, written afterwards by whoever made the call, in the place the work lives rather than in a chat message that scrolls away.
- The reasoning behind a ticket: why this is being built, who uses it, what a poor result would look like.
- Constraints that are not obvious from the code: the client who cannot be broken, the migration that must not run during business hours, the service nobody may touch without asking.
- Anything you have explained out loud twice. The third time is proof it belongs in writing.
Notice what is missing. Not meeting minutes. Not a transcript. Not a daily narrative of what everyone did. Those are the artefacts teams produce when they have been told to communicate more and have not been told what for.
Decisions, not minutes
The single highest-value writing habit for a distributed team is short decision notes. A few sentences: what we decided, why, what we considered instead, and who to ask. Attached to the ticket or the pull request the decision concerns, not filed in a separate archive.
This survives translation across time zones, across contract types, and across people leaving. It is also the thing that makes handover cheap two years later, because knowledge transfer is mostly the transfer of reasoning, and reasoning is the part that never makes it into the code.
One place, and a rule about which place
Written context spread across chat, email, a wiki, ticket comments and three documents is functionally the same as no written context, because nobody can be confident they have found all of it. The discipline is not about volume. It is about there being a rule that everyone can state.
A rule that works: chat is for coordination and is assumed to be lost; the ticket holds everything about this piece of work; the repository holds everything about how the system works. If a piece of writing does not obviously belong to a ticket or to the code, it is probably a decision note and belongs with whichever one it constrains.
The test is simple. Someone joining in six months should be able to find the answer without asking a human. If the only path to it is a person, it is not written down, it is remembered.
How to ask a question that gets answered once
Asynchronous questions have a cost structure people underestimate. A vague question costs a round trip, and a round trip across even a small time difference can cost most of a day. Two rounds and the day is gone.
The format that avoids it: state what you are trying to do, what you have already tried, the specific thing you are stuck on, and, crucially, what you will do if nobody answers. That last part does most of the work. It converts a blocking question into a non-blocking one, and it lets the other side reply with a single word when the assumption is right.
This applies in both directions. A manager who asks "how is it going?" has asked a question that cannot be answered usefully and has spent a round trip finding that out.
Overlap is for the things writing cannot do
Writing everything down is not a substitute for talking, and teams that treat async as an ideology rather than a tool end up resolving a disagreement over nine messages that a ten minute call would have settled.
Use shared hours for the categories where writing is genuinely worse: disagreement, ambiguity that needs several exchanges, anything with a tone risk, and the first conversation about a piece of work whose shape is not yet clear. A working day that overlaps by most of its length, which is the case between Beirut and Western Europe, makes this cheap enough that there is no reason to be doctrinaire about it. Then write down what you concluded.
The cost, stated honestly
Writing takes time and some of it is wasted. Decision notes get written for decisions nobody revisits. Context gets added to tickets that get cancelled. That waste is real, and the argument for doing it anyway is not that every note pays off. It is that you cannot tell in advance which ones will, and the ones that do pay off pay off enormously, usually at the moment somebody leaves or an engagement changes hands.
Start with two habits rather than a policy: decisions get written where the work lives, and anything explained twice gets written the third time. A team that does only those two things is better documented than most, and neither requires anyone to maintain a wiki.