Rethinking the RFC Review Process

RFCs (Request for Comments) are the backbone of technical decision-making. They’re how teams reason about architecture, share context, and align on direction before writing code. But a process designed to bring clarity can easily turn into one that creates confusion, especially when too many people are involved, or when expectations aren’t clear.

Recently, I’ve been reflecting on how our RFC review process could be more effective. In my experience, the best review processes tend to be simple, structured, and built on trust.

Start Small and Validate Early

Every RFC should begin with a quick pairing between the author and someone a level above – usually a tech lead or senior engineer. The goal is to validate the idea, make sure it’s technically feasible, and identify any major red flags.

This early feedback loop helps authors refine their proposals before wider review, and prevents wasted cycles on ideas that aren’t ready for a full audience yet.

Separate Async Review from Live Discussion

Once the document is ready, it should go out for asynchronous feedback. Everyone gets time to read and comment thoughtfully. Live review meetings should then focus on discussion and decision-making, not on reading the document for the first time.

If people join a live review without reading the RFC, the meeting often becomes unproductive. The author ends up walking through the basics instead of resolving open questions. A good rule of thumb is that live reviews are for alignment, not discovery.

To make that possible:

• Share the RFC at least 48 hours before the meeting.
• Highlight key areas and open questions.
• Keep attendance limited to decision-makers and stakeholders.

Keep It Lightweight but Consistent

A good review process balances structure with agility. Here’s a simple model that works:

1. Feasibility Review: Author pairs with a senior engineer or lead to validate direction.
2. Team Review: Share with the team for async comments and optional live discussion.
3. ARB Review: Present to the Architecture Review Board only if the project spans multiple teams or introduces new systems.

Each review phase has a clear purpose and audience. This avoids the “too many chefs in the kitchen” problem, where ownership gets diluted and authors struggle to keep everyone aligned.

Focus on Decision, Not Consensus

The goal of an RFC review isn’t to achieve universal agreement – it’s to make a well-informed decision. That requires clear roles and boundaries. Every RFC should have:

• A small, defined review group
• A clear approver or DRI
• A timeboxed review window (e.g., five business days)

After that, the author can move forward unless major blockers are raised. This encourages accountability and momentum while still leaving room for feedback.

Build a Supportive Review Culture

Process only works if the culture behind it is healthy. Reviews should feel collaborative, not adversarial. Reviewers should aim to understand the author’s intent before critiquing the details. Authors, in turn, should be open to feedback and focus on improving clarity and trade-offs, not defending their original idea.

When the culture is right, RFCs become more than documentation – they become a shared way of thinking.

Closing Thoughts

A good RFC review process doesn’t need to be heavy or bureaucratic. It just needs to be clear. The right process should empower authors, bring clarity to reviewers, and make decisions traceable and predictable.

When we treat the process as a tool for alignment rather than control, it helps everyone move faster together.