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

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

RAPID

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

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

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