How to Keep a Decision Log Your Team Will Actually Use
The most expensive meetings are the ones where you re-decide something you already decided, because nobody wrote down why. A decision log is the cheapest insurance against that.
A decision log is a running record of the choices that shaped how your team works: what was decided, when, by whom, and (the part that matters most) why, and what you would need to see to revisit it. It is not meeting minutes. Minutes record what was said; a decision log records what became true.
The value shows up months later. A new hire asks why the team uses one queue instead of per-person queues. Without a log, someone reconstructs a half-remembered rationale and the decision quietly reopens. With a log, you point at three sentences and move on.
What each entry needs
- The decision, stated as a claim: "We will X", not "We discussed X".
- The date and the person accountable for it.
- The rationale in two or three sentences: the reasoning, not a transcript.
- The trigger to revisit: the specific signal that would make this worth reopening. "If support volume doubles" is a trigger; "eventually" is not.
- What you did not choose and why. The rejected option is often the most useful part, because it is what someone will propose again.
Where it belongs
A decision log dies when it lives somewhere nobody works. A separate wiki space that requires a context switch is a graveyard. The log has to sit next to the work it governs: in the project, the team space, or the doc where the decision was made, so that recording a decision costs one line rather than a detour.
One log per team or per project, not one global log for the company. A global log is unsearchable within a month. Scope it to the group that has to live with the decisions.
Keeping it alive
The failure mode is not too many entries; it is too few, because logging feels optional in the moment. The fix is to make it a step in the decisions you already run: when a DACI or a proposal resolves, the last action is a log entry, and the decision is not "done" until it exists.
Review the triggers quarterly. A decision log without a review cadence becomes an archive; with one, it becomes a live map of which assumptions are due for a second look. In Atlas, decisions logged against a project surface in that project, and a recurring review can be an automation rather than a habit you hope survives.