Unleashing the Power of RFCs: A Game-Changer for Productivity

Effective communication and documentation are paramount in the fast-paced tech industry. RFCs (Request for Comments) can hold the key to enhancing collaboration and driving successful outcomes.

Companies across tech use RFC documents to explore and propose product and process changes beyond the scope of a single team. In this blog, we’ll explore the purpose of an RFC, how to write a good one, and what to do to usher an RFC from inception to feedback — and perhaps even implemented change.

What is an RFC?

It’s not as formal as it sounds — but it has an interesting history! Most broadly, RFCs are a way for people in the tech world to share ideas, propose new standards, or suggest improvements to existing protocols and technologies. It's like an open forum where anyone can throw in their two cents and spark discussions among experts.

The first RFC was written in 1969, and effectively functioned as a memo for changes proposed to ARPANET — the precursor to the modern Internet. Fast forward to today, and the management of RFCs has been entrusted to the Internet Engineering Task Force (IETF), a renowned organization dedicated to developing internet standards. If you take the time to explore these documents, you'll discover that the vast majority of the internet and its infrastructure has been meticulously defined within these pages over the course of more than 50 years.  RFCs are not just documents; they are the building blocks of the internet, embodying the collaborative spirit and collective expertise of countless individuals who have contributed to its growth and evolution. (Here’s a wiki for more info.)

But back to the day-to-day; RFCs cover all sorts of topics, and act as a roadmap guiding engineers, designers, and other team members throughout the lifecycle of an idea. They outline the project's goals, requirements, and implementation details, ensuring a clear understanding of the tasks at hand. If you have an innovative idea to share, an RFC might be a great way to get traction on it!

Why Many Companies Rely on RFCs for Success

RFCs are indispensable tools for tech companies seeking to streamline their development processes and achieve their goals. They serve various purposes, including:

• Alignment: RFCs establish a shared understanding of project goals, requirements, and implementation details, fostering alignment across teams.
• Communication: By documenting design decisions and rationale, these documents facilitate effective communication among stakeholders, promoting collaboration and understanding.
• Decision Making: RFCs present alternatives and trade-offs, enabling informed decision-making and the selection of optimal approaches.
• Accountability: With defined milestones, responsibilities, and timelines,RFCs establish accountability, aiding progress tracking and evaluation.

By encouraging the above, RFCs effectively provide a mode of documentation for anything that might be beneficial or informative to a product or a team. This then ladders into knowledge preservation, collaboration, consistency and standardization, and even debugging when there are challenges down the road.

What Makes a Good RFC?

When Google engineers get confronted with a system that they hadn’t previously touched their first question might be “Where is the RFC?” Amazon, Salesforce, Uber, and more are among the many top companies using RFCs to improve their workflows. There are many ways to go about it — here's an article that has compiled templates from tens of the top companies employing this strategy. And here is a Google Doc compiled by LeadDev with a blank RFC you might build from, yourself.

Regardless of format, a good RFC comes down to three key approaches: clearly defining an objective, providing clear background and context, and accurately and completely detailing the technical specifications of the project.

Context and Scope

This section gives the reader a very rough overview of the landscape in which the new system is being built and what is actually being built. This isn’t a requirements doc. Keep it succinct! The goal is that readers are brought up to speed but some previous knowledge can be assumed and detailed info can be linked to. This section should be entirely focused on objective background facts.

Goals, Non-Goals, and Constraints

Make a bulleted or numbered list! And keep it short. Sometimes it’s necessary to include what the industry often calls “non-goals.” These are clarifications about goals that could potentially align to the RFC, but are actually not in the intended scope of the project. By clarifying “non-goals,” teams keep the RFC focused — or even open opportunity to shift non-goals into explicit goals. Really, this opens the conversation.

This section can also include an abstract on system and design context, as well as degrees of constraint.

Implementation Proposals, Tradeoffs, and Key Considerations

Include this section to provide your best guess at what will be needed to move forward with the proposed work, and anything that seems like it could be a blocker or a tradeoff to making the RFC happen. Most importantly, this section is iterative: as it is passed around to more teams and as the RFC conversation progresses, this section should include (well maintained and straightforward) running list of the requirements for the project.

Final Recommendation and Decision

Once next steps are agreed upon, add them to the RFC. Describe the implementation in such a way that accounts for future iteration — you should expect that another team or project will want to understand exactly what was done, so that they can build upon or change it as needed moving forward. This also serves as a basis for direction when the changes start to be put in place, keeping work on track. More than anything, this section helps with documentation and proper sharing of RFCs, so that everyone involved — now or in the future — can have a quick and complete understanding of what happened.

Organizing and Archiving RFCs

A well-organized system ensures easy access to past RFCs enabling teams to refer back to previous projects, learn from past experiences, and leverage existing knowledge. A shared folder might be the simplest and best way to do this, and below is an example from Mews about how their time organizes past RFCs:

Archiving these documents in a well-understood and communicated system serves as a valuable resource across several functions, including:

• Onboarding new team members, as it provides historical context, insights into decision-making processes, and a repository of best practices.
• Maintaining a systematic approach, so that companies can ensure continuity, foster collaboration, and facilitate efficient project execution.
• Safeguarding intellectual property to promote compliance with regulatory requirements.

Investing time and effort in organizing and archiving design documents not only enhances productivity but also contributes to the long-term success of companies by preserving institutional knowledge and facilitating continuous improvement.

In the dynamic realm of tech careers, harnessing the power of well-crafted RFCs can be a game-changer. They can propose and align changes in an organization, and by extension, a career! Learn more about RFCs and talk to mentors about optimizing internal processes to your benefit with Merit: