How RFCs Outlived My Employer

From Consumer to Creator

Before I wrote my first RFC at Hashicorp, I'd been on the other side for years - the person reading RFCs, implementing them, relying on them to get work done.

My go-to reference for API design at every job? RFC9205 (Building Protocols with HTTP). Across different companies, different tech stacks, different teams - this RFC was a constant. The canonical guide for how HTTP should work in practice. It influenced the structure of Rails, my preferred backend framework, and I love that Rails brought the soul of RFC9205 to life - turning abstract protocol design into concrete, elegant code.

My personal favorite? RFC5545 (iCalendar). I implemented it for patient scheduling, first for a hearing aid app, then later for fetal ultrasound appointments at Trice Imaging. Written in 2009, it was still my authoritative guide years later. In healthcare, scheduling errors have real consequences - a missed ultrasound appointment isn't just an inconvenience. RFC5545's precision meant I could book with confidence. And honestly, I love time - timezones, dates, the beautiful complexity they entail. I'm the kind of person who gets excited about leap seconds, and RFC5545 captures all of that.

These documents, written by people I'd never meet, guided my work across years and companies. No ambiguity. No archaeology. Just durable, well-reasoned guidance that transcended its authors.

That's what hooked me: RFCs weren't just documentation. They were portable knowledge. It didn't matter where you were working, what job you're doing - these were positive patterns to propigate.

Then I joined Hashicorp (acquired by IBM in 2025) and learned the other side: how to write RFCs, not just consume them.

A Decades-Old Process That Still Works

The Request for Comments (RFC) process isn't new. In 1969, Steve Crocker, a graduate student at UCLA, began circulating informal memos to coordinate work on ARPANET protocols. The name itself was intentionally humble - "request for comments," not decrees or specifications - to invite critique and encourage open dialogue among researchers building the early internet. It's a theme I try to continue in my frontend guild.

Over time, those informal documents became the foundation of the internet itself. Their existence gave validity to people building against them. The IETF formalized the process, and RFCs went on to define everything from TCP/IP to email to the calendaring standards I'd later implement in production systems. RFCs have proven themselves as a tool that not only worked then, but still works now.

At Hashicorp, the same principles that made internet RFCs work for global standards became how distributed teams made internal decisions. It became a tool for making durable, high-quality decisions - explicitly prioritizing clarity and correctness over raw speed. The goal wasn't just to document a choice, but to create references that would outlive the original authors - just like RFC9205 and RFC5545 had outlived theirs.

No one expected that those RFCs to outlive the company itself, but after the IBM acquisition, they did.

What is an RFC?

At its simplest, an RFC is a formal proposal document - an argument for a specific direction.

An RFC isn't required for every change. It's reserved for "significant" changes - decisions that meaningfully shape the system or the user experience:

• New user-facing features
• Fundamental architectural shifts
• Breaking API changes
• Adoption of new core technologies or patterns
• Large refactors impacting multiple teams

The goal is not bureaucracy. The goal is shared understanding before irreversible work begins.

The Lifecycle

A typical RFC follows a predictable lifecycle:

1. Draft: An engineer writes the proposal
2. Comment & Debate: Asynchronous feedback phase (days to months, depending on scope)
3. Revision: Author incorporates feedback, clarifies reasoning, often through multiple rounds
4. Approval: Consensus is reached among relevant stakeholders
5. Implementation: The RFC becomes the charter for the work

Once approved, the RFC is no longer just a discussion artifact - it's a reference point. It answers the question: "Why did we decide to do it this way?"

Key Components

While formats vary, effective RFCs tend to share a common structure:

• Abstract: The tl;dr - what is being proposed in 2-3 sentences
• Motivation / Problem Statement: The user or system problem being solved
• Proposed Solution: The concrete, detailed "what"
• Rationale & Design Details: Why this approach was chosen
• Trade-offs & Alternatives Considered: What was rejected, and why - crucial for showing rigor
• Implementation Plan: High-level steps, directionally clear but not exhaustive
• Unresolved Questions: Known unknowns and areas for future work

That last section is particularly important. Good RFCs don't fake omniscience; they acknowledge uncertainty explicitly.

Two Examples: Different Scopes, Both Valuable

The Projects RFC: Large and Cross-Cutting

The first RFC I particiapted in at Hashicorp was for Projects - a feature allowing teams to group related infrastructure (workspaces, variables, external data sources) and manage them as a cohesive unit with group-oriented permissions.

The scope was massive. It touched product, infrastructure, security, and frontend teams. The RFC's goal wasn't just to propose a solution - it was to discover hidden scope and ensure no team was blindsided.

