The hardest part of an RFC process isn’t designing the template. It’s making sure people actually use it without feeling like they’re filing TPS reports.
I’ve written before about When to Write an RFC and When Not To and how it helps in formalizing technical decisions as companies scale. This is the tactical follow-up on how to actually run the process, what makes it work, and how I’ve kept it from becoming the bureaucratic overhead that drives away good engineers or excessively slows innovation.
How It Works
The process is straightforward. When an engineer proposes a “significant technical change”, they write an RFC. A loose definition of “significant technical change” is something that crosses team boundaries, changes a contract, or would be expensive to reverse. Leaders should know what constitutes significant technical change(s) in their organization.
The document itself is a tool for thinking, not a bureaucratic hurdle. A functional template only needs to prompt for five things: the problem, the proposed solution, the “why” behind the chosen path, the discarded alternatives, and the risks. If it takes longer to document the change than it would to code it, you’re over-indexing on detail. We aren’t writing a Wikipedia entry; we’re documenting a decision-making process.
The proposing engineer (or team) owns the RFC from draft to decision. They write it, circulate it for feedback, present it at the Architecture Meeting, and update it with whatever comes out of the discussion. Ownership matters because it keeps accountability clear, the meeting informs the decision, but the engineer isn’t waiting for permission.
Those are the mechanics. The two places this process often breaks down are the draft and the roadshow. The draft is the first hurdle for the engineer; getting the thinking clear enough to write down. The second is socialization (the roadshow): getting the right people to actually engage with it before and during the meeting.
The Trap of the Silent RFC
A “Silent RFC” is effectively a dead one. It kills the engineer’s motivation when nothing happens, and it misses the real-world feedback that would have sharpened the idea. “No plan survives contact with the enemy” applies here — not because your colleagues are adversaries, but because no one person knows all the systems, dependencies, and constraints that will shape the final solution. The only way to surface those is to talk to people before the meeting, not just publish and wait.
The author is responsible for driving the feedback loop — but that doesn’t mean they should be doing it alone. Chasing busy people who have no particular incentive to engage with your document is draining, and silence is demotivating. Leaders need to actively support this: helping identify the right reviewers, making introductions across teams, and checking in when an RFC seems to be stalling. The goal is to keep momentum while the engineer does the work of synthesizing feedback into the proposal.
The Architecture Meeting
After the initial async circulation with a clear timeline for feedback, typically handled in an announcements channel (Slack/Teams/whatever), we move to the discussion phase. This is where the process comes together. We run a weekly meeting where engineers present their RFCs to a cross-functional group of technical leads. The meeting isn’t an approval committee, it’s a sounding board. This distinction matters more than it might seem. When engineers treat the meeting as a resource rather than a gate, they bring ideas earlier, ask for input on the parts they’re uncertain about, and treat questions as help rather than attacks. It’s also not exclusively for RFCs; engineers use it to share learnings, discuss complex implementations in progress, or get feedback on potential solutions. If there are no presentations, we cancel the meeting. It’s an expensive meeting given who’s in it.
Attendees often change based on the topics. There’s a core group of technical leads, but we invite others when a topic is relevant to their work. The goal is cross-pollination: the engineer building the new API hears from the team that will consume it, the infrastructure lead spots dependencies that weren’t obvious.
I’ll write more about how to run these meetings effectively—the facilitation, the psychological safety requirements, the judgment calls—in a future post. For now, the key point is that the meeting exists to help engineers make better decisions, not to approve or reject their work.
What Happens After
The goal of the Architecture Meeting isn’t to reach a consensus; it’s to add clarity. When the meeting adjourns, the path forward falls directly or into some gradation of the following 3 categories:
- Validated Alignment: RFC is “approved” as-is. The engineer got good feedback during the “roadshow”, addressed the obvious concerns, and the meeting confirms everyone’s aligned (including those who hadn’t participated before).
- Constructive Course Correction: RFC needs revision. The discussion surfaced something important, like a risk that wasn’t considered, an alternative that looks more promising, or a dependency that changes the approach. The engineer updates the document and either brings it back or, if the changes are minor, proceeds with the new direction.
- Documented “No”: RFC gets rejected or deferred. The timing isn’t right, the problem isn’t actually worth solving yet, or there’s a fundamental issue with the approach. Don’t delete these. A rejected RFC is still valuable as it documents why we decided not to do something, which prevents the same proposal from coming back six months later without new information.
The common thread is that the proposer or proposing team still owns the decision. The meeting informed their thinking, but they’re not waiting for permission. For most RFCs, they walk out knowing what to do next.
Recording the Meetings
We record every Architecture Meeting and make those recordings available to the entire organization. This isn’t just for people who were OOO or double-booked, though that’s the immediate practical benefit. The real value is cultural. When you record these discussions, you’re providing a class in senior-level trade-off analysis. Junior and mid-level engineers get to see exactly how decisions are made — how we weigh technical debt against speed, how we (hopefully) constructively challenge assumptions, and how we handle ambiguity. It’s the most effective way to scale “the way we think” across an organization without relying on a large culture deck.
More importantly, it removes the “black box” mystery. If someone disagrees with a decision, the context is right there. They can hear the nuance, the pushback, and the final reasoning. Transparency at this level builds a type of organizational trust that is hard to quantify, but impossible to ignore.
Documentation as Change Management
One underappreciated benefit of this process is that, by the time an RFC is approved, everyone who needs to be in the know is already in the know. Think about how announcements usually work. Someone makes a decision, then sends an email or Slack message announcing it. Half the affected people miss it. Some of them find out during implementation, when they’re already blocked. Others don’t find out until months later, when they’re trying to understand why the system works this way.
With an RFC process, the announcement is the process. The document circulates during the feedback period. The affected team(s) or leader(s) are in the meeting. By the time implementation starts, there should be no surprises. Everyone saw it coming, had a chance to weigh in, and understands the reasoning.
The RFC also becomes the permanent record. When a new engineer joins and asks “why did we build it this way?” the answer exists. When someone proposes something similar a year later, you can point them to the original discussion. The institutional memory lives in the document, not in the heads of people who might have left the company. And it’s a searchable record typically living in the wiki.
Keeping the Process Lightweight
Another threat to the RFC process (aside from silence) is additive bureaucracy. Every time someone has a bad experience, there’s pressure to add more rules, more fields, more oversight. Resist this (or use the RFC process itself to amend the process through consensus).
A few principles that help:
- Keep the template short. If the template is intimidating, people won’t use it. The sections exist to prompt thinking, not to require exhaustive documentation of every single detail.
- Be clear about the threshold. Not everything needs an RFC. We’ve defined what’s significant enough to warrant one–changes that cross team boundaries, modify contracts, or are expensive to reverse. If engineers are uncertain, I’d rather they write a short RFC that turns out to be unnecessary than skip the process for something that needed discussion. If the RFC is really short, you’ll also get that feedback anecdotally, “Why did I just read this? Go ahead and do it.”
- Don’t let the meeting become a presentation. The async feedback period is for people to read and comment. The meeting is for discussion, not a walkthrough of the document. If engineers are spending significant time preparing slides, something has gone wrong. Though there are sometimes topics that warrant this.
- Celebrate failed RFCs. When someone brings an RFC and the meeting reveals a fundamental problem, that’s a win. You caught the issue before anyone wrote code. Make sure the engineer who brought it feels that way, not like they wasted everyone’s time.
When to Redirect
Not every RFC that gets drafted, gets implemented. Sometimes Engineers get really excited about a new technology, programming language, tool, or whatever the new hotness is. They convince themselves that this new hotness is going to be implemented one way or another; they just need a target. This is where it’s on leaders to use their best judgement. It’s a fine line to walk when a leader needs to “shut down” an idea and not also kill motivation, enthusiasm, and initiative. As a leader, you don’t want to seem like a gatekeeper while you are protecting the interests of the business and minimizing distractions.
One option is to timebox a “questionable” idea. If the engineer is usually pretty trustworthy and this single RFC is a bit “outside the box,” you can suggest a constrained experiment:
- Include a very short PoC in the milestones of the RFC document where there is a going to a presentation and “reassessment” at the next architecture meeting.
- “Take 3 days and come up with a PoC to prove the value.”
This gives the idea a fair shot without committing the organization to something unproven.
A Note on AI Tools
We’ve found that Claude and similar tools are useful for drafting RFCs. They are not to generate the ideas, but to organize the engineer’s thinking. An engineer who knows what they want to propose can get to a first draft faster by talking through it with an AI assistant that asks clarifying questions and helps structure the document.
This works because the value of an RFC isn’t in the prose. It’s in the thinking the prose represents. If an AI helps someone articulate their reasoning more clearly, that’s fine. If someone asks an AI to generate a proposal they don’t actually understand, the meeting will expose that immediately.
Some Closing Thoughts
Most technical processes die because they try to replace human judgment with a workflow. They treat engineers like units of delivery rather than owners of a craft. An RFC process only works when the organization views it as a service, not a tax. The document is there to clarify the author’s thinking; the meeting is there to provide the perspective they might be missing; and the record is there to ensure the rest of the company isn’t left in the dark.
If your engineers are dodging the process, don’t add more rules. Look at the meeting or feedback structure. If it feels like a tribunal, fix the culture. If the documents are being ignored, fix the socialization. Treat the RFC as a resource, not a gate. Because at the end of the day, no one actually wants to build the wrong thing.
Appendix
Here are some starter documents that might be useful to help kick off the process.
