← All postsHow-to

Decision log: writing down what was decided and why

A decision log records what was decided, by whom, and what was rejected. The format that takes two minutes, and why the rejected options are the part worth keeping.

How-toD

Six months after a decision, nobody can reconstruct why it was made. The people involved remember different versions, the thread where it happened has scrolled away, and the most common outcome is that the decision gets quietly remade — usually the other way, and usually by somebody who was not there the first time. A decision log is the cheapest insurance against that, and it takes about two minutes per entry.

What a decision log entry contains

  • The decision, stated as a sentence somebody can act on, not as a topic.
  • The date and who made it — the person, not the meeting.
  • The options considered and why they were rejected. This is the part that matters most and the part always omitted.
  • What was assumed to be true at the time, because that is what changes.
  • What would make you revisit it, which turns a decision into something reviewable rather than permanent.

Why the rejected options are the valuable half

A log that records only what was chosen answers the wrong question. When somebody proposes the alternative two years later — and they will, confidently, as if it were new — the entry that says "we considered this and rejected it because X" either ends the conversation in thirty seconds or, more usefully, shows that X is no longer true and the decision genuinely should change. Without the rejected options you cannot tell those two cases apart, and the discussion restarts from zero every time.

Record the decision even when it feels obvious. Obviousness is a property of the moment, not of the decision — the entries people are most grateful for later are the ones that felt too trivial to write at the time.

Keeping it from becoming a chore

  1. One entry per decision, in a single running document per team rather than a file per decision.
  2. Write it at the moment of deciding, not afterwards — a decision reconstructed later is already a different decision.
  3. Keep it to five lines. Anything longer is a proposal document and belongs elsewhere.
  4. Let anybody add an entry; restrict only the editing of existing ones.
  5. Review the open assumptions quarterly and mark decisions that are now due a revisit.

Where it differs from minutes

Minutes record a meeting; a decision log records decisions wherever they happen, which is often in a message, a call or somebody's head. Most meaningful decisions never appear in minutes because they were not made in a meeting. Keeping the log separate also makes it searchable as a decision — "why do we do it this way" is a question minutes answer badly and a log answers in one line.

Ettex Notes suits the running-document form directly: one log per team, entries added as they happen, searchable later without reading a year of meeting records. Where a decision produces work, the action belongs in a register with an owner and a date rather than inside the log entry itself.

Frequently asked

Who should write the entry?

Whoever made the decision, or whoever was asked to. Delegating it to a note-taker produces summaries of discussions rather than decisions.

How is this different from a decision record in software?

The same idea with a narrower scope. Architecture decision records apply the format to technical choices; a decision log applies it to everything else.

What if a decision is later reversed?

Add a new entry referencing the old one rather than editing it. The reversal and its reasons are as useful as the original.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.