Writing RFCs

Writing RFCs

4 min read

A Request For Comments also known as RFC, is a process that captures ideas and proposals about a specific topic to discuss and find consensus šŸ¤.

An RFC involves a document or a series of documents šŸ“‘, which are drafted, reviewed and eventually approved or rejected by a group of people.

Table of Contents

What are the benefits?


Writing down your idea into a document will clarify your thoughts and will help organizing them in a structured manner.

Anticipating šŸ”® the problem you aim to solve and envisioning potential solutions is key to identifying issues and edge cases.


As a team, it's important that decisions šŸŽ™ļø are made by reaching a consensus šŸ¤. It's very common that as humans we have different opinions and points of view.

RFCs are an effective process to include everyone's opinions šŸ’­ and reach a decision everyone agrees with.


The document šŸ“‘ itself is a valuable piece of documentation as it captures the context, the problem, the solution, and the decision-making process.

It will serve as a reference for future team members and will help them understand the context and the reasoning behind the decisions made ā£ļø

An RFC is usually the initial step in the decision-making process before creating Architecture Decision Record which I previously wrote about āœļø

Better decision-making

One of the steps of the process is to share the RFC with the team to collect feedback and review the context and the proposed solution.

Involving multiple people šŸ§  in the decision-making process is key to achieve high quality decisions, as it will bring different perspectives and solutions to the table reducing the chances of overlooking important details.

You can think of it as a code review, but for ideas and proposals.

When you should write an RFC?

It depends šŸ™ˆ but generally I would recommend writing them when dealing with high-impact decisions and major changes that require consensus and alignment such as:

  • Introducing a new service in your company šŸš€
  • Major changes in the architecture šŸ—ļø
  • Big features that have an overarching impact šŸ†•

It's up to you to decide when to write them, but in my opinion you should weight āš–ļø the effort šŸ„µ and the impact šŸ’„ since it's a time-consuming process that involves many people.

How to write an RFC

Define a template

When writing them, a common practice is to have a template to write āœšŸ¼ all the documents in the same way.

You'll find a lot of templates online, but this is the one I use šŸ‘ˆ

RFC Template

ā—ļø Use a tool that allows collaborative features (comments, suggestions etc) to make it easier for the team to review and provide feedback such as Google Docs or Notion.

Share document for review

Once you have the document ready, share it with the team for them to review šŸ‘€ and provide feedback.

Address feedback

After the reviews come in, you should address the comments, questions and concerns and incorporate any suggestions if appropriate šŸ–Šļø.

Make a decision

Finally, after the document has been reviewed and the feedback has been addressed and collected, it's time to make a decision.

The team should either approve āœ… the RFC and move forward with the proposal or reject āŒ it.


In case you're looking for inspiration, there are many organizations and communities that use RFCs to propose and discuss new ideas, here are some examples:


RFCs are a powerful process to gather feedback, align the team and document decision-making. They're a great way to reach consensus as a team representing everyone's opinion.

I encourage you to give them a try and see how they can help you and your team to make better decisions! šŸ«°

Enjoyed the article? šŸ˜

Subscribe šŸ‘Øā€šŸ’»