How to Preserve Decision Rationale

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:

How to Close the Decision Before You Close the Meeting

⚠ 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.

Constraint: This is an editorial design choice built for lightness, not a validated standard. Capture the required core, Decision, Context, Rationale, Downside, Status, within the same working session as the decision whenever possible, before the reasoning has a chance to fade. One page is the target, not a proven optimum.

Done state: The record lives where the team already works, carries both a decision date and a record-writing date, and is marked Active with a stated Revisit-If condition.

Limitation: This record cannot supply missing decision rights, prove deliberation actually occurred, or guarantee anyone reads it before the next relitigation. It preserves enough judgment for a later reader to reconsider the decision intelligently. It does not lock the decision, and it is not a substitute for the authority to make one.

---

🖊 What Holds Up Under Pressure

Primary claim label: DESIGN INFERENCE (precedent) / EVIDENCE (Falessi study)

I trust the shape of the ADR tradition more than I trust any specific field count inside it. That’s a judgment call, not a finding, so here’s what it’s built on.

Basis: Structured decision-rationale records have real professional lineage. Tyree and Akerman proposed a structured architecture decision description in 2005. Nygard’s lightweight five-part Architecture Decision Record followed in 2011. MADR expanded the format with optional fields. By 2025, GOV.UK had built ADRs into institutional practice. Researchers have identified ADRs in 921 public repositories.

Precedent proves use. It doesn’t prove results. That’s the one substantive challenge to my own claim. Adoption tells us practitioners found the format worth trying. It doesn’t tell us the format works. Of the thirteen elements proposed for the One-Page Decision Record, nine have direct precedent in the ADR tradition, three have partial precedent, and one is an editorial adaptation built for a product-leadership audience rather than a software-architecture one. No field count in that mapping has been validated as optimal.

Limitation: What I’ll stand behind is narrower than the pattern itself. The structure is worth building on. Whether this specific field count is right is still an open question, and I’m treating it as a starting design, not a proven one. We can borrow the pattern. Not the certainty.

The Falessi study is the closest thing to a controlled test of the underlying claim, and it deserves to be reported straight before anyone draws a conclusion from it.

Basis: Falessi, Cantone, and Becker tested 50 postgraduate participants working in 10 teams through an artificial software-architecture scenario. The measured outcome was correctness on a later design judgment, evaluated against the study’s own defined answer, not a review of whether the original decision was good. With written rationale available, individual correctness was 86% versus 64% without it, a 22-point gap. Team correctness was 67% versus 11%, a 56-point gap. The study found no significant time advantage for the rationale condition.

Counterpoint: No independent replication of that result has been located, and a separate 65-person study comparing structured against narrative documentation formats found no advantage for either, though that study tested format against format, not rationale against no rationale. One study, run once, in one artificial scenario, cannot establish a general effect.

In my own work, written rationale rarely ended the next debate faster. It changed the debate from “Why did they do this?” to “Are the conditions that justified it still true?”

Limitation: The claim I’ll stand behind is this. Written rationale can help a later reader reconstruct why a decision made sense, in the narrow sense the Falessi study measured. It comes from software architecture and engineering design, not from direct product-management outcomes, and a real aerospace design-rationale record in separate field research answered only 41% of the questions later readers actually asked it. Nothing in this evidence validates one page, a specific field count, a named confirmer, or the complete artifact this article proposes. Optimize for better reconstruction. Don’t promise faster reading. Don’t confuse format with value.

---

🛑 Do Not Use When

A decision record is only as safe as what people believe will happen to it after they write it. A decision record is memory insurance, not truth serum. The page preserves what people felt safe enough to write.

• The record culture treats candor as a liability. Used for learning, a record is written close to the decision, team-authored, process-focused, allows uncertainty, treats supersession as normal, and stays separate from performance review. Used for blame, the same fields get written after the outcome, reflect the known executive preference, expose named people, get pulled into reviews, and treat completion as compliance and disagreement as failure.

