How to use RFCs to take decisions at scale
In this article, you’ll learn how we managed to take decisions at scale at Doctolib, by using the Request For Comment process.
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 standardisation.
How can you ensure everybody in the team has the necessary visibility and, can participate and contribute to technical discussions? To solve this problem at Doctolib we introduced the Request For Comment 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.
From open source to corporations
During the following years the adoption of RFCs by the open source community was a natural consequence. Open Source, by definition, aims to involve an entire community in order to achieve the best outcomes. Of course reaching an agreement among hundreds of people is far from easy and smooth. That’s why many mass opens source projects, like Vue.js or Rust, use RFCs to drive the evolution of their projects.
Nowadays, with the adoption of digital products at mass scale, many tech companies have reached “corporation size” and they are facing problems similar to those in open source. On top of that the engineering ecosystem has changed drastically. A society of communication and disintermediation also requires participation, contribution and collaboration.
As a result many private companies have begun to introduce RFC or equivalent processes to enhance the exchange between individuals.
How we use RFCs at Doctolib
The last year was significant in terms of growth for Doctolib. We are now more than 120 engineers working and evolving the application on a daily basis. We plan to grow even more during the next months and years.
For this reason in the summer of 2020 we decided to launch the Doctolib RFC process. Of course we have some specific rules and guidelines to ensure the efficiency and effectiveness of the process in Doctolib’s context.
When we need to follow the RFC process
We usually write an RFC when we intend to make “substantial” changes that impact the whole engineering organisation. What constitutes a “substantial” change is evolving and varies depending on what part of the ecosystem we propose to change, but it may include:
- New code conventions
- Replace vastly used libraries
- Refactoring big part of the application
- Changes to the RFC process itself
Doctolib RFC life-cycle
Before creating an RFC
A hastily-proposed RFC can hurt its chances of acceptance. Low quality proposals and previously-rejected proposals may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother.
Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other engineers to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.
While implementation code is not necessary to start the RFC process, a proof-of-concept may help the design discussion.
Recruit RFC sponsor
A sponsor is a seasoned engineer responsible for ensuring the best possible outcome of the RFC process. In particular this includes:
- advocating for the proposed design
- guiding the RFC to adhere to existing design and style conventions
- guiding the review committee to come to a productive consensus
- when approved, ensuring proposed implementation is prioritised and assigned to teams
People need to identify the sponsor before submitting an RFC.
Doctolibers engineering community feedback
As the purpose of RFCs is to ensure the community is well represented and served by new changes, it is the responsibility of community members to participate in reviewing RFCs where they have an interest in the outcome.
Community members have to:
- provide feedback as soon as possible to allow adequate time for consideration
- read RFCs thoroughly before providing feedback
- be civil and constructive
Review committees
The sponsor will request a review committee meeting, no sooner than 2/3 weeks after the RFC is published. The goal of the review meeting is to resolve minor issues; consensus should be reached on major issues beforehand.
Review committees must:
- ensure that substantive items of public feedback have been accounted for
- add their meeting notes as comments on the PR
- provide reasons for their decisions
The committee may approve the RFC, reject it, or require changes before it can be considered again. Approved RFCs will be merged into the repo, and rejected RFCs will have their PRs closed.
Prioritise and implement approved RFC
Once the RFC is approved and merged is the Author’s responsibility to write Epic and Tasks, in order to facilitate the prioritisation and implementation of the solution.
Takeways
After 6 months from its introduction we approved and merged more than 50% of the proposed RFCs. Probably the best achievement amongst them was the decision to introduce Typescript in our main monolithic application. This was something really difficult to imagine 1 year ago, however thanks to everybody’s participation and contribution we were able to achieve a result we think will improve the quality of the service we are providing to patients and practitioners even more.
Every single engineer at Doctolib brings with them a wealth of experiences and knowledge. We believe participation and collaboration is a key aspect of our evolution. There is not a single good reason why we shouldn’t create the conditions for everybody to contribute and participate in the growth of the company and the service. People are what makes Doctolib.
If you want more technical news, follow our journey through our docto-tech-life newsletter.
