5 exercises — RFC openings, alternatives considered, trade-offs, open questions, and implementation plans. The structure and vocabulary that drives technical consensus.
0 / 5 completed
1 / 5
An engineer is writing the opening section of an RFC. Which opening best serves the document's purpose?
An effective RFC opening must answer three questions in the first paragraph:
1. What is being proposed? "replacing per-service Redis instances with a shared Redis Cluster" 2. Why? "reduce cost by ~$4,200/month and eliminate 3 on-call failure modes" 3. What is the constraint/success criterion? "while maintaining <5ms p99 cache latency"
This matters because senior engineers and stakeholders will read the title + first paragraph and decide whether to read further. If your opening is vague, persuasive, or personal-opinion-heavy, you lose credibility immediately.
RFC opening anti-patterns: • "The author believes…" — RFCs make proposals, not personal arguments • "As you all know…" — assumes shared context, signals lazy writing • "Please read and let me know" — RFCs drive decisions, not open polls • No numbers — quantify the problem whenever possible
Standard RFC sections: • Abstract / Summary • Motivation / Problem Statement • Proposal / Design • Alternatives Considered • Trade-offs / Drawbacks • Open Questions • Implementation Plan
2 / 5
An RFC section is titled "Alternatives Considered." An engineer writes: "We considered using Memcached but rejected it." The section is weak. The most important improvement is to _____.
The "Alternatives Considered" section is often the most valuable part of an RFC — and the most commonly written poorly.
What weak alternatives sections look like: "We considered X but decided against it." → completely useless "We considered X but it didn't work." → vague and unconvincing
What strong alternatives sections look like: "We considered Memcached as an alternative to Redis Cluster. Memcached would reduce operational complexity (simpler data model) but it lacks Redis's support for sorted sets and pub/sub, which our leaderboard and invalidation features require. Additionally, Memcached does not support persistence — a hard requirement from the DBA team."
Why this matters: • It shows you thought deeply about the problem — not just the first solution you found • It prevents readers from raising alternatives in review that you've already considered • It documents the trade-off reasoning for future engineers who will ask "why didn't they just use X?" • It builds trust: reviewers can see your reasoning, not just your conclusion
The number of alternatives is less important than the depth of reasoning for each one.
3 / 5
In an RFC's "Trade-offs" or "Drawbacks" section, an engineer writes: "This proposal has no significant drawbacks." A senior engineer says this is a red flag. Why?
"No significant drawbacks" is one of the most reliable signals that an RFC hasn't been thought through carefully enough.
Every engineering decision has trade-offs. Examples of real trade-offs to acknowledge: • Increased complexity — "This adds a new service dependency" • Operational overhead — "The team needs training on the new tool" • Migration cost — "Migrating 40 services to the new API will take ~3 sprints" • Performance in edge cases — "Under extreme load >10k RPS this approach adds 2ms latency" • Vendor dependency — "We become dependent on Vendor X's support and pricing" • Reversibility — "This migration is not easily reversible"
Why acknowledging drawbacks builds trust: Readers know trade-offs exist. If you pretend they don't, readers assume you're either naive or selling something. Acknowledging limitations honestly demonstrates intellectual honesty and makes reviewers more likely to approve the proposal.
RFC vocabulary for drawbacks: "The primary trade-off is…" "One limitation of this approach is…" "This introduces a potential risk of…" "The migration cost is estimated at…" "We accept this trade-off because…"
4 / 5
An RFC includes a section titled "Open Questions." An engineer asks: "Why list things we don't know yet — doesn't that weaken the proposal?" What is the correct answer?
The "Open Questions" section is a deliberate and valuable tool in RFC writing, not a sign of weakness.
What Open Questions achieve: • Surface decisions that are genuinely unknown or contested — instead of hiding them • Invite reviewers with specific expertise to contribute ("I know the answer to Q3") • Set expectations: "This RFC is approved in principle pending resolution of Q1 and Q2" • Prevent the author from being the single bottleneck on all unknowns
Good open question examples: "Should the cluster use 3 or 5 replica shards? We recommend 3 for cost, but the DBA team should validate." "What SLA does the payments team require for cache misses? We need this to finalise the timeout configuration." "Is the security team comfortable with shared Redis for PII-adjacent data? Requires sign-off."
Bad open question examples: "How does Redis work?" (research question, not a decision) "Should we do this?" (the RFC itself answers that)
RFC vocab for open questions: "This remains an open question pending input from…" "We have not yet determined whether…" "This decision is deferred to…" "Feedback needed: …"
5 / 5
A tech lead reads an RFC and leaves this comment: "The proposal is technically sound but the RFC doesn't address the implementation plan." What is missing?
An RFC that lacks an implementation plan creates a common failure mode: it gets approved, then the team spends weeks figuring out how to actually execute it.
What a strong RFC implementation plan includes:
Phases: "Phase 1: Migrate 3 low-traffic services (Week 1-2). Phase 2: Migrate payments service (Week 3, requires Redis Cluster stable). Phase 3: Switch off old instances (Week 4)."
Owners: "Infrastructure migration: Platform team. Service-level changes: individual service owners."
RFC implementation vocabulary: "This will be rolled out in N phases, with phase 1 targeting…" "Phase 2 is gated on [condition]." "The rollback procedure is: …" "Success will be measured by: …" "Ownership: [team] is responsible for [scope]."