• More words does not mean more candor. The highest-severity misuse, turning the record into a performance-evaluation or blame artifact, is manageable only by keeping this practice narrow.

[Candidate personal-signal insertion point: a real, specific instance where you saw a decision record get pulled into a performance review or a blame conversation would land hard here. One sentence, real, would outweigh the rest of this paragraph.]

• A named confirmer is being asked to do more than confirm. The optional confirmer field verifies that the record reflects the decision as understood at the time. It is not the person to blame, not proof everyone agreed, and not a validated safeguard. If leadership wants it to do more than that, don’t add the field.

• The decision is low-stakes. Backlog swaps, minor copy changes, routine status syncs. A full record there is documentation theater with a nicer format.

---

Decision Logged: The One-Page Decision Record

Decision: ________

Context: ________

Rationale: ________

Downside accepted: ________

Status: Active / Superseded Superseded by: ________

Revisit if: ________

Decision date: ________ Record-writing date: ________

Optional when the decision justifies it: Alternatives considered / rejected: ________ Decision driver: ________ Evidence links: ________

This is the full one-page receipt for the series, context, options, decision, owner, sign-off, in one place. Unlike EO-003’s Meeting Capture Strip, this record isn’t meant to be read aloud in sixty seconds. It’s meant to still make sense in eighteen months.

---

This Week

3 actions for the product lead:

• Pick one decision made in the last two weeks that you’d hate to have to explain in a year, and write its One-Page Decision Record today, while the reasoning is still fresh.

• Fill in the downside field first, before the rationale field. It’s the one most likely to get skipped.

• Store the record where the team already works, attached to the ticket, the roadmap item, or the doc that governs the decision, not in a private notebook.

1 action for the leader in the room (the decision owner or approver): Confirm the record reflects the decision as you understood it at the time, not as proof everyone agreed, and not as a performance review.

1 action to improve decision traceability today: Set a real Revisit-If condition on one existing decision that currently has none, so its next status change is a choice instead of a surprise.

[Candidate personal-signal insertion point: if any of these three actions is one you actually do, or wish someone had told you to do five years ago, say so directly here in one line.]

---

One-Page Decision Record Field Kit

The One-Page Decision Record Field Kit is the fourth unlock in the Decision Memory Field Kit, the free seven-part toolkit this series builds one asset per issue. It gives product leads a lightweight, screenshot-safe record for preserving the judgment behind a consequential decision. What was decided, the context that shaped it, the rationale, the downside knowingly accepted, current status, and the condition under which it should be revisited, with room to add alternatives, a named decision driver, and evidence links when the decision earns that extra weight. It is built around a hard boundary. This is memory insurance, not a performance-evaluation tool, and it is designed to resist becoming one. The kit includes the full field set, the five-step capture sequence, the misuse boundary, and a worked example distinguishing a record built for learning from one that’s quietly become a blame artifact.

Decision Record One-Pager

368KB ∙ PDF file

Download

