01 layer
knowledge
what it reads before it writes anything
03 playbooks
—
stands on its own
An RFC is a written proposal for a change to a product or system, circulated before the change is made. It does two things: it tells people a change is coming, and it collects the objections while they are still cheap to act on. Somebody will spot the case you did not think about, and you would rather they spot it now.
When a team proposes something significant, the cost of writing it down is a couple of hours. The cost of not writing it down is discovering the disagreement in code review.
When to write one
- The change spans multiple teams or multiple internal services, in process or in code. Adding a new type of payment method, rather than another gateway for an existing one, will touch user, payment and order components at once.
- The change alters a rule the business depends on. Recalculating how many items count as available for sale so that backorders work against a known warehouse date is a small diff with a large blast radius.
- The change reaches outside engineering. Integrating with Salesforce to recalculate customer scores changes the support team's process too, and they should be in the working group rather than informed afterwards.
- You are replacing a technology: a database, a language for a service, a platform. If the proposal is to move full-text search from Elasticsearch to MeiliSearch on the strength of a proof of concept, the proof of concept and its numbers belong in an RFC.
- You need alignment on the technical approach for a new project.
When not to
- The change does not alter the output of any process outside your own.
- No technology is being introduced or replaced.
- The change stays inside one service and one team.
Writing an RFC for these teaches people that RFCs are ceremony, and then they stop reading the ones that matter.
Writing one
Before you start, check that the idea is not already in the roadmap or already on the rejected list. Both happen, and both are avoidable with ten minutes of searching.
The document needs the change described completely enough to argue with: what it does, what it requires, the use cases it serves, and how you intend to implement it. Seek out the people who will disagree before you circulate it rather than after. An RFC that reaches the wider team having already survived its two toughest reviewers is a proposal. One that has not is a first draft with an audience.