Decision Log Template

Small teams don't suffer from making too few decisions. They suffer from making the same decisions three times, because nobody remembers the first two. Someone proposes switching backup vendors; the team debates for an hour; the answer is "not now, we'll look at it in Q3." Six months later the same debate starts from zero, because the decision and its reasoning lived in a chat thread that everyone scrolled past. A decision log fixes this with one line per decision: what was decided, who decided it, why, and — the field everyone skips — when to revisit it. The template is deliberately small: if logging a decision takes more than two minutes, the log becomes a museum and everyone stops feeding it. It pairs naturally with the delegation of authority (which says who may decide what) and the weekly review (which is where revisit dates get checked).

1. The five fields — and the one that does the real work

The Revisit field is the one that does the real work. "We decided to defer X" without a revisit date is a polite no — the topic resurfaces later as a fresh debate. "We decided to defer X, revisit 2027-03-01" is a scheduled decision: the debate is pre-paid, and whoever picks it up starts from the recorded reason instead of zero. A log with empty revisit dates is half a log.

2. Which decisions get logged (and which don't)

Log reversible-but-expensive decisions, not everything. Five triggers always earn a line:

1. Spend above the threshold. Whatever your authority matrix sets — $200, $500 — every purchase above it gets a line with the reason. This is also what the ops budget quarterly reforecast reads.
2. Policy changes. Password rules changed, a maintenance window moved, the on-call rotation restructured. Policies that change silently breed "that's not how we did it" conflicts.
3. Tool decisions. Adopt, reject, or defer — especially the rejects. "We evaluated X in March and rejected it over the missing SSO" kills the same proposal coming back in October. This is the sprawl audit's memory.
4. "We'll revisit later." Every deferral gets a revisit date, or it doesn't count as decided.
5. Anything you'd want to read after an incident. "We knew the printer VLAN was flat and accepted the risk" is the exact sentence a postmortem needs to find — and the one nobody can produce from memory.

What doesn't get logged: who's covering the phone on Friday, the color of the new chairs, every bug triage call. The test is the same one the budget uses for its lines: would someone plausibly re-ask this in six months? If yes, one line. If no, it lives in the task tracker like everything else.

3. The format: one file, newest first

The whole log lives in one file — markdown table, spreadsheet, or the CSV below. Newest entries at the top: the log is read for recent decisions; old ones exist for search. One line per decision; if the "why" needs a paragraph, link the paragraph. Keep it boring:

date,decision,owner,why,revisit
2026-09-12,Backups stay on vendor A,Ops,A restore test proved RPO under 1h; B migration saves $9/mo,2027-03-01
2026-09-08,Rejected status-page SaaS,Ops,$29/mo for 4 incidents a year; template page + DNS works,when incidents pass 6/quarter
2026-08-30,Printer VLAN stays flat until Q4,Ops,Segmenting breaks the scan-to-email the office runs on,2026-10-15
2026-08-21,Contractor onboarding via contractor checklist,Ops,3 vendors failed background checks in Q2,review at next contract renewal

That last column does double duty — and here is the habit that makes the log pay: when a revisit date arrives and the answer is still "keep as is," log a new line saying so. "Revisited VLAN decision 2026-10-15: still flat, scan-to-email still load-bearing, next look Q2" is a ten-second entry that prevents the eleventh re-debate. Decisions that survive their own review become decisions you stop paying attention to — which is the point.

4. Where the log plugs into the rituals you already run

• The weekly review (two minutes). The weekly review already scans calendars and incidents; it also scans the log's revisit column: any revisit date that fell due this week gets answered or rescheduled — on the spot. A revisit date that slips silently twice is a decision that never really happened.
• The postmortem (the evidence shelf). After an incident, the postmortem asks "what did we know and decide before this?" The log is where that answer lives — with dates, owners, and reasoning. It turns hindsight from archaeology into a lookup.
• The budget reforecast (the receipts). The budget's quarterly reforecast asks what changed: the log's tool decisions and spend lines are the change history, already written down.
• New-hire onboarding (the twenty-minute read). A new ops hire reading the log learns in twenty minutes why the backup vendor, the flat VLAN, and the rejected status page are the way they are — instead of re-opening each fight from scratch. Pair it with the onboarding checklist.

5. The two failure modes (and the fixes)

• The museum. The log starts rich, entries take ten minutes each, and it dies by November. Fix: cap the format at five fields and one sentence each. If an entry needs more, link the document — the log is an index, not the archive. The documentation habits page has the general rule: build the smallest artifact someone will actually maintain.
• The diary. Entries like "discussed backups, good meeting." Not decisions — no owner, no date, nothing to re-read. Fix: reject entries that can't be phrased in the past tense with an owner. "Discussed X" gets re-logged as "Decided X" or dropped; the debate itself was not the artifact.

There's a third, quieter failure: the log only one person writes. If the recorder is always the same name, decisions made in hallway conversations never land. Fix: anyone may add a line, but the authority matrix still names the decision owner — the log records who decided, not who typed.

6. The paste-in starter (CSV)

Start with the five decisions from the last quarter you can still remember — reconstructing them is the fastest way to feel the value, and the fastest way to notice which ones you can't reconstruct:

date,decision,owner,why,revisit
2026-09-01,Backup vendor stays A,Ops,restore test passed at RPO 45m,2027-03-01
2026-08-28,MDM enrollment becomes day-1 for all laptops,Ops,2 unmanaged devices found in asset drift check,2026-12-01
2026-08-15,Deferred SSO rollout to accounting tool,Ops,vendor SSO tier costs $40/user/mo,revisit when team passes 8
2026-07-30,Accepted flat printer VLAN risk until Q4,Ops,segmenting breaks scan-to-email workflow,2026-10-15
2026-07-10,On-call comp stays flat $150/week,Ops,rotation is 1-in-3; revisit at 1-in-2,when rotation tightens

Five rows is a working log. The habit matters more than the tool — a decision log in a text file that's updated beats an empty notes-app database that's beautiful. If you later want structure and automation around it, the what-to-automate-first pass will tell you it isn't the bottleneck; the ritual is.

7. What a year of logging buys you

• The "did we decide this?" answer in seconds. The same vendor debate arrives four times a year; the log ends it in one search. The saved hours are the visible return; the key-person risk reduction is the invisible one — decisions stop living in one person's head.
• Accepted risks with dates on them. Every "we know and accept this risk" line gets a revisit date, so accepted risks expire instead of fossilizing. That's also what a cyber-insurance questionnaire means when it asks whether risks are "documented and managed."
• A postmortem that starts from facts. The "what did we know before?" section fills from the log in minutes — compare with the incident timeline, which captures the day of, not the months before.
• A record for the day you're not there. When the solo operator takes two weeks off, the log plus the authority matrix lets the person covering make the small calls and hold the big ones — without re-deciding forty things from scratch.