Challenges

Writing Technical RFCs That Actually Get Read and Drive Decisions

By Marc Molas·August 10, 2023·9 min read

The most expensive technical decisions in an engineering org happen in Slack threads that disappear, in meetings where half the stakeholders are absent, or in a senior engineer's head without anyone else's input. Then six months later, when the architecture is creaking and someone asks "why did we build it this way?", nobody remembers. Or worse, everyone remembers differently.

RFCs -- Request for Comments documents -- solve this problem. They're one of the most powerful tools available to engineering teams, and one of the most underused. I've seen them transform how teams make decisions, align across time zones, and build institutional memory. I've also seen them done badly, turning into 40-page novels that nobody reads and that slow everything down.

Here's how to do them right.

Why RFCs matter

An RFC is a written proposal for a significant technical decision, shared with the team for feedback before implementation begins. That's it. Not a specification. Not documentation. A proposal that invites input.

The value comes from three things:

Forced clarity of thought. Writing forces you to structure your reasoning. The vague idea that seemed great in your head gets tested when you have to explain it on paper. I've written RFCs where the act of writing revealed that my proposed solution had a fundamental flaw I hadn't noticed. That's the point -- it's cheaper to find the flaw in a document than in production code.

Async alignment. In a distributed team spanning multiple time zones, synchronous meetings are expensive and exclusive. Someone is always joining at an inconvenient hour, someone is always missing. An RFC lets everyone contribute their perspective on their own schedule. The engineer in Buenos Aires and the one in Berlin both read the same document and add their comments without needing to find a 30-minute overlap.

Institutional memory. Six months from now, a new team member will ask why the system uses event sourcing instead of a traditional CRUD pattern. Instead of relying on oral history ("I think Maria decided that, but she left in March"), you point them to RFC-047. The context, alternatives, and rationale are all there. This alone is worth the cost of writing RFCs.

The RFC structure that works

I've iterated on RFC templates across multiple teams and organizations. This is the structure that consistently produces useful documents without being burdensome:

1. Title and metadata

RFC number and title. Sequential numbering (RFC-001, RFC-002) makes referencing easy.
Author(s) and date.
Status. Draft, In Review, Accepted, Rejected, Superseded.
Reviewers. Name the people whose input you specifically need.

2. Context and problem statement (1-2 paragraphs)

What's the situation? What problem are we solving? Why now? This section grounds the reader. Don't assume they have the same context you do. Link to relevant tickets, metrics, or incidents that make the problem concrete.

Bad: "We need to improve our data pipeline." Good: "Our current batch ETL pipeline processes 2M records nightly. With our growth trajectory, we'll hit 10M records by Q1 2024. The current architecture takes 4 hours to process 2M records and won't scale linearly. Last month we had two incidents where the batch job didn't complete before business hours (INC-234, INC-251)."

3. Proposed solution (the core of the document)

Describe what you want to build, how it works, and why this approach. Include:

Architecture or system design. Diagrams help. A simple box-and-arrow diagram communicates more than five paragraphs of text.
Key technical decisions within the proposal and why you made them.
Scope. What's included and, critically, what's explicitly not included.

4. Alternatives considered (non-negotiable section)

List at least two alternatives you evaluated and why you rejected them. This section does three things: it shows you did your homework, it preempts "but why didn't you consider X?" comments, and it documents the decision landscape for future readers.

If you can't think of alternatives, you haven't thought about the problem enough.

5. Risks and open questions

What could go wrong? What are you uncertain about? What assumptions are you making that might be wrong? This section is where intellectual honesty lives. A proposal that claims zero risks isn't confident -- it's naive.

6. Implementation plan

A rough timeline and phasing. Not a detailed project plan -- just enough to show this is feasible and to identify dependencies. "Phase 1: migrate the ingestion layer (2 weeks). Phase 2: migrate the transformation layer (3 weeks). Phase 3: decommission the old pipeline (1 week)."

7. Decision and outcome (filled in after review)

What was decided? When? By whom? Any modifications to the original proposal? This closes the loop and turns the RFC from a proposal into a record.

Common mistakes that kill RFCs

Too long. If your RFC is over 4 pages, most people won't read it carefully. They'll skim, miss the nuance, and either rubber-stamp it or raise objections that are already addressed in the text. Be ruthless about cutting. Move implementation details, API schemas, and data models to appendices.

Too abstract. "We should adopt a microservices architecture" without specifying which services, what the boundaries are, or how they communicate is not a proposal -- it's a wish. RFCs need to be concrete enough that someone could disagree with a specific aspect.

No clear decision point. The RFC should state explicitly: "We need a decision on this by [date]. If no objections are raised by then, we proceed with the proposed approach." Without a deadline, RFCs become perpetual drafts that never convert to action.

Writing RFCs for everything. Not every decision needs an RFC. Choosing between two NPM packages for date formatting doesn't need a document. RFCs are for decisions that are hard to reverse, affect multiple teams, or involve significant investment. I use this rule: if the implementation takes less than a week and is easily reversible, just do it. If it takes more than a week or is hard to reverse, write an RFC.

Using RFCs as permission slips. The RFC process should be about getting input, not getting approval. If every RFC needs to be "approved" by a committee, you've built a change review board with extra steps. The goal is better decisions through collective input, not bureaucratic gatekeeping.

Building the RFC habit without bureaucracy

The biggest challenge isn't writing one RFC -- it's making it a team habit. Here's what works:

Start with a lightweight template. Don't create a 15-field template on day one. Start with Problem, Proposal, Alternatives, Risks. Four sections. You can add structure later as the team sees what's useful.

Make the first few RFCs visible wins. Pick a decision that the team has been going back and forth on. Write it up as an RFC. When it leads to a clear decision with documented reasoning, the team sees the value. That sells the practice better than any process mandate.

Store RFCs where people already work. A shared Google Drive folder nobody visits is where RFCs go to die. Put them in your repository (an /rfcs directory), in Notion if that's your team's home, or in Confluence if you're stuck with it. Wherever the team already looks for information.

Assign reviewers explicitly. "Please review" addressed to nobody is addressed to nobody. Name 2-3 specific reviewers whose expertise is relevant. Give them a deadline. Follow up if they don't respond.

Keep the review period short. Five business days is plenty for most RFCs. If an RFC sits in review for three weeks, the author has already moved on mentally and the document becomes stale.

Celebrate good RFCs. When someone writes an RFC that saves the team from a bad decision or leads to a notably better architecture, call it out. "Alejandro's RFC on the caching strategy saved us from a design that would have broken at 10x load" makes writing RFCs feel valuable, not like homework.

RFCs for distributed teams

RFCs become even more valuable when your team is distributed. They're the great equalizer -- the engineer who's quieter in meetings gets equal voice in a written document. The team member in a different time zone doesn't miss the discussion because there is no discussion to miss. Everyone contributes asynchronously.

At Conectia, we've seen the RFC practice make a tangible difference in how distributed teams operate. When our senior engineers join a client's team, having a clear RFC process means they can contribute architectural thinking from day one, not just code. They understand the context behind existing decisions (because it's written down) and can propose improvements through the same structured process. It's how distributed teams make decisions as well as -- or better than -- colocated ones.

The investment is small: a template, a storage location, and a commitment to writing before building for significant decisions. The return is enormous: better decisions, fewer "why did we do this?" conversations, and a team that thinks before it codes.

Building a distributed team that makes strong technical decisions asynchronously? Talk to a CTO -- our senior LATAM engineers bring the structured thinking and communication skills that distributed teams need.