A decision log is a maintained record of significant decisions made by a team or manager, including the decision itself, the date, the decision-maker, the rationale, and the alternatives that were considered and rejected.
Its primary function is not documentation for its own sake but prevention: it stops a settled question from being reopened every time a new stakeholder joins the conversation.
Key takeaways
- A decision log entry has three required fields: what was decided, who decided it, and why the alternatives were not chosen.
- The log is a meeting output, not a post-meeting task: it should be written while the rationale is still in the room.
- The highest-value entries are the decisions that felt controversial or uncertain at the time. Those are the ones most likely to be relitigated.
- A decision log reduces onboarding time: new team members can understand the reasoning behind current choices without excavating old chat threads.
Why it matters
Decisions decay. The reasoning behind a technical choice made six months ago, a product direction taken under time pressure, or a resourcing call made in a planning session is rarely preserved. When a new person joins, or when the context changes, the decision gets questioned from scratch. The discussion takes the same time the first one took, minus the people who were actually there.
Decision logs are also a check on revisionism. In teams without a record, decisions tend to be remembered selectively: the path taken is remembered, the alternatives considered are forgotten. That makes it easy for a vocal stakeholder to reopen settled questions by claiming 'we never really decided this.' A log ends that pattern.
For managers specifically, a decision log externalizes judgment. It shows the team that decisions are reasoned, not arbitrary, and that the process is consistent. Over time, it also reveals patterns: which types of decisions tend to be revisited, which stakeholders tend to re-raise settled calls, and where the team's biggest areas of ongoing ambiguity lie.
How it works in practice
Setting up and maintaining a decision log
-
Choose a single place to keep it
The medium matters less than the consistency: Notion, Confluence, a shared doc, or a dedicated channel all work. One place, always updated, always findable. Multiple places means it will not be consulted.
-
Define the minimum entry format
Every entry needs: the decision in one sentence, the date, the decision-maker, the rationale in two to three sentences, and the key alternatives rejected. Keep it short enough that people actually write it.
-
Write the entry in the meeting, not after
The rationale is clearest while the discussion is still happening. Assign one person to take the log entry live. Post-meeting documentation of reasoning is consistently thinner than in-the-moment capture.
-
Link to relevant context
If the decision references a document, a spec, a customer call, or a data point, link it. The log entry is the index; the linked context is the depth. This keeps entries short while making them verifiable.
-
Review the log at planning boundaries
At the start of each quarter or sprint planning cycle, review recent entries. Some decisions will need to be revisited given new information. Surfacing them proactively is better than having them surface mid-execution.
Common mistakes
Recording only the decision, not the rationale
A list of decisions without reasoning is a history, not a log. The value is in understanding why, so that when context changes, the team can assess whether the original reasoning still holds.
Letting the log go stale
A log that is not updated within a week of decisions being made quickly becomes untrusted and unused. Assign a standing owner for updates, or embed it in the meeting process itself.
Logging every decision indiscriminately
Not every decision needs a log entry. Trivial or easily reversible decisions add noise that buries the signal. Log decisions that would be costly or time-consuming to reopen.
Treating the log as a wall against future discussion
The log is a starting point for revisiting a decision, not a block on it. When new information is material, decisions should be reopened. The log makes that conversation faster by restoring the original context.
What it sounds like
A team is three months into a project and a new engineering lead is questioning a database choice made before they joined.
“Why are we using Postgres here? This seems like a graph database problem,” said Daniel.
“We evaluated graph databases in April. The log entry has the comparison: we ruled them out because of operational complexity given our team size,” said Guy.
“Okay, that context changes my question. Does the team size assumption still hold, or should we revisit?” said Daniel.
Questions managers actually ask
How is a decision log different from meeting notes?
Meeting notes capture everything discussed. A decision log captures only what was decided, who decided it, and why alternatives were rejected. Decision logs are consulted; meeting notes are archived.
How long should a decision log entry be?
Five to eight sentences at most. The decision in one sentence, the rationale in two to three, the alternatives rejected in one to two. If it takes longer, you are writing a document, not a log entry.
Who should own the decision log?
In a small team, the manager. In a larger team, a designated directly responsible individual per domain. The key is that ownership is named and consistent, not shared.
Should individual contributors have access to the decision log?
Yes, by default. Transparency about why decisions were made builds trust and reduces the likelihood of people working against decisions they do not understand.
What happens when a logged decision turns out to be wrong?
Add an update entry: the original decision, what changed, the new decision, and who made it. Do not delete the original. The history of how the team thinks is as valuable as the current state.
How is this different from an architecture decision record?
Architecture decision records are a specific format for engineering and technical choices. A decision log is a broader, more informal version that covers any significant team decision, not just technical ones. The principles are the same.
See how Leap improves execution in your meetings
Leap sits in your meetings, captures decisions and owners in real time, and shows you where execution breaks down before the week is out.