The Decision Survived. The Judgment Didn't.
How to Build a One-Page Decision Record Before the Reasoning Disappears (EO-004 | Executive Override)
What Should a Good Decision Record Include?
Plain-English premise: A decision can ship, get approved, and sit on the roadmap for years while the judgment behind it, the evidence, the alternatives, the accepted downside, disappears completely, unless someone captures it before it scatters.
👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.
Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.
Episode 3:
⚠ Tension
The decision shipped. The ticket closed. Eighteen months later, nobody in the room can say why it was made, only that it was.
🎯 Payoff
Inside: the One-Page Decision Record, a lightweight artifact built to preserve the judgment behind a decision, not just its outcome.
Nine percent! That’s the share of one dataset, 8,702 engineering chat messages, that contained anything a later reader could call a rationale. Everyone could see what got decided. Almost nobody could see why.
The Decision Survived. The Judgment Didn’t.
Every consequential decision leaves two things behind, an outcome and a judgment. The outcome is easy to keep. It’s the shipped feature, the roadmap entry, the checkbox marked “Approved.” The judgment is harder. It’s the customer evidence weighed, the constraints accepted, the alternatives considered and set aside, the dissent voiced, the downside knowingly accepted, the uncertainty nobody resolved.
The outcome remains. The reasoning scatters.
As time passes, the pieces of that reasoning don’t vanish all at once. They scatter across chat threads, meeting notes, ticket comments, team turnover, and reorganizations, and by the time the next team goes looking, what they find is the shipped feature, the roadmap entry, the approved checkbox, and a folder marked “Why?” with nothing in it.
We kept the result. We lost the judgment.
That folder is the whole problem in one image. A decision record can’t preserve everything. It can preserve more than the final answer, and right now, most teams are only keeping the final answer.
Decision Context Has More Than One Way to Disappear
Teams often treat missing context as one documentation problem. It isn’t.
Not everything missing was actually deleted.
Sometimes the judgment was never recorded. It stayed verbal, tacit, dependent on whoever was in the room. Other times it survives, just scattered, chat here, ticket there, a deck nobody opens again. Retrieval fails even when the record exists, buried under everything else written that week. A document can survive and still answer the wrong questions, the ones the writer had in mind rather than the ones a later reader actually brings to it. Records go stale too, current when written, wrong by the time anyone needs them. And the worst case: person-bound, the context walking out the door with whoever transfers, resigns, or quietly forgets what once felt obvious.
Different failure. Different fix. A new template will not repair a record nobody can find. Better search will not recover reasoning that was never captured. A retention policy will not make a stale document trustworthy. A template most directly addresses the never-recorded case. The other five failure modes need their own fixes. A single home for fragmented pieces. Better retrieval for buried ones. A revisit trigger for stale records. A transfer routine before person-bound context walks out the door. The right remedy depends on the failure mode.
Teams Record the Comfortable Parts First
Even when teams do write something down, they don’t preserve every part of the decision equally.
What flatters the decision survives. What complicates it fades.
Constraints get documented 82.7% of the time. Assumptions, 79.0%. Benefits, 69.1%. Complexity drops to 50.6%. Costs, 45.7%. Weaknesses, the actual downside of the call, just 35.8%. Constraints are recorded 2.3 times more often than weaknesses. The downside disappears first.
“We chose this because it meets the deadline” is easier to write down than “we accepted a reliability risk because the sponsor would not move the date.” This is an omission pattern, not a lie. Teams record what’s comfortable and skip what’s costly, and the skipped details are usually what a later reader needs most. A useful record has to prompt for what teams are least likely to volunteer: What downside did we accept? What serious option did we reject? What evidence would have changed the call? Where did informed disagreement remain?
Honest records expose uncomfortable choices.
Vague ones create less immediate risk.
🎒 The Move: The One-Page Decision Record
Before laying out the fields, one thing decides almost everything downstream, and it needs to be said plainly.
The biggest enemy may be documentation burden.
More complete on paper can mean less complete in practice. The natural response to an incomplete record is to add more fields. A missing alternative becomes a new field, a political misunderstanding becomes a confirmer block, a stale record becomes an extra date. Soon a lightweight memory aid turns into a miniature governance system. It looks more complete on paper. It becomes less complete in practice.
That is a credible adoption risk, not a universal law, but the numbers back it up. In a survey of 81 software-architecture practitioners, 60.5% cited insufficient time or budget as a documentation barrier, and 42% cited the absence of clear standards. Burden is not only about length; unclear practice matters too. About half of the 921 public repositories in one open-source study contained only one to five architecture decision records total. Starting the practice did not guarantee anyone kept using it. In a controlled study, a lightweight rationale record took roughly seventeen minutes to create, a useful floor to know, not a product-team standard or an ideal completion target.
The better design principle is progressive disclosure. The goal isn’t to capture everything. It’s to preserve the few things most expensive to reconstruct later. Keep the required core small, add depth when the decision earns it, and remove fields nobody maintains.
Here is that principle turned into five steps, the minimum viable Decision Memory practice, built to preserve enough judgment to reconsider the decision intelligently.
Orienting sentence: when a decision is worth remembering, capture it in five moves before the reasoning has a chance to scatter, walk out the door, or quietly go stale.
Step 1: Capture it close to the decision. Record the decision date and the record-writing date separately. A later reconstruction can still be useful, but don’t let it masquerade as contemporaneous judgment.
Step 2: Preserve the uncomfortable information. Rationale, downside accepted, serious alternatives, important uncertainty. The supportive parts are usually easier to record. These are the parts most likely to be skipped, and the ones most worth keeping.
Step 3: Keep the required core small. Decision, Context, Rationale, Downside, Status. Add depth, alternatives, reasons rejected, decision driver, evidence links, revisit condition, only when the decision justifies it. No page length or field count is empirically optimal.
Step 4: Make reconsideration normal. A record moves from Active to Superseded when a Revisit-If condition is met and something actually changed. A changed decision isn’t automatically a failed decision.
Step 5: Protect the record from misuse. The record exists to help the team remember and reconstruct what happened. It is never an audit trail for proving fault, a performance-evaluation tool, or proof that genuine deliberation occurred.
