A decision log is a chronological record of decisions made by a team. Each entry captures the question that was decided, the options considered, the chosen path, the rationale, and the people accountable. The log is append-only — entries are not edited as circumstances change.
Decision logs are distinct from project plans and from postmortems. Plans describe intent. Postmortems analyze events. Decision logs capture the moment of choice and the reasoning at that moment, with no benefit of hindsight.
The value of a decision log compounds over time. Six months after a decision, the team can answer "why did we choose this?" without depending on anyone's memory. Two years later, the log explains the codebase to engineers who joined after the choice was made.
Why Decision log Matters for Distributed Teams
Engineering teams lose enormous time relitigating old decisions because no one remembers why the original choice was made. A decision log makes that conversation unnecessary.
For distributed teams, the decision log is the substitute for the corridor conversation. Without it, decisions either repeat or freeze.
Frequently Asked Questions
What is a decision log?
A decision log is a chronological, append-only record of decisions made by a team. Each entry captures the question, options considered, chosen path, rationale, and accountable people. It preserves institutional memory in queryable form.
Related Terms
Decision documentation
Decision documentation is the written record of decisions made by a team, including the question, the options considered...
Read definitionInstitutional knowledge
Institutional knowledge is the accumulated context, history, judgment, and lore that lives inside an organization. It in...
Read definitionRFC (request for comments)
An RFC, or request for comments, is a written proposal circulated to a defined audience for structured feedback before a...
Read definitionGet the vocabulary that makes distributed teams work
One email per week on async governance. No spam.
See decision log in action.
StandIn is built around these concepts. Engineers publish declared state before going offline. The next shift starts with full context.