A decision log is cheaper than the mistake it prevents

The economics of a decision log are almost embarrassingly lopsided once you actually compare the two sides. Writing down why a decision was made, at the moment it's made, costs a sentence and perhaps thirty seconds of someone's attention. Not having that sentence, when the decision is questioned later, costs an investigation — tracking down whoever might remember, piecing together a plausible reconstruction, and still not being fully certain the reconstruction is right.

Why the comparison rarely gets made honestly

Because the two costs land on different people at different times. The cost of writing the decision down falls on the person making the decision, right now, when they're busy and the value feels abstract. The cost of not having it falls on someone else entirely, later — an auditor, a successor, a new manager — at a point when the original decision-maker may not even be around to feel any responsibility for the gap.

This mismatch is exactly why decision logs are chronically under-maintained even in businesses that would readily agree, in the abstract, that they're a good idea. The person paying the small cost now never experiences the large cost later, so there's no natural feedback loop pushing the habit to stick.

What a decision log actually needs to contain

Not a lot. The value comes from consistency and specificity, not length.

What was decided. Stated plainly, without hedging — the actual choice made, not a description of the options considered.

Why, in the decision-maker's own words, at the time. Not a polished justification written for an imagined future reader — a genuine, brief account of the reasoning as it existed in the moment.

What would change the decision. A short note on the conditions under which this choice should be revisited is often the single most valuable line in the entry, because it turns a static record into something someone can actually act on later — see the exception that made sense once and confuses everyone now.

Why this works better as a habit than a project

Treating this as a documentation project — go back and log every past decision — is exhausting, low-value, and usually abandoned halfway through, because most past decisions aren't worth reconstructing and the ones that are worth it are the hardest to reconstruct accurately.

Treating it as a habit — log the decision the moment it's made, going forward — costs almost nothing per instance and compounds. A year of consistent thirty-second entries produces something genuinely valuable. A one-off attempt to backfill years of history produces something incomplete and unreliable, because the details that matter most have already started to fade — see institutional memory has a shelf life.

Where to start, realistically

Not everywhere. Start with the categories of decision most likely to be questioned later: pricing exceptions, supplier terms, write-offs, anything that deviates from a standard, documented process. Routine decisions within an established process don't need this — the process itself is the record. It's specifically the judgement calls, the one-offs, that benefit from a sentence attached at the time.

Making it actually happen

Attach the log entry to the approval step, not a separate system. If writing the reason is a required field at the point of approving an exception, it happens because it's part of the workflow, not because someone remembered a separate best practice.

Keep the bar low. A one-sentence reason beats a three-paragraph justification nobody has time to write, because the one-sentence version actually gets done consistently and the longer version gets skipped under deadline pressure.

Review a sample periodically, not to police it, but to confirm the habit is actually producing something useful — and to catch cases where the reason logged is too vague to be worth anything to a future reader.

Common questions

Why is a decision log worth the effort if most decisions turn out fine anyway?

Because the cost asymmetry is extreme — writing a reason down takes seconds, while reconstructing it later, once it's needed, can take hours and still produce an uncertain answer. You don't need every decision to be questioned later for the habit to pay off; only a small fraction ever will be, but you can't know in advance which ones.

Why do decision logs often fail even when everyone agrees they're a good idea?

Because the cost of maintaining the log falls on the person making the decision, immediately, while the benefit is felt by someone else, much later — often after the original decision-maker has moved roles or left. That mismatch removes the natural pressure that would otherwise keep the habit alive.

What should a decision log entry actually include?

Three things, briefly: what was decided, why it was decided in the decision-maker's own words at the time, and what circumstances would justify revisiting it. Length isn't the goal — a genuine, specific sentence beats a polished paragraph that took too long to write and therefore never gets written consistently.

Should a business try to backfill a decision log for past decisions?

Generally not as a big project — most past decisions aren't worth reconstructing, and the details of the ones that are worth it have usually already started to fade from memory, making the reconstruction unreliable. It's far more effective to start the habit going forward, focused on decisions being made right now.

Related: the exception that made sense once and confuses everyone now · institutional memory has a shelf life · configuration without a reason attached