Documenting Decisions Through RFCs
Using RFCs for Effective Decision Making
👋 Ciao, Alex here. Welcome to a new free edition of Not Just Bits, and thank you to all the readers and those who support my work. Every week, my goal is to share lightweight and informative resources for CTOs.
Scaling an engineering team is hard. Very hard. Lines of communication and interactions between teams grow constantly and more than proportionally. Eventually, you may find yourself dealing with problems like technology misalignment, lack of visibility, and team duplicating effort or not following standards.
How can you ensure everybody in the team has the necessary visibility and can participate and contribute to technical discussions?
One effective solution is the Request For Comment (RFC) process.
What is an RFC?
The RFC system was first introduced by Steve Crocker in 1969 to help record unofficial notes during the creation of the ARPANET. Later, Internet RFCs became established and are used by the Internet Engineering Task Force as official documents of Internet specifications, communications protocols, procedures, and events.
Using RFCs Effectively
To streamline decision-making and enhance collaboration, it's important to understand that RFCs are not limited to engineering topics. There's a common misconception that RFCs are only for engineering topics. In reality, RFCs often cover cross-domain topics that involve product management, customer success, and other areas. This inclusive approach ensures comprehensive decision-making across the organisation.
When to Use the RFC Process
An RFC should be written when planning to make substantial changes that impact the entire organisation. What constitutes a “substantial” change varies but may include:
Major infrastructure changes (e.g., migrating to a new cloud provider)
New security conventions (e.g., implementing company-wide SSO)
Replacing open-source libraries (e.g., switching from one logging library to another)
Refactoring significant parts of the application (e.g., reworking the customer onboarding process)
When Not to Use the RFC Process
While RFCs are powerful, they are not always necessary. Avoid using RFCs for:
Decisions that need to be made quickly to resolve an immediate issue
Minor bug fixes or patches
Small, incremental changes that do not affect the overall architecture or team workflows
Routine maintenance tasks
RFC Instructions
RFC Owner
They support the proposed design, ensure the RFC follows existing design and style rules, help the review committee reach an agreement, and make sure the proposed implementation is prioritised and assigned to teams.
Feedback
The purpose of RFCs is to ensure the community is well represented and served by new changes. Community members should take part in reviewing RFCs where they care about the outcome, provide feedback quickly, read RFCs thoroughly, and be polite and constructive.
Reviewer
The goal of the review meeting is to fix minor issues; major issues should be resolved beforehand. The committee makes sure that public feedback has been considered, adds their meeting notes as comments on the PR, and provides reasons for their decisions.
Action Points
Once an RFC is approved, it is the owner's responsibility to write the action points to help prioritise and implement the solution.
Takeaways
After introducing an RFC process, you can expect significant improvements in team collaboration and decision-making.
Every engineer brings a wealth of experience and knowledge. Participation and collaboration are key to the evolution of any tech team. Creating the conditions for everyone to contribute and participate in the company's growth and service ensures continued success and innovation.
By adopting and tailoring an RFC process to your organisation's needs, you can foster a more collaborative, transparent, and efficient decision-making environment, ultimately driving better outcomes for your tech team.
✅ Before you go:
Please share this post and invite your network to subscribe to the Not Just Bits newsletter.
Feel free to connect with me on LinkedIn.
See you next week! Best, Alex Di Mango