Planning for change with RFCs

When Steve Crocker wrote the very first RFC in 1969 on ARPANET, the small network of computers that connected four American research universities, he did so to avoid “sounding presumptuous” when compiling notes from a meeting of graduate students and staff. He titled his memo “Request for Comments,” or “RFC” for short. Other members of the group soon followed suit, writing RFC memos of their own, printing them out, and mailing the documents to one another in the era before email.

Over 50 years later, the RFC format continues to be computer scientists’ preferred method of introducing new ideas, behaviors, and specifications to the workings of the internet. So much so, in fact, that every official Internet Standard, a specification of an internet technology or methodology, has started off as an RFC that was later adopted by the Internet Engineering Task Force, the organization that creates and promotes these standards. The RFC process is now used by a growing number of open-source projects, including prolific frameworks and languages such as Ember, React, Vue, Swift, and Rust, to propose, implement, and plan new features. Some companies, including Artsy and Uber, have even adopted the process for introducing technical and sometimes cultural changes internally.

Suffice it to say, the RFC process is a tried-and-true methodology used by many in the industry. It can help us communicate effectively and share important knowledge and context within a team. And when it comes to planning changes to a codebase, product, or organization, it can support us in coming to a consensus around why certain problems need to be tackled and how we can best address them. While some organizations might reach an agreement by decree of engineering leadership, RFCs provide a more egalitarian approach.

A case study in adopting RFCs

Building software can be an expensive, time-consuming task. Using our resources, energy, and precious minutes to solve the right things, at the right times, in the right ways, can help ensure we’re being as efficient as possible and we can leverage the consensus-building powers of RFCs to achieve that.

I recently implemented the RFC structure at a relatively small, open-source, globally distributed startup where I was spearheading an effort to overhaul the product engineering and planning process. With a fast-growing engineering team, an under-resourced product team, and no standardized approach to technical decision-making, we struggled to allocate time and resources in an organized and transparent manner. This was taking a toll on the engineering culture and product development process. We needed a better way to gather input, provide clarity, and build consensus without reinventing the wheel. 

Noticing parallels between our work and that of open-source software projects relied upon by production apps and built by maintainers and contributors all over the world, we opted to take a page from the open-source book and implement the RFC process internally. As we adopted and refined our approach, we found we could make more informed and democratic judgments about how to apportion resources and align on priorities.

When to go the RFC route

Whether the RFC process makes sense for your team depends on your organization’s structure, product development processes, and existing decision-making frameworks. And as with any methodology, it comes with trade-offs to consider.

The RFC process compels us to reflect on why a problem or idea matters and how we should solve and plan for it. This takes time. Writing up a proposal, requesting comments, and engaging with and addressing those comments (usually more than once) can be slow going. Some folks may resist it, preferring a faster or more familiar process. RFCs also push us to communicate extensively in writing, which can be daunting to some. And they require everyone to be involved in the surrounding discussions after all, writing a long and well-thought-out RFC doesn’t mean much if no one reviews or provides feedback on it. If your organization already has a relatively streamlined way to handle major changes, pivoting to a completely new process might not make much sense.

But for the somewhat small, distributed engineering team I mentioned, setting up the skeleton of a new RFC process proved to be a suitable and mostly straightforward task. I followed the example set by open-source projects and created a GitHub “rfcs” repository, including a directory for accepted RFCs and a basic template for anyone to use when authoring a new one. 

In our first few months using RFCs, we started to see gaps in the template, documentation, and approval process, and it took a few adjustments before it really started to gel with the engineering organization’s workflows and structure. (Don’t be surprised if you have to tweak the process a few times before it feels right for your team.) But once we got it up and running, folks started engaging with the process, asking questions, and weighing in on discussions more openly and enthusiastically than before.