Technical RFCs
Democratizing architectural decisions through Request for Comments (RFCs). Any engineer can propose a change, fostering rigorous debate and collective ownership of the system design.
Writing is Thinking
Architecture should not be handed down from an Ivory Tower. The best systems emerge when decisions are debated openly, with context and trade-offs clearly articulated in writing.
I implement a structured RFC in the form of engineering roundtables and close pairings of engineers and architects where any engineer, junior or senior - can propose a significant change. This forces clarity of thought, creates an asynchronous decision trail, and ensures that we build the right thing, not just the easy thing.
The RFC Lifecycle
- 1.Draft: Author defines the problem, proposed solution, and alternatives.
- 2.Comment: Team reviews asynchronously./
- 3.Review: Roundtable discussion to resolve discussions and plans.
- 4.Decision: Adopted, Rejected, or Deferred.
Why It Matters
Knowledge Sharing
The process itself educates the team. Junior engineers learn from senior feedback, and senior engineers get fresh perspectives.
Historical Context
"Why did we build it this way?" The RFC serves as a permanent record of the constraints and trade-offs accepted at the time.
Asynchronous Scale
Allows distributed/remote teams to contribute to decisions without needing synchronous "all-hands" architecture meetings.
