Recording a decision so it stays decided
The most expensive thing a distributed team loses is not information. It is the reasoning behind a choice everyone has forgotten making.
Six months after a decision, three things have happened. The people who made it remember it differently. Someone who was not there is proposing the alternative that was already rejected. And nobody can reconstruct why the rejected option was rejected. For broader context on distributed asynchronous work, GitLab’s all-remote handbook is a useful reference.
In a co-located team this is repaired by conversation. Distributed, it is repaired by a meeting across four time zones, or not at all.
Record four things, not one
- What was decided, stated plainly enough to be checked against later.
- What the alternatives were, including the one that nearly won.
- Why the alternatives were rejected — the actual reason, not a summary.
- What would make us revisit this: a threshold, a date, a condition.
The third is the one that saves the most time and is skipped most often. Without it, the rejected option returns every few months and the argument is re-run from scratch by people who do not know it has already happened. For a practical software-side reference on accountability around written decisions, this guide adds useful detail.
A decision with a stated revisit condition is a decision people can live with, because disagreeing means arguing that the condition has been met rather than that the decision was wrong.
Write it where it will be found
A decision recorded in a chat thread is gone within a week. Recorded in a document nobody links to, it is gone within a month.
The practical answer is a single, dull, chronological log — a decision record — with one entry per decision and a link from wherever the work happens. It does not need a tool. It needs to be one place, and the same place every time.
Write it when the decision is made, not later
Reconstructed reasoning is not the reasoning. Written a fortnight afterwards, it becomes a tidy justification of the outcome, which is exactly the thing that is useless later.
The rule that works is that the decision is not made until it is written. That sounds bureaucratic and it takes about four minutes, and it converts the writing from an administrative chore into the act of deciding.
Name the decider
Distributed teams generate a specific failure: a discussion that reads like agreement, followed by nobody acting, because everyone assumed someone else had the call.
Recording who decided — not who was consulted — resolves it. It also makes it possible for a decision to be made by one person after listening, which is faster than consensus and considerably more honest about how most decisions are actually made.
Let disagreement be recorded
Where someone disagreed and the decision went the other way, note it. This is not a formality: it protects the person who objected, it tells a future reader that the trade-off was known, and it makes disagreeing safe enough that people will do it in advance rather than after it goes wrong.