The **Decision Record One-Pager** is the fourth unlock in the Decision Memory Field Kit, a practical tool for preserving the judgment behind an important decision before that judgment scatters across meetings, chat threads, tickets, and team turnover. It is designed for decisions that cross teams or customer commitments, accept a meaningful tradeoff, or would be costly or awkward to reverse or explain later. The opening page gives readers a simple test: would someone reasonable ask, “Why did we do this?” within six months? When at least two of those conditions are true, the decision deserves a durable record. The working page captures the full decision story in one place: * what was decided, * the context or forcing function behind it, * the options that were considered, * why one option won, * the downside knowingly accepted, * the current status, * who owns the decision, * when the decision was made, * when the record was written, * what condition should trigger reconsideration, * and who confirmed that the record reflects the decision as understood at the time. It also includes optional space for rejected alternatives, the decision driver, and supporting evidence links when the decision earns that additional depth. The prompt to complete **Downside Accepted** before polishing the rationale is especially valuable because teams tend to preserve the comfortable parts of a decision more readily than the risks, costs, and compromises that later readers most need to understand. This is not another approval form or miniature governance system. It is intentionally lightweight, evidence-informed, and designed to remain usable in the real environments where decisions are made. A decision can be marked **Active** or **Superseded**, connected to the decision that replaced it, and paired with a clear **Revisit If** condition so reconsideration becomes a normal response to changed evidence or constraints rather than an admission of failure. The most important value of the One-Pager is not that it prevents disagreement. It gives future disagreement a more accurate starting point. Instead of asking, “What were they thinking?” the next team can ask whether the original evidence, constraints, and accepted tradeoffs still hold. Its boundary is visible on the artifact itself: > **This record is memory insurance, not truth serum.** It is not an audit trail, a performance-evaluation tool, or proof that genuine deliberation occurred. Used properly, it preserves enough judgment for a later reader to reconsider the decision intelligently without turning the people involved into defendants. I am gifting the complete **Decision Record One-Pager** so readers can move directly from the article’s argument into practice. It can be used for the next consequential product decision, attached to the ticket or roadmap item that governs it, and kept where the team already works. The goal is simple: when the decision survives, the reasoning should not have to disappear with it.

Download

---

📎 Forward This

The decision survived. The judgment didn’t. A one-page record, written close to the decision and kept separate from performance review, is what preserves the reasoning after the outcome is all that’s left.

Next week, Executive Override moves from the durable record to the limits of any template. EO-005 introduces the Decision Reflection Card Field Kit, naming the conditions no framework can fix, missing decision rights, leadership bad faith, and incentive systems that reward churn.

That same operating belief sits at the heart of my upcoming book, Collaborate Better. Better collaboration isn’t louder agreement. It’s the discipline of naming tradeoffs and owning next steps out loud. Learn more at CollaborateBetter.us.

---

⬅ Closing

A useful decision record doesn’t lock the decision. It preserves enough judgment for the next team to reconsider it intelligently.

Small core. Honest limits. Safe use.

Regards,

Mark 👋

Citations and Research Binder

3.74MB ∙ PDF file

Download

This Citations and Research Binder supports **Executive Override Episode 004: The Decision Survived. The Judgment Didn’t.** It gathers the research behind the article’s claims about decision rationale, organizational memory, incomplete and fragmented records, retrieval failure, person-bound context, stale documentation, omission asymmetry, accepted downside, rejected alternatives, Architecture Decision Records, later-reader reconstruction, documentation burden, progressive disclosure, supersession, revisit conditions, attribution, blame risk, and the conditions that determine whether a decision record remains useful after the original participants, constraints, and assumptions are no longer available. It also defines the argument’s limits: the article does not claim that every final decision is preserved while only the rationale disappears, that decision records reliably improve the quality of the original decision, that written rationale makes later review faster, that ADR adoption proves effectiveness, that findings from software architecture and engineering design transfer directly to cross-functional product decisions, that one page is empirically optimal, that any particular field count has been validated, that a named confirmer improves candor or prevents distortion, that non-punitive language eliminates blame-driven omission, that documentation prevents turnover loss, relitigation, executive override, or poor judgment, or that the complete One-Page Decision Record has been validated as an integrated product-management intervention. The distinction between Decision Date and Record-Writing Date, the five-step Minimum Viable Decision Memory Practice, the required core and optional-depth field structure, the Revisit-If condition, Active and Superseded status, and the rule that the record remain separate from performance evaluation are treated as evidence-informed design choices rather than established optima. The binder exists to show what the evidence supports, what remains contested or indirect, and how teams can distinguish a durable outcome from recoverable judgment, professional precedent from demonstrated effectiveness, better reconstruction from faster review, a useful memory aid from an audit trail, and a record built for reconsideration from one quietly repurposed for blame.

Download

Previous:

More Content to Discover: