Decision log
A short written trail for calls that need an owner, a revisit date, and a reason. Not a binder of minutes.
Most teams do not forget what they discussed. They forget what they decided, who owned it, and what would make them reopen the call. A week later the same debate returns with slightly different charts and the same unresolved tradeoff.
A decision log is a lightweight way to leave a trail. It sits next to a weekly review or a partnership operating cadence. The point is not documentation for its own sake. The point is memory that can be checked.
When it is worth writing
I use a log when the call sets how other people will behave: priorities, incentives, partner terms, resourcing, or anything we will claim later as “already decided.” Skip the trivial choices that do not need a revisit.
What to capture
Keep the fields short enough that someone will actually fill them in the day of the call:
- Decision (one sentence)
- Context (two to four lines)
- Options considered
- Constraints
- Owner
- Date
- Revisit by
- What would change this call
If you cannot name an owner or a revisit date, you probably do not have a decision yet. You have a discussion.
A few rules that keep it useful
- One owner per decision.
- Write it the day of the call, while the tradeoff is still clear.
- Revisit is a date, not a vibe.
- Link from the weekly review when the decision came out of that forum.
What to avoid
The failure mode is a log that records conversation without a call. Long notes, no owner, no revisit, and a false sense that the organization moved. If the entry cannot answer “who decides, by when, and what would reopen this,” it is not earning its place.