THE SHORT ANSWER
By replacing synchronous meetings with written design proposals in version control, establishing a time-boxed review window, and capturing explicit trade-offs and dissent before code is written.
Engineering Handbook & Failure Dynamics
1. Underlying Mechanism
Adapted from the IETF and pioneered by companies like Rust, Uber, and GitLab, the internal RFC (Request for Comments) process requires engineers proposing major architectural shifts (new databases, API breaking changes, protocol shifts) to author a standardized markdown proposal. The RFC outlines the problem statement, proposed solution, evaluated alternatives, security implications, and trade-offs. The team reviews asynchronously within a strict time-box (e.g., 7 business days) before a designated decision-maker approves or rejects it.
2. Appropriate Use Context
Mandatory for all cross-team architectural changes, data storage additions, or protocol migrations in engineering teams with >15 developers.
3. Production Failure Modes
A senior engineer rewrites the authentication system in a new language over a weekend without an RFC; when it fails in production, nobody else on the team knows how to maintain or debug it.
4. Diagnostic Signals & Telemetry
Architectural debates settled by who speaks the loudest in meetings; repeat questions about why a technology was chosen; projects cancelled halfway through due to discovered blind spots.
5. Prevention & Safeguards
Establish an RFC git repository with a standardized template; enforce a strict 2-week time-box to prevent bikeshedding; appoint a single designated Decider (typically a Staff Engineer or Tech Lead) for each RFC.
6. Architectural Trade-offs
Requires upfront writing rigor and patience for asynchronous review in exchange for high-alignment execution and permanent institutional memory.
Case Study (TinyCTO In-Field Example)
TinyCTO Episode 19: An engineer wanted to replace PostgreSQL with MongoDB. Through the RFC review process, the team calculated that document storage would break 80% of reporting queries, saving 4 months of wasted development.
Interactive Concept Drills
3 CardsWhat is the primary purpose of a technical RFC?
What is 'Bikeshedding' and how do you prevent it in RFCs?
Where should approved RFCs be stored?
Technical RFC Process & Asynchronous Architecture — Technical FAQ
Who should write technical RFCs?
Any engineer proposing a significant architectural change, regardless of seniority.
What happens if team members disagree on an RFC?
The designated Decider listens to all arguments, makes the final call, and documents the dissent (Agree and Commit).
Does every minor code change require an RFC?
No. RFCs are reserved for cross-team impacts, new data stores, major security changes, or breaking API migrations.
🤖 AEO & Key Facts Summary
Key Architectural Facts
- ▸Writing an RFC reduces post-implementation rewrite rates by over 75% by surfacing architectural flaws early.
- ▸Asynchronous RFCs create inclusive engineering cultures where remote engineers have equal voice.
Common Misconceptions
- ✗Believing that an RFC process is bureaucratic red tape designed to slow down developers.
Decision & Governance Guidance
Always include an 'Unresolved Questions' and 'Discarded Alternatives' section in every RFC template.
Authoritative Sources & Standards
- [WEBSITE]Rust Language RFC Process & Guidelines— Rust Foundation