Many engineering organizations adopt an RFC (Request for Comments) process with good intentions, only to see it stagnate over time. Documents become heavy, reviews become performative, and engineers either avoid the process entirely or treat it as a bureaucratic checkbox.
That pattern will likely sound familiar because it was ours, too.
About three years ago, when I joined Attentive, it became clear that RFCs were technically part of the engineering culture, but not meaningfully so. A few people wrote them, but there was no shared understanding of when to write an RFC, what it should look like, or how decisions were supposed to emerge from the process. Documents varied wildly in style, tone, and level of detail across teams. As a result, decision-making was inconsistent, and we occasionally ran into avoidable issues that someone else in the organization could have flagged early had they known the work was happening.
As the company grew, this problem became more pronounced. When Attentive was smaller, most engineers had a rough sense of what was being built and why. Over time, changes became increasingly siloed. Staff-plus engineers, in particular, expressed concern that they could not effectively offer their expertise if they did not know who was working on what or when architectural decisions were being made. The cost was a gradual loss of transparency, confidence, and shared technical context.
We needed a system that improved decision-making and transparency without causing process paralysis or developer thrash. What we did not want was a heavy, prescriptive process that slowed teams down, created personality-driven conflict, or made engineers second-guess themselves.
The RFC process described here is the result of that effort of the Staff-plus guild at Attentive. We iterated on clear guidelines, introduced a lightweight template for consistency, and even built small bits of tooling (such as an internal bot that notifies engineers when new RFCs are ready for review) to make participation easier for those who want to stay engaged.
This post distills that experience into a practical RFC process intended for software engineers and technical leaders who want a lightweight but effective way to make better architectural and design decisions without slowing teams down. The emphasis throughout is on collaborative decision making and clarity, and avoiding consensus by exhaustion.
Our hope is not that you adopt this process verbatim, but that it sparks a similar conversation in your own organization about how design decisions are made, reviewed, and shared.
An RFC is a technical design document that captures:
Equally important, an RFC is the engine of a collaborative review process. The document is the artifact but the real value comes from the feedback loop it creates.
RFCs are most effective when they are started once the design has taken a concrete shape, but before implementation details are locked in. The cost of incorporating feedback increases over time, so earlier is generally better.
Most organizations have a template but intentionally avoid a rigid format. RFCs should evolve as feedback is incorporated, and their structure should adapt to the problem being solved.
You should consider writing an RFC when one or more of the following apply:
If any of these resonate, an RFC is likely the right tool for you.
A well-designed RFC process should:
The goal is to improve decisions, not to maximize participation for its own sake.
Clear status signaling is essential so that all stakeholders are aware of the timelines and progress. Consider including a status indicator in your header metadata
Post-closure changes should be captured as addendums to preserve decision history.
If you are unsure of the proposal, or suspect a proposal may face strong resistance, consider doing a lightweight "vibe check" before investing significant time in writing a full RFC. Informal conversations with likely approvers or domain experts can quickly surface fatal flaws or misalignment.
This is not about pre-approval or consensus-building behind closed doors. It is about avoiding sunk-cost bias and ensuring that a written RFC is a productive use of time for both the author and reviewers.
Once approvers are largely comfortable with the proposed direction, teams may begin work breakdowns or limited implementation. This allows momentum to continue without waiting for perfect certainty.
However, if there are serious unresolved concerns in the RFC, authors should pause before productionizing the solution. RFCs exist to surface risks and build shared confidence. Proceeding while substantive issues remain unresolved undermines the process and erodes trust. Reviewers can indicate their concerns by using the “Request Changes” state on their review.
In these situations, the right response is to slow down deliberately: invest time in building consensus, clarifying assumptions, or adjusting the design before committing further. The further along implementation goes, the more expensive RFC-driven changes become. Unresolved feedback should be treated as a signal, not noise.
RFCs should default to asynchronous review to allow thoughtful feedback. Meetings can be valuable when discussion stalls or complex trade-offs need real-time alignment.
If you schedule a meeting:
Although RFCs are not approval-seeking exercises, there are cases where the review process surfaces concerns that are serious and unmitigable. In such situations, outright rejection of the RFC may be warranted.
Authors, and their managers, should treat this as a strong signal and an opportunity to course-correct. If the work is constrained by external timelines, this is often the right moment to renegotiate assumptions, scope, or deadlines. A poorly designed project does not avert a crisis; it merely delays it.
The cost of ignoring serious concerns is rarely avoided. It is deferred, and almost always paid later, by more teams, at significantly higher cost.
The RFC author is accountable for the full lifecycle of the proposal, including drafting, soliciting feedback, and driving the document to completion.
Practical guidance for authors:
Authors should explicitly identify who is involved in the RFC and in what capacity. A responsibility assignment matrix (often framed as RACI) works well:
This clarity helps prevent both under-review and “too many cooks” scenarios.
An RFC is a communication artifact, not a code dump. Use clear prose to explain the proposal, its motivations, and its trade-offs. Simply pasting code snippets, schemas, or contracts and expecting reviewers to infer intent wastes reviewer time and almost always results in excessive clarification comments.
If reviewers need to ask basic questions to understand what you are proposing, the document is incomplete. The RFC should stand on its own, with code and contracts used only as supporting material where they add clarity.
Write documents that are readable and scoped appropriately:
As a rule of thumb, if the idea is too complex to explain clearly without excessive length, it likely needs decomposition. If it is simple enough to be captured entirely in implementation, skip the RFC and proceed directly to code review.
Focus on high-level design and architecture. Discuss alternatives and provide a recommendation. Explain the reasoning about your design choices, decisions and assumptions, with data. If you made assumptions, list them. Avoid low-level implementation details better suited for pull requests. Extensive diagrams, benchmarks, or background material should live in appendices or linked documents.
RFCs should be approached by reviewers not as a mechanism for gate-keeping, but as a forum for providing active feedback. The author is not asking for permission; they are asking for perspectives that help strengthen the design and surface risks early.
RFCs are also an important form of technical communication and a venue for mentorship and shared learning. Reviewers are encouraged to engage with the document thoughtfully and constructively. Guidance such as Amy Ciavolino’s work on mindful communication in code reviews applies equally here: feedback should invite discussion, encourage openness, and avoid shutting down exploration.
Reviewers should recognize that they are offering perspectives, not arguments. The goal is not to “win” a debate, but to help the author arrive at a well-reasoned solution.
Approvers, in particular, must take proactive ownership of the review process. Early, actionable feedback saves significant time for the author and for the organization by preventing investment in approaches that are unlikely to succeed.
Approvers are active partners in the RFC process and are expected to:
All reviewers are expected to respect the timelines defined in the RFC. RFCs are meant to drive decisions, not linger indefinitely. In practice, this means:
Reviewers should update the RFC header with one of the following states once they have reviewed.
Before leaving comments, reviewers should read the document at least once in full. Many concerns are addressed later in the RFC, and premature comments often create unnecessary noise.
When commenting:
Reviewers should actively avoid starting or participating in pile-ons. If a discussion thread becomes overly long or circular, any reviewer or approver may suggest taking the discussion offline via a moderated meeting to resolve the logjam.
Engaged observers are encouraged to step in and propose this path when they see discussions becoming unproductive. This helps prevent unnecessary friction and keeps the RFC moving forward.
If a long discussion has already concluded, avoid reopening the thread. Instead, consult the decision log or ask the author to clarify what decision was made and why.
An RFC process succeeds when it is lightweight, respectful of engineers’ time, and clearly oriented toward better decisions. Clear writing, early feedback, and disciplined scope are what make the process scale.
Treat RFCs as living design conversations not as code dumps, not as permission slips, and not as bureaucratic hurdles, and they will improve decision quality as your organization grows.
