Stakeholder alignment

Stakeholder Alignment

Decisions fail more often in the alignment than in the logic. A good RFC or decision doc does two things: makes the best argument for the chosen path, and makes the roles of everyone affected explicit so no one is surprised.

Pick the right artifact

Artifact	When to use	Length
RFC / design doc	Technical decision affecting multiple teams; invites comment	3-10 pages
Proposal	Bet on a direction that requires budget/headcount/scope	1-3 pages
Pre-read	Input for a scheduled decision meeting	1-2 pages
Decision doc	Record a decision that has been made (or is being made now)	1 page
One-pager	Early alignment on an idea before full RFC	1 page

Use the smallest artifact that produces alignment. A 10-page RFC for a two-team change is over-investment; a Slack thread for a 10-team change is under-investment.

RFC / design doc structure

# [Title] — [state: Draft / Reviewing / Accepted / Rejected / Superseded]

## BLUF
[One-paragraph summary: the problem, the proposed direction, the ask.]

## Roles (DACI)
- **Driver:** [who writes + shepherds]
- **Approver:** [who makes the final call — name, not group]
- **Contributors:** [who provides input]
- **Informed:** [who needs to know]

## Context
[Shared understanding. What led here. Keep controversial claims for later sections.]

## Problem
[What we are trying to solve. Why now.]

## Options considered
- Option A: [name] — [one paragraph] — pros / cons / rough cost
- Option B: [name] — [same]
- Option C: do nothing — [same]

## Recommendation
[Chosen option + why, in one paragraph.]

## Trade-offs
[What we are giving up. What we are not solving. Second-order effects.]

## Open questions
- [ ] [Question needing input] — @person
- [ ] [Assumption needing validation] — @person

## Plan
[Milestones with dates. Dependencies on other teams.]

## Appendix
[Supporting material, benchmarks, prior discussions.]

Variations: for short changes, collapse Options / Recommendation into one section. For contentious changes, expand Trade-offs with a pre-mortem.

Worked examples and short-form variants in references/rfc-design-doc-templates.md.

Role assignment — DACI vs RAPID

Both frameworks make roles explicit. Pick one and use it consistently across the org.

DACI

Role	Meaning
Driver	Shepherds the decision. Writes the doc, runs the meeting.
Approver	Makes the final call. Usually one person.
Contributors	Provide input. Their concerns must be addressed; they do not have veto.
Informed	Need to know once the decision is made.

RAPID

Role	Meaning
Recommend	Proposes the decision.
Agree	Formal sign-off required (legal, security, etc.).
Perform	Executes once decided.
Input	Consulted. Not a veto.
Decide	Makes the call.

Rules:

• One Approver / Decider. If two people share the role, you do not yet have a decision process.
• Name, not team. "Platform Engineering" is not an approver. "Sarah Kim (Platform)" is.
• Contributors ≠ vetoers. Disagreement is logged, not blocking.
• Publish roles before the debate, not after. Otherwise roles migrate to favor the person who shouts loudest.

Pre-reads

A pre-read makes a 30-minute decision meeting take 10 minutes.

Structure:

1. The decision being made — one sentence.
2. Options with crisp summaries — ≤2 paragraphs each.
3. Recommendation — with confidence.
4. What we need from the meeting — specific, actionable, under 3 items.

Sent 24-48 hours before the meeting. If the meeting still takes 30 minutes, either the pre-read was bad or the decision was not yet decision-ready.

Decision docs

A decision doc captures a decision AFTER it has been made. Purpose: future reference, onboarding, accountability.

# Decision: [title]

**Date:** [YYYY-MM-DD]
**Decider:** [name]
**Status:** Accepted / Superseded by [link] / Reversed

## Context
[Why a decision was needed.]

## Decision
[What was decided, in one paragraph.]

## Alternatives considered
[Brief: option → reason not chosen.]

## Consequences
[What this means going forward. What we are giving up.]

## Follow-ups
- [ ] [Action] — @owner — [date]

This is distinct from an ADR (Architecture Decision Record) which focuses on architecture specifically — see documentation-discipline for ADRs.

Escalation patterns

When alignment fails:

1. Restate the open question. "The disagreement is whether X or Y. We need the approver to decide by [date]."
2. Name the cost of delay. "Every week without a decision costs [concrete cost]."
3. Escalate the decision, not the debate. The approver decides the question; they do not re-run the debate.

Anti-Patterns

Anti-Pattern	Problem	Solution
RFC as rationalization	Doc written to justify a decision already made; readers disengage	Write the RFC before the decision; include real alternatives
Group approver	"Engineering leadership" as approver; no one decides	One named person as Approver/Decider
Missing trade-offs section	Only upsides listed; readers suspect downsides not examined	Every proposal lists what it gives up
Options theater	Option A is the real proposal; B and C are strawmen	Include serious alternatives or omit the section entirely
Consensus-seeking	Trying to get everyone to agree on everything	Decider decides while contributors contribute; disagreement is logged
Pre-reads read in the meeting	Meeting time wasted re-reading the doc	Send 24-48 hours before; if not read, doc was too late or too long
Missing kill condition	No clause for what evidence would reverse the decision	Add "We will reconsider if [specific measurable outcome]"
Decider named after debate	Roles migrate to favor whoever speaks loudest	Publish roles before the debate
Contributors treated as vetoers	Individual contributors block progress	Contributors provide input; they do not have veto power

Workflow

1. Pick the artifact. RFC, proposal, pre-read, decision doc, one-pager — by scope and audience.
2. Assign roles before writing. DACI/RAPID. Name, not team.
3. Draft BLUF. One paragraph. If you can't write it, you're not ready.
4. Write the options section honestly. Include "do nothing." Real trade-offs.
5. Recommend with confidence + trade-offs.
6. Send for comment with an explicit deadline and the ask. "Comments by Friday. I need approval from [Approver] by the 15th."
7. Record the decision. If not already the doc's purpose, create a decision doc.

References

File	Contents
references/rfc-design-doc-templates.md	RFC templates (short + long), variants per decision type, naming conventions
references/daci-rapid-cheatsheet.md	Full DACI and RAPID specs, role-assignment rules, common mistakes
references/alignment-playbooks.md	Pre-read checklist, escalation patterns, async alignment vs sync meeting trade-off

Related skills

• structured-writing — the BLUF at the top of the RFC.
• clarity-editing — make the RFC readable.
• documentation-discipline — decide whether this decision deserves an ADR.
• visual-communication — architecture diagrams inside the RFC.
• trade-off-analysis — the Options section is a trade-off matrix.
• storytelling-for-stakeholders — for investor decks and board materials (narrative-heavy).