Making decisions when there are only a few team members is relatively straightforward. As the team scales, decision making that incorporates all the relevant perspectives without grinding to a halt gets exponentially harder. In our previous venture, we started incorporating RFC (Request for Comments) into our process as our software team approached 20 engineers and product managers. Over the course of a couple of years, our team leveraged 30+ RFCs to facilitate some of our biggest product and technical decisions. If scaling decision making is a challenge you are facing today, give RFC a try. I am a fan.
What is an RFC?
Basically, RFC is a structured process to gather input on key decisions. It also communicates those potential changes to anyone whose work may be affected or will be working on implementing the changes. First of all, it encourages the team to write things down. Being agile and fast is great though for big decisions, it is worthwhile to step back and plan out your work. RFC is a structured way to identify and seek feedback from stakeholders. Finally, it is a place to record alternative paths and the reason behind why one path is chosen over the others.
Draft the RFC
Typically 1 or more owners create the initial draft. Spending no more than a few hours, the owners capture the business context, the team’s shared understanding of the problem, the approach, and the implementation/architecture impact. Often the owners get together with a subset of stakeholders to work out the initial kinks and settle on a plan. Once drafted, the RFC enters the PROPOSED state.
Having a sense of who would be impacted by the change, the owners select a set of stakeholders to review the draft RFC. Sometimes, these stakeholders recommend additional stakeholders to be added. The stakeholders have until the RFC Close Date to review and comment on the RFC. The Close Date is usually set to be between 2 days and 2 weeks. Though we have definitely missed those timelines in practice.
Comments to the RFC and their associated responses often are handled directly in the doc asynchronously. Though if the complexity level and size of the disagreement/concerns are high, engineers are encouraged to dedicate time to meet in person or over video chat to resolve all the comments. The owners can choose to incorporate new suggestions to the RFC or keep them under the section “Dissenting Opinions” or “Alternative Solutions”
In my last startup, we decided that each RFC needs at least 2 approvals from senior engineers that are not the RFC owners. It was our choice and not necessarily the default of all RFC processes. If the owners are comfortable with the RFC after all comments are resolved and they receive the 2 needed approvals, the RFC is ACCEPTED. Changes described in the RFC are now ready for implementation. On the other hand, if the changes proposed are too controversial or the RFC ends up highlighting faults that are unacceptable to the owners, the owners can choose to cancel the RFC and set the RFC state to CANCELLED.
Key Components of an RFC
Responsibilities include drafting the initial RFC, addressing comments and closing the RFC
In my last startup, we had 2 close dates, one for product and one for tech. They are typically between 2 days to 2 weeks. You are free to set only one Close Date.
What and Why
This section describes the changes needed by product and the architecture required to support them. It also includes a summary of the reasons behind the proposed changes.
Let’s look at an example from my last startup, x.ai. x.ai is an AI-powered assistant for scheduling meetings. Here are some excerpts from a Product RFC for building a UI component that allows for multiple participants to schedule meetings. In describing the What, this example went pretty far into the details. It includes interaction mockup as well as specifying the internal logic concepts like REQUEST_MEETING_AVAILABLITY, PROPOSE_LOCATION, REQUEST_LOCATION, etc needed to make this feature work. For the purposes of this article, there’s no need to understand these concepts.
There is often more than one way to solve a problem. This section documents the various approaches considered and their associated rationales. From the same RFC, here is an example of the Alternative Approaches to this Time UI.
To mitigate the risk of RFC turning every decision into agreement by consensus, it is important to have a place to log the difference in opinions that are heard and considered. Yet, RFC doesn’t require 100% consensus to be approved.
At x.ai, we required that at least 2 senior engineers sign-off every RFCs. And sometimes, we wouldn’t move forward with an RFC and will simply close it. You can choose your own sign-off criteria.
If you like this article, you might also be interested in my post on Manager Guidance Review for manager of managers. To learn more about RFCs, here are a couple of great articles on RFCs by Phil Calcado and Gergely Orosz that I would recommend.
At NorthShore.ai, we take a modern knowledge management approach to support scaling Customer Experience and Product teams. Hit us up to see how we can help your team improve productivity and delivery higher customer satisfaction through knowledge intelligence.