staff-engineering · staff
Technical RFCs That Ship
Quick answer
A technical RFC proposes a change that needs multi-person agreement before code freezes the design. It is not a novel and not a rubber stamp. Staff engineers write RFCs to surface risks early, collect the right reviewers, and produce a decision that can become an ADR when accepted.
Why this matters
- Cross-team work fails quietly without a shared artifact.
- Async critique beats calendar-only design meetings.
- RFCs create a paper trail for compliance and onboarding.
- Interview stories about influence often are RFC stories.
Learning objectives
- Choose RFC vs ADR vs ticket.
- Structure an RFC for busy reviewers.
- Run a review window without infinite debate.
- Convert accept/reject into ADRs and rollout plans.
- Avoid RFC theater.
Explain like I am 5
Before building a big Lego tower with friends, draw the plan so everyone can say “that wall will fall” before you glue the bricks.
Mental model
sequenceDiagram
participant Author
participant Reviewers
participant Decision
Author->>Reviewers: RFC draft (problem + design)
Reviewers->>Author: Comments / risks
Author->>Reviewers: Revision
Reviewers->>Decision: Accept / revise / reject
Decision->>Author: ADR + implementation plan
| Artifact | When |
|---|---|
| Ticket | Local implementation task |
| RFC | Cross-team or high-blast-radius design |
| ADR | Decision is accepted and durable |
| Runbook | How to operate after ship |
Core concepts
Problem first
Open with user/system problem, success metrics, non-goals, and constraints. Designs without problems attract bikesheds.
Audience and reviewers
Name required reviewers (security, platform, owning teams) and optional FYI. Infinite open review is not a process.
Design sketch, not implementation dump
Enough architecture for risk discovery: components, data flow, failure modes, migration, observability. Link prototypes; do not paste 2k lines.
Risks and rollout
Call out security, data loss, cost, operability, and rollback. Prefer phased delivery with kill switches.
Decision SLA
State the review window (e.g. 5 business days) and the decision forum (async approve, architecture review, or tech lead triad). Silence is not consent unless you defined it that way.
Worked example
Title: Regional active-active for ledger reads.
Problem: Read latency from a single region exceeds SLO for EU users.
Proposal: Async replica + sticky routing; writes stay primary region for v1.
Risks: Stale reads on conflict windows; operational load of dual-region failover drills.
Reviewers: Payments platform, SRE, security.
Outcome: Accepted with mandatory staleness budget in API docs → ADR-0042.
Trade-offs
| RFC for everything | Code without RFC |
|---|---|
| Slow small changes | Surprise blast radius |
| High alignment | Tribal design |
Staff default: RFC when ≥2 teams, data model change, security boundary, or hard-to-reverse infra.
Failure modes
| Mode | Mitigation |
|---|---|
| RFC as finished novel | Keep under ~3–5 pages |
| Debate forever | Decision date + owner |
| Rubber-stamp culture | Require dissent notes |
| No implementation link | Ticket epic + ADR on accept |
| Hidden stakeholders | RACI on first page |
Interview mode
Skeleton: “I use RFCs to make multi-team change safe—problem, design, risks, rollout, named reviewers, and a decision path that becomes an ADR.”
Knowledge check
Align stakeholders on a design and risks before shipping a cross-team change
Replace all code comments
Store only final decisions forever without options
Avoid security review by writing longer docs
Related
By Shubham Jain