How to use RFCs to take decisions at scale

Marco Ziccardi
Feb 26 · 4 min read

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.

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

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.

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.

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

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.

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.

Doctolib

Improving Healthcare for Good

Marco Ziccardi

Written by

Engineering Manager | Kaizen advocate | Music addicted

Doctolib

Doctolib

Founded in 2013, Doctolib is the fastest growing e-health service in Europe. We provide healthcare professionals with services to improve the efficiency of their organization, transform their patients’ experience, and strengthen cooperation with other practitioners. We help pati

Marco Ziccardi

Written by

Engineering Manager | Kaizen advocate | Music addicted

Doctolib

Doctolib

Founded in 2013, Doctolib is the fastest growing e-health service in Europe. We provide healthcare professionals with services to improve the efficiency of their organization, transform their patients’ experience, and strengthen cooperation with other practitioners. We help pati

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store