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.