What Is a Decision Log?

The basic definition

A decision log is a chronological record — usually a table, a doc, or a spreadsheet — where a team writes down significant decisions as they're made: a date, a short description of the decision, and (ideally, though often skipped under time pressure) a reason. It's one of the simplest tools available for keeping decisions from disappearing entirely, and for a small team, a plain decision log can genuinely be enough.

What belongs in a good entry

A minimal but useful decision log entry usually has:

• Date — when the decision was made.
• What was decided — stated as a concrete choice, not a topic ("Switched to Postgres" not "database discussion").
• Why — the reason, in a sentence or two.
• Owner — who made the call or is accountable for it.
• Status — whether it's still standing, or has been revisited/reversed since.

The single most common failure mode of a real-world decision log is skipping the "why" column under time pressure — leaving a list of decisions with no reasoning attached, which is barely better than not having a log at all for the exact question a decision log exists to answer.

Where a plain list stops being enough

A decision log's core structure is a flat list — one row per decision, no relationship between rows. That works fine until a team has enough decisions that some of them start relating to each other: a later decision that supersedes an earlier one, two decisions made independently that quietly contradict each other, or a cluster of related decisions that would be much more useful read together than found one at a time by scrolling. A spreadsheet or doc doesn't surface any of that on its own — someone has to already remember the earlier entry to know it's relevant.

Search is the other common breaking point. A decision log with a few dozen entries is easy to skim. One with a few hundred, spread across a doc that's been split, archived, or migrated tools twice, stops being something anyone actually checks before asking the question out loud again.

Decision log vs decision memory

Decision memory is best understood as what a decision log becomes once it also handles structure and connection: separating the reason and alternatives into their own fields instead of one free-text cell, flagging when a new entry relates to or contradicts an old one, and supporting a real question — "why did we choose X" — instead of only a linear scroll. A decision log is a reasonable place to start; decision memory is what to reach for once the list itself becomes the bottleneck.

A practical starting point

If your team doesn't have any decision log today, starting with a plain doc or spreadsheet — date, what, why, owner, status — is a completely legitimate first step, and better than doing nothing while you evaluate anything more structured. The failure mode to watch for isn't the format; it's whether the "why" column keeps getting left blank.