Decision logs

A decision log is a chronological record of significant decisions the business makes, what was decided, why, by whom, with what reasoning. Takes 2 minutes per decision to maintain. Saves months of rework, re-litigation, and "wait, why did we do it that way?" conversations.

Why decision logs matter

In a growing company, decisions happen faster than anyone can remember. Six months later, a new hire asks "why do we do X?", and nobody remembers. The reasons get re-invented poorly, or the decision gets unmade and redone (usually worse).

A decision log is institutional memory. It survives people leaving, meetings forgotten, context lost.

What belongs in a decision log

Not every small call. The ones that:

• Affect how the business operates going forward
• Involved meaningful debate or trade-offs
• Would be hard to reverse
• Someone might reasonably question in 6 months

Examples: pricing changes, org structure shifts, major tool/vendor choices, policy changes, product direction shifts, market entry/exit.

The entry template

DATE: [When decided]
DECISION: [One-sentence summary]
OWNER: [Who made the call]
CONTEXT: [What prompted this]
OPTIONS CONSIDERED:
  - A: [pros/cons]
  - B: [pros/cons]
  - C: [chosen, why]
REASONING: [Why C over A and B]
REVISIT: [When or under what conditions to re-evaluate, if applicable]

Total: 3-8 lines. Takes 2 minutes to fill in after a decision meeting.

Where it lives

One shared doc. Notion page, Google Doc, Confluence, whatever. Chronological. Searchable. Readable by the relevant leadership circle.

Not every decision needs to be visible to every employee. Scope the log to who needs to know.

Why the "reasoning" field is the magic

Future-you or a new team member will see the decision. They need to know why. Without reasoning, the decision is floating in the air, easy to question, easy to unmake.

Good reasoning documents the constraints at the time:

• "We chose X because A, B, and C were true in Q2 2026."
• "If those become less true, re-evaluate."

This gives future-you permission to change course when the conditions change.

The revisit field

Some decisions are clearly conditional:

• "Revisit when we hit $1M ARR"
• "Revisit if the vendor changes pricing"
• "Revisit in 6 months regardless"

Calendar reminders on revisit dates mean decisions get re-evaluated, not just forgotten.

Who maintains it

An operations lead, EA, or founder's chief of staff. Low overhead, they attend meetings, take 2 minutes to log each major decision, keep the doc current.

Common mistakes

• Logging every decision, too noisy. Stick to significant ones.
• Writing only what was decided, not why, strips the utility.
• Making it private to the CEO, defeats institutional memory.
• Starting a log during a crisis, you need the discipline built before you need it.
• Treating it as a historical record only, use it in decision meetings: "we decided X last quarter, why is this back up?"

The related doc: assumption log

A cousin of the decision log. Tracks the assumptions your strategy rests on.

"We assumed X was true. If X turns false, Y part of the plan breaks."

Review quarterly. When an assumption turns false, you know which decisions to revisit.

Decision velocity vs, quality

Companies often choose: move fast and decide poorly, or decide well and move slowly. A decision log lets you do both, because you can revisit and fix yesterday's mistakes instead of pretending they didn't happen.

What operators learn from keeping one

Six months into keeping a decision log, patterns emerge:

• Which types of decisions you consistently get wrong
• Which reasoning shortcuts mislead you
• Which "obvious" calls weren't obvious in hindsight

This is the meta-skill: learning from your own decision history. Impossible without records.