The process took about 3 months from draft to approval. Multiple rounds of feedback, serveral dozens of comments, and significant design revisions. A backend engineer in a different timezone surfaced critical security permission implications that would have been missed in a synchronous meeting. Asynchronous review gave them time to think deeply, research the codebase, and respond thoughtfully. That feedback reshaped the design.

By the time the RFC was approved, it wasn't "Dean's idea" - it was a shared decision with collective ownership. A dozen engineers across five teams had shaped it. When implementation began, everyone knew the plan, understood the rationale, and had bought in.

Was 3 months slow? Absolutely. But it prevented what would have been months of rework, misaligned implementations, and painful retrofits. The Projects RFC was about discovery and alignment before a single line of code was written.

The Client-Side Polling Service RFC: Communication-Focused

Not all RFCs take 3 months. The second RFC I wrote was for a client-side polling service - a large refactor with minimal functional changes. It was internal restructuring, not new features.

The RFC's primary goal was communication: signal that the change was happening. The secondary goal was gathering implementation feedback, but the decision to refactor was already made.

Timeline: 2 weeks.

Even this lightweight RFC caught something valuable. One engineer commented: "Can you add a tracking header to the polling requests so we can identify them in analytics?" A small detail, easily implemented during the refactor. Caught early because the RFC created space for input, and we were able to gather analytics right out of the gate.

The polling service RFC wasn't about extensive debate - it was about transparency and considering use cases I hadn't yet imagined. Lightweight process, same structure, genuine value.

The Common Thread: Not all RFCs are equally weighted. Scope, complexity, and goals determine the process, but the structure remains consistent.

A Philosophy of Deliberate Design

RFCs aren't magic. The template matters way less than the values baked into the process.

Workflows, Not Technologies

One of Hashicorp's core principles was "workflows, not technologies" - the idea that technology is just a tool, and the focus should always be on the human workflow it enables. The RFC process embodies this perfectly.

By forcing the conversation to start with the user's problem in the "Motivation" section, RFCs shift the focus from "what cool tech can we use?" to "what is the best workflow for solving this problem?" The technology choice becomes a servant to the workflow, not the other way around.

The Projects RFC started with the question: "How do teams manage related infrastructure as a unit?" - not "Should we use a graph database or relational model?" The workflow came first; the technology served it. If we'd started with technology, we'd have built the wrong thing.

Writing is Thinking

The act of writing forces a level of clarity that is impossible to achieve in verbal discussion. You can't hand-wave your way through a written proposal; it compels you to think through edge cases, anticipate questions, and structure your argument logically.

I can't count how many times I started writing an RFC convinced I had the answer, only to realize halfway through the "Rationale" section that my approach had a fatal flaw. Embarrassing? Sure. But better to discover it on page 3 of a draft than after two sprints of implementation. The process of writing was more valuable than the final document - it's where fuzzy thinking gets exposed.

If you can't explain a system in writing, you probably don't understand it yet.

Asynchronous by Default

RFCs are fundamentally asynchronous. That's not an accident - it's a sign of respect.

Asynchronous review decouples decisions from time zones, meeting schedules, and social dynamics. It allows people to engage deeply, on their own time, and contribute thoughtful feedback. It gives the introvert who needs time to process an equal voice to the person who is quickest to speak in a meeting.

On the Projects RFC, that backend engineer who surfaced security concerns? They were in a completely different timezone. In a synchronous meeting, they might not have been present, or might not have had time to think deeply enough to spot the issue. Asynchronous review gave them the space to contribute their expertise when they were at their best.

This isn't just nice - it's strategically important. The best ideas can come from anyone, anywhere, at any time. An asynchronous process captures them; synchronous meetings favor speed and charisma over depth and rigor.

It Creates a Durable Record of Context

Here's the thing about code: it captures what is built, but fails to capture context.

Six months later, someone reads your code and wonders: "Why was this built this way?" If you're lucky, there's a comment. If you're unlucky, the original author is gone and the reasoning is lost. Meaning erodes over time and personnel turnover - the original intent becomes archaeology. The RFC archive is one of the most valuable assets an engineering organization can possess.

The Internet RFC Model:

I never met the people who wrote RFC9205 or RFC5545. They documented their thinking years before I needed it, and that writing guided my work across different companies, different tech stacks, different decades. The clarity outlasted the authors, the companies, the original context.

The Internal RFC Model:

Years after the Projects RFC, engineers refactoring the permissions system can read the original rationale and maintain the design intent while modernizing the implementation. Just like RFC5545 let me implement iCalendar without guessing the authors' intent, internal RFCs let teams evolve code while staying true to the original problem being solved.

RFCs preserve not just decisions, but the spirit of the idea.

The Ultimate Test of Durability:

