Writing RFCs and Decision Documents That Drive Alignment

A decision document drives alignment when it names a single decision-maker, states a recommendation instead of a menu of options, and records why alternatives were rejected — then gets timestamped into a record people can actually find later. Match the format — one-pager, RFC, or full spec — to how contested and reversible the decision is.

Quick answer: Escalate the format to match the stakes: a Slack thread for reversible calls, a one-pager once more than a few people must agree, an RFC when the technical or strategic approach is genuinely contested. Whatever the format, it only works if it names a decider, states a recommendation, and gets dated into a record you can still find in six months.

When a Slack Thread Stops Being Enough

A Slack thread stops being enough the moment a decision needs to survive the people who made it — when more than a handful of stakeholders must agree, the choice is expensive to reverse, or someone will reasonably ask "why did we do this" months later. That's the moment to escalate to a written one-pager or RFC.

Jeff Bezos's well-known distinction between one-way and two-way doors — from his 2015 Amazon shareholder letter — is the cleanest test for how much formality a decision deserves.

A two-way door — reversible, cheap to undo — rarely needs more than a quick thread and a judgment call. A one-way door, like a schema migration or a vendor commitment, deserves a document: the cost of getting it wrong, or forgetting why you chose it, is much higher.

The mistake runs in both directions. Over-formalizing a reversible call wastes a week on a document nobody needed. Under-formalizing an expensive one leaves the reasoning trapped in a thread that scrolls away, forcing a re-litigation the moment someone new joins the project.

This escalation ladder isn't a bureaucratic ritual — it's a filter. The document should always match the actual risk, not the seniority of who's asking or the anxiety of the moment. A director asking a casual question doesn't need an RFC; a junior engineer proposing an irreversible data migration does.

Anatomy of a Decision Document That Actually Resolves Something

A decision document resolves something when it contains a narrow problem statement, one clear recommendation, the alternatives seriously considered and why they lost, who's affected, and a named decision-maker with a deadline. Skip any of these and the document becomes a discussion starter instead of a decision-closer.

Five elements separate a technical document that actually converges a room from one that just restates the disagreement in writing — and they hold whether you're writing a formal RFC or a lighter one-pager:

1. A problem narrow enough to resolve in one sitting. "How should we handle idempotency in the payments retry queue" gets decided. "How should we think about reliability" does not.
2. One recommendation, not a menu. Three options with no pick invites bikeshedding — the room debates your indecision instead of your reasoning.
3. Alternatives considered, and explicitly why they were rejected. This is what makes the decision defensible later, when someone asks "did we think about X?"
4. Blast radius. Which teams, services, or customers are affected if this ships — vague enough that people miss it, specific enough that they can't dismiss it.
5. A named decision-maker and a deadline. Without both, the review runs forever and the loudest voice wins by default.

Name the Decider Before You Write a Word

Most stalled decision documents fail here first: nobody was ever assigned to actually decide, so "review" becomes an open-ended debate with no mechanism to close. The RAPID framework — Recommend, Agree, Perform, Input, Decide, from Bain & Company's Marcia Blenko, Michael Mankins, and Paul Rogers — solves this by assigning exactly one person the "D," the Decide role.

Everyone else Recommends, gives Input, or is simply Informed. Atlassian's widely used DACI model — Driver, Approver, Contributors, Informed — is the same idea under different letters.

Naming the decider before you draft changes how you write: you're no longer building consensus among ten equal voices, you're giving one accountable person what they need to decide well.

Grounding the blast radius in a specific, concrete moment — not just "affects three services" — is what makes the stakes legible to a non-technical reviewer. The same discipline behind mapping a customer journey, pinpointing exactly where in the experience something breaks, works just as well inside a technical decision document as it does in a stakeholder deck.

The Recommendation Comes First, Not Last

State the recommendation in the first three sentences. If a reviewer has to scroll to find out what you actually think, the document has already failed its real job. This is the same discipline behind the executive communication pyramid: lead with the conclusion, and let the supporting argument follow underneath it, not the other way around.

That discipline extends to the problem statement itself. A problem framed only in technical terms ("we need a caching strategy") lands weaker than one tied to the job it actually affects — the approach behind Jobs to Be Done applies just as well to a technical RFC as it does to a feature brief. "This caching decision affects how fast a customer can complete checkout" gives a non-technical decider something real to weigh.

Running the Review Without Losing the Room

A review fails when it either drags on with no resolution or gets rubber-stamped because nobody actually read it. The fix is structural: a fixed comment window, a named place for dissent, a premortem before the deadline, and an explicit rule for what happens if consensus doesn't form in time.

Set a Deadline, Not an Open Door

Set the window up front — "comments close Friday at 5pm" — and put it in the document itself, not just the calendar invite. An open-ended review is the single most common reason decision documents die slowly instead of resolving quickly.

Surface Dissent Before the Deadline, Not After

Before the deadline, run a premortem: a technique from psychologist Gary Klein's 2007 Harvard Business Review article "Performing a Project Premortem." Ask reviewers to imagine the decision failed spectacularly and write down why, before it's locked in. It surfaces objections people otherwise hold back live, where disagreeing with a confident recommendation feels socially costly.

Written, asynchronous review also tends to surface better dissent than a live meeting, simply because it removes the pressure to agree out loud in the room. GitLab's publicly published team handbook — one of the most cited examples of "handbook-first," asynchronous documentation culture in remote engineering orgs — treats the written record as the default over a meeting, precisely because a comment thread with a date attached survives in a way a conversation doesn't.

A few habits keep the review itself efficient:

• Reply inline, not in a new thread. A comment tied to the specific sentence it objects to is easier to resolve than a general "I disagree" in Slack.
• Distinguish blocking objections from preferences. Not every comment needs resolution before the deadline — only the ones that would actually change the recommendation.
• Keep the language plain enough that a non-specialist reviewer can object intelligently. Jargon-heavy writing doesn't just slow reviewers down — it hides weak reasoning behind vocabulary, the exact failure mode our guide to PM writing clarity is built to prevent.

If the deadline arrives and disagreement remains, the named decider from the RAPID or DACI model makes the call and states it plainly. That's not a failure of the process — it's the process working as designed.

Common Failure Patterns That Kill Alignment, Even With a Good Template

Most decision documents fail for a handful of repeatable reasons: no recommendation, no deadline, scope too broad to actually resolve, or a document nobody formally closes once the decision lands. Naming the pattern is usually enough to fix it, since each one traces to a specific structural gap.

• The menu, not a recommendation. Three options, no pick. This isn't neutrality — it's the author avoiding accountability for the judgment call they were supposed to make.
• The zombie doc. No deadline, so the document lingers half-adopted for months, quietly used as the excuse for two contradictory implementations.
• Decision by silence. Nobody objected because nobody read it before the deadline — that's absence of dissent, not agreement, and it collapses the first time someone actually reads it after the fact.
• The data-appendix ambush. Burying the real ask behind fifteen charts instead of naming it in the first paragraph. Whether a decision leans on a data appendix or a narrative argument should be a deliberate choice, not a default — our guide to narrative vs. data presentation covers when each actually persuades.
• Scope creep inside the document itself. An RFC meant to settle one schema question quietly turns into a re-litigation of the whole roadmap, because nobody enforced the narrow-problem rule.

A decision document that presents three options and no recommendation isn't neutral — it's the disagreement, restated in a nicer font.

Making the Decision Durable: Closing the Loop So the Record Survives

A decision document isn't finished when the debate ends — it's finished when the outcome is dated, archived somewhere findable, and distilled into a record someone can locate months later without pinging the author. Closing the loop is a discrete, often-skipped step, and skipping it is exactly why old decisions get silently re-litigated.

The Architecture Decision Record (ADR) pattern, formalized by Michael Nygard in 2011, is the standard shape for this: one short page per decision, stating the context, the decision, and the consequences, filed where a future engineer will actually find it, not buried in a closed thread. A decision document doesn't need to become an ADR specifically, but it does need an equivalent: a short, dated, findable summary of what was decided and why.

Write the Reasoning Down Before You Know the Outcome

Author and decision researcher Annie Duke's concept of a decision journal, from her book Thinking in Bets, applies the same logic to the reasoning itself. Writing down what you decided, why, and how confident you were — before you know the outcome — is what protects you from resulting: judging a decision by how it turned out rather than by how sound it was at the time.

A dated record written in the moment can't be quietly rewritten by hindsight later. That same principle is why written records outlast meetings in the first place — a point our guide to PM communication and influence makes about status updates and stakeholder presentations applies just as directly here: a decision that only lives in someone's memory gets re-litigated the moment that person is on vacation, changes teams, or simply misremembers.

Where Prodinja Fits

This is the specific gap Journals in Prodinja is built around: a place to capture a decision or a difficult conversation's reasoning — including real voice capture — at the moment it happens, rather than reconstructed from memory during a review nobody prepared for. Logging the why right after a contested RFC closes is what turns "we talked about this once" into an entry you can actually point back to, dated and specific.

On the written side, Spec Studio's PR-style diffs are designed to make a decision's evolution traceable the same way engineers already expect from code review. When an RFC's outcome gets folded into the spec, a reviewer can see exactly what changed, when, and in whose proposed edit, instead of re-reading the whole document hunting for what's different.

Key Takeaways

• Match the format to the stakes, not the habit. A reversible, low-stakes call needs a thread; an expensive-to-reverse one needs a written document — Bezos's one-way/two-way door test from his 2015 shareholder letter is a fast way to tell which.
• A recommendation beats a menu. Three options with no pick invites bikeshedding instead of resolving anything; state your recommendation in the first three sentences.
• Name the decider before you draft. RAPID or DACI assigns exactly one accountable "D" or Approver — without it, review runs forever and the loudest voice wins by default.
• Run the review on a clock. A fixed comment window, a premortem before the deadline, and an explicit tie-breaker rule keep a review from dying slowly or getting rubber-stamped.
• Watch for the repeatable failure patterns. The zombie doc, decision-by-silence, and the data-appendix ambush all trace back to a missing recommendation, deadline, or narrow scope.
• Closing the loop is a separate step from deciding. A dated, findable record — an ADR-style summary or a decision journal entry — is what prevents hindsight from quietly rewriting why a call was made.
• The record matters as much as the writing craft. A brilliantly structured RFC that nobody can find in six months has already lost most of its value.