What

An RFC (Request for Comment) is a written proposal that outlines a plan for change — inviting others to challenge, refine, or endorse it before execution begins. Originally used in open source communities to propose technical changes, RFCs are just as valuable in product and platform work. The PHP RFC library offers a good example on what a technical RFC looks like.

This is an important step in the how of working to ensure that teams are aligned on the approach before getting into the execution phase of a project. The RFC should be owned by a Directly Responsible Individual (DRI). It should follow a clear structure that both technical and non-technical stakeholders can engage with.

An important caveat here is these types of documents can take on a lot of different forms or names, RFCs is one such form. You may be using terminology such as "poster pages", "product request documents" or something similar to this, I feel the principle is largely the same and the version on which you work on could, and should, be an alignment between engineering and product teams.

When

This has always been one of the hardest things to measure for me. Some projects will absolutely need some form of RFC. Others may require just a sense check of the steps of execution without all the additional detail.

You probably need an RFC if:

• The project or feature will require coordination of more than 1-2 engineers
• The work affects multiple teams or systems
• There are complex trade-offs or high risk
• You expect meaningful async feedback from stakeholders
• The project spans multiple delivery milestones

I personally feel that this is one of those things that come with experience and you will sometimes get it wrong, I know I certainly have. But eventually you'll get the right flight level here.

How

Here's a suggested format that I have had good mileage with in the past.

• Context - a high level overview of what has brought us to need to do this work
• Definition of Done - again, high level of what we want to achieve
  • Risks - both technical and operationally, for example, we may not be able to easily test X, Y or Z
  • Impact Analysis - looking at standardised list, assess what areas will be impacted by this change, i.e. API documentation or our observability tools
  • Decision Logs - any decision that has been undertaken by the DRI to reach a concensus
  • Architecture & System Flows - *important technical details around the actual "how" surrounding the feature
• Launch readiness
  • Testing and Acceptance Testing Plan - How are you going to know what you built work? What are your test cases
  • Rollback / recovery plan - Worst case scenario, how do we get back on track?
  • Tracking & Observability - How will you know what is working and what isn't? When this launches, how do I see the technical health
  • Documentation Plan - In 6 or so months time, most of us may have forgot a lot of how this project came to be, where is the digestable information that fits the wider business narrative
• Milestones - Arguably one of the most important parts of the document, how are you delivering iterative impact and how can we break this work down appropriately to gain confidence in the overall solution

It's important to note, we shouldn't boil the ocean so to speak with a document like this, gaining 80% confidence in the plan is more than enough here to begin building is my personal opinion.