Hashicorp no longer exists as an independent company - it was acquired by IBM in 2024. But the RFCs we wrote? They're still there. Still guiding engineers who never worked at "Hashicorp," who never met the original authors.

The Projects RFC, the polling service RFC - they outlived not just personnel turnover, but the entire organizational structure. Just like RFC9205 and RFC5545 outlived the companies where they were written, good RFCs transcend the organizations that create them.

That's the standard: write documentation that survives reorganizations, acquisitions, and company transformations. Because it will.

It Separates Ideas from Egos (And Builds Ownership)

In meetings, it's hard to separate critique of an idea from critique of the person presenting it. Seniority, charisma, and politics creep in. The loudest voice often wins, regardless of merit.

RFCs change this. By formalizing debate around a written document, you critique the proposal, not the proposer. "I disagree with this approach" is easier to say about text than to someone's face. The proposal stands on its own merits. Junior engineers can challenge senior engineers. Introverts can contribute as much as extroverts.

And here's the paradox: by separating the idea from the person, you actually get better collective ownership. The RFC author drives the process, but commenters become collaborators. By the time the Projects RFC was approved, it had input from a dozen engineers across five teams. Everyone had ownership because everyone had shaped it. Implementation wasn't a decree - it was a plan we'd built together.

When people have shaped a decision, they're invested in making it succeed.

When RFCs Can Go Wrong

Those are the strengths. But like any process, RFCs can become bureaucratic overhead if misapplied. They're not a silver bullet.

Too Many RFCs: If every small change requires an RFC, you've failed. Full stop. I've seen teams that RFC everything, and they're miserable. The bar should be "significant" changes - things with broad impact, architectural implications, or irreversible consequences. Not every bug fix or minor feature needs an RFC. If you're writing RFCs about log message changes, you've lost the plot.

RFC Theater: Going through the motions without genuine debate or revision defeats the purpose. If every RFC is rubber-stamped without substantive feedback, you're paying the cost of the process without getting the benefits. RFCs should invite real critique, and authors should be willing to revise based on it.

Endless Debate: RFCs can stall if "consensus" is undefined. Does approval require unanimity? Majority? Sign-off from specific stakeholders? Without clear criteria, debates become infinite. Define what "approved" means, time-box comment periods, and empower someone (the author, an architect, a team lead) to make the final call.

Mitigation:

• Clear guidelines on when an RFC is required (and when it isn't)
• Time-boxed comment periods to prevent endless debate
• Defined approval criteria (e.g., "2 senior engineers + 1 architect must approve")
• Encourage "lightweight RFCs" for smaller changes - shorter documents, faster turnaround, same structure

The trade-off is speed vs. durability. The RFC process is methodical, deliberate, and requires significant up-front effort. It is not the fastest way to make a decision. But it is optimized for making high-quality, durable decisions at scale. It wisely trades short-term velocity for long-term alignment and maintainability.

When you need speed - for small, reversible changes, experiments, internal-only refactors - skip the RFC. When you need durability - for irreversible changes, public APIs, architectural decisions - invest in the RFC.

The Long Game

So what does that investment actually look like in practice?

The Projects RFC took 3 months. The polling service RFC took 2 weeks. Neither was the fastest path. But both prevented far more time lost to misalignment, scope creep, and forgotten context.

I built my career on internet RFCs. RFC9205 for APIs. RFC5545 for scheduling. These documents, written by people I'd never meet at companies I'd never work at, guided my work across years.

At Hashicorp, I learned to write RFCs with the same durability in mind. The goal wasn't just to document a decision, but to create a reference that would outlast me.

I didn't expect them to outlast the company itself, but they did. After the IBM acquisition, those RFCs are still there, still guiding engineers working on those same systems. They outlived the company that created them.

That's the power of well-written documentation: it transcends individuals and organizations. Knowledge compounds when it's preserved in writing.

You Don't Need Hashicorp's Scale

I know this all sounds like I'm advocating for process, which feels wrong. (Engineers are supposed to hate process, right?) But even a lightweight version - simple Architectural Decision Records (ADRs) - creates the same value: written context that outlives individual memory.

Hell, a solo developer can use this for their own future self. "Why did I build it this way?" becomes answerable six months later when you've forgotten the original reasoning.

The principles scale: writing clarifies thinking, asynchronous debate allows for depth, documented decisions outlive people.

A 50-Year Legacy

A process born in 1969 for ARPANET still works because the fundamentals haven't changed. Writing clarifies thinking. Asynchronous debate scales. Documented decisions outlive the people who made them.

RFCs don't just document decisions - they preserve the spirit of why something exists, letting code evolve while staying true to its purpose.

From consuming them to writing them, I've learned the same lesson: well-reasoned decisions, preserved in writing, transcend time and change.

That's alignment at scale.