Keep a Decision Log
Three months ago the team agreed on the vendor. Today someone asks 'why didn't we pick the other one?' and nobody remembers — so you debate it all over again. A decision log is one page where each decision, its reason, and its date live permanently. It ends re-debates in one sentence: 'we decided this on March 4th because X.'
TL;DR / Quick Fix
Quick fix: keep a single shared document where every significant decision gets one line — what was decided, why, when, and by whom. When the topic resurfaces, point at the entry instead of re-debating. Five minutes of writing saves hours of repeated meetings. Backfilling history is optional.
Follow these steps
- Create one shared document. A simple doc or wiki page titled Decision Log. One place, shared with the team — a log scattered across chats and emails is not a log.
- Log the decision the day it happens. Write it while the reasoning is fresh: what was decided, the key reason, the date, and who decided. Same-day entries take two minutes; reconstructed ones take twenty and lose the why.
- Record the reason, not just the verdict. 'Chose Vendor A' is useless in three months. 'Chose Vendor A — half the cost, API fits our stack, decided March 4 by the leads' ends the re-debate.
- Include the alternatives considered. One line on what you rejected and why. Future-you will thank present-you when someone proposes the rejected option as if it were new.
- Review it before big meetings. Skim the log before planning sessions. Half of all 'new' proposals die quietly when the log shows they were already decided.
- Keep it to significant decisions. Vendor choices, architecture calls, policy changes — not what to order for lunch. A log of everything is a log of nothing.
What NOT to do
- Do not keep the log in your head or in chat. Memory fades, chat scrolls away — the log only works as one persistent document.
- Do not log decisions without the reasoning. A verdict without its why invites the exact re-debate you are trying to prevent.
- Do not let it go stale. A log abandoned after two weeks teaches the team it does not matter — assign its upkeep to the meeting notes ritual.
- Do not use it as a weapon. 'Per the log, you are wrong' poisons the tool; 'here is what we decided and why' keeps it useful.
Frequently asked questions
What counts as a decision worth logging?
Anything expensive to revisit: vendors, tools, architecture, policies, scope changes. If re-debating it would cost an hour, log it.
Who should maintain the log?
Whoever runs the meeting where the decision happens. Five roles are overkill — tie it to the existing meeting notes habit and it maintains itself.
Should rejected options be logged too?
Yes, briefly. The most common re-debate is a rejected option returning as a 'new idea' — one line prevents it.