Nicolas de Nayer (Doctolib) : The art of growing tech teams ! (full script)

We all know Doctolib. Some of us have known about it for a few years. For others, the Doctolib experience is more recent and stems from its link with the Covid-19 pandemic. If there is one tech company in France that embodies success and scalability, it is Doctolib. To give you an idea, we’re talking about 40 to 50 million appointments made per month in 2021. So, let’s talk about engineering and scalability with Nicolas de Nayer, VP Engineering at Doctolib.  

You’ve played a key role in the group because you’ve been involved in building the teams and deploying the tech dimension of the company. Before talking about your role, could you summarise your career and experiences before you joined Doctolib? 

I am a developer first and foremost. For personal reasons, I came to Paris and that’s where I discovered Octo Technology. I fell in love with this company and their methodology which was very innovative for the time. I decided to join them and I spent three very intense years there which taught me a lot as an agile coach, architect and tech lead. As a consultant, I was sent to Viadeo for a large-scale agile transformation mission. This assignment was very interesting and varied. And it went so well that Viadeo offered me the opportunity to take over an office in San Francisco. There, I stopped consulting to invest more in the company. I managed a dozen employees with another person from Octo Technology. We had a great time!  

And then, in the summer of 2015, Jessy from Doctolib came looking for me and pitched me Doctolib. I knew Ivan and Jessy, two of the founders of Doctolib. They explained the project to me and how I could be complementary in this adventure. I decided to leave the surf and the sun of San Francisco to come back to the grey of Paris to help them in this adventure. 

What was your mission? 

I don’t think they’ll mind me saying this, but I arrived to make them useless and even to make myself useless. At that time, Doctolib had 80 people but at the tech and product level, there were only three people: Ivan and Jessy with an intern and a freelancer. The four of them were the tech and product department. 

And the rest of the teams did what? 

The CEO, Stanislas, started by making Doctolib a commercial war machine. He recruited excellent people and created something really efficient from a commercial and operational point of view. Those 80 people were support, administration and business. And I was surprised! I knew that on the tech and product side there weren’t many processes in place, but I knew it worked. I was especially surprised by the maturity of the company on the non-tech and product side. It was very well managed.  

On the tech and product side, there were good practices and a very good foundation. The code was already tested and automated testing and deployment were already in place. But where it wasn’t working so well was in the management, methodologies and recruitment. That’s normal, because the people who were managing were very good at the technical side and the product side. They are the best developers I have ever seen! For the first two years, they did almost everything. And it was impressive that the company got so far with so few people.   

So you brought maturity to the process and organisational side? 

Exactly. Alone, we go fast; together, we go far. With two people, they had already gone very fast. But at some point, the model reached its limits. We had to scale up and for a company like Doctolib, we had to do it with more people. This means more processes, more methods, more structure in terms of recruitment, etc. That’s when I arrived. Since the beginning, my role has been to find the best process and the best methodology for Doctolib to function, but, basically, I’m looking for a lost efficiency that will never be found. It can never be more efficient than two people who went to the same school at the same time and who have already created companies together. Ivan and Jessy are like an old couple. They don’t talk, they understand each other. At the time, there was no process for the technology nor the product. It worked well with two people, but when you’re 350 in the service, it’s necessary. Otherwise, everything collapses!  

In terms of business, can you tell us about the positioning of Doctolib today?   

Before I arrived and during the first few years I was there, Doctolib was an agenda for practitioners. We did it well. Doctors paid for a service that helped them optimise their practice. The fact that we had a very clear focus was very good, because it prevented us from spreading ourselves too thin and we were very efficient. At the moment we said to ourselves, it’s OK, our service is sufficient, we are successful everywhere in France, now we can start to open internationally. But there again, we chose to go gradually, and we did it step by step, carefully. About a year and a half ago, we revised our vision a little. Today, our mission is to facilitate access to care for patients and to help practitioners and health professionals take the time to do their job without worrying about administrative tasks. Today, Doctolib’s strategy is to offer relevant products to practitioners and health professionals while facilitating access to care for patients. It’s a virtuous circle that is very good for practitioners and for patients. And so much the better for the growth of Doctolib! 

In terms of numbers, can you give us an idea of the size of the universe you are in? You said that you went from 3 to 350 in 5 or 6 years. More specifically, what are we talking about today in terms of use of the platform, traffic, etc.? 

When I arrived, we had surpassed 3,000 practitioners paying Doctolib. Today, we are at 150,000. But in fact, the numbers have doubled every year since I’ve been here, both in terms of team size and traffic. From time to time, we have surprises like the vaccination campaign when everything accelerates even more. Since the beginning, we’ve been watching the growth rate of our growth. We will look at how much we are accelerating. The daily pace is 20 million appointments per month, 10,000 HTTP requests per second on Monday mornings, more than 100 million visits per month, 500,000 lines of code, 350,000 lines of test code and three production releases per day.  

What does the architecture of the business look like for making it grow like that? 

Today, we’ve managed to keep our architecture very simple. The simplest possible for the degree of complexity we’re trying to address. For the vast majority of Doctolib, it is a Monolith Rails with front-end code in JavaScript React and we also use Single Page Applications. We have SPAs on the patient side, other SPAs on the doctor’s side. Behind that, there is a Ruby on Rails backend. 90% of the code and business logic runs in there. On the side, there are small applications that are a bit hybrid. To keep it running, we take great care of it! It’s a fairly simple engine, but one that is optimised and well looked after. All of it is done without any application cache. Appointments and availability are calculated each time a user visits the site. On the side, for everything that is asynchronous, we will have Redis and standard frameworks on Rails. We’re going to start putting text script in a few places. We also have Elasticsearch on the search part essentially.  

Was your simple architecture vision set from the start or did you choose it after several trials, errors and learnt lessons? Has your architecture always been like this, or has it evolved?  

In fact, architecture is going to change and is already changing. We’re setting up a lot of projects at the moment to make it evolve, but it’s only the continuation of the principles that were already established. We have always tried to keep the architecture as simple as possible. For example, to respond to a problem very locally, we are aware that it is simpler to look for another tool. But then you have to call on people to develop and maintain these tools in terms of code and run once they are in production. So, after a while, you end up using a thousand tools for a thousand different problems and there is no consistency. I think that’s where you have to force yourself to keep the stack simple and understandable by everyone. That’s what makes it possible to go very far. Also, often in this type of situation, we end up realising that we haven’t even got to the end of the tools. Nevertheless, at some point, you have to know how to let go and change tools without pushing to the extreme of optimising tools that are ultimately unsuitable. 

What are the other main aspects or pillars of the tech philosophy at Doctolib? 

For me, the first is what I just mentioned: keep the stack simple. It’s a value that we display on our walls and that we try to keep in mind. It’s a will that was present before me! It’s something that I’ve taken up and that I communicate about.

Another value that is very dear to our teams: user first. The principle is to try to reproduce the magic combo that I explained above of Tech and Product. When developers are able to take a step back from why a feature is being made, they are 100 times more efficient. If a developer has a good understanding of the need expressed by the product team or by the strategy, he will have a simple and effective solution to provide with his technical prism. We really try to have developers who are able to think and challenge products to find shortcuts and save a lot of time. 

That implies that the teams can propose initiatives and challenge the use in case we ask of them…  

Yes, and that brings me to another value which is very dear to the teams. It’s the ownership aspect. We really want each developer to take over a project one turn at a time. It doesn’t matter whether they are a new joiner or an experienced developer. We don’t have a single tech lead who frames a project upstream and manages it. This role rotates and, in turn, everyone is the pilot of the project with the product team. This developer is going to be the tech holder for this project and is going to do it their way with the product side to talk, to be in contact with the hospitals, the patients or the doctors, and try to understand the need with their technical prism. In this way, they will have good ideas and be able to challenge the product. Then they will frame the project with the product team and will be responsible for steering it.

When I say project, it’s always small features with a maximum development time of 3 weeks. Even once it’s in production, it’s the same developer who will ensure that it works properly. You build it, you run it. They will check the performance and check for errors when it is in production. But it’s not necessarily the developer who will do this. Instead, they will make sure that the team does it well. We really want to make all the developers accountable.  

Another very important value for us is guaranteeing security and reliability. This is the data security aspect. We invest a lot in it, but we can never be perfect on security. It’s a very sensitive subject and we force ourselves to spend time on it. In fact, it accounts for 15% of our feature time. That’s a lot, but as we’re never perfect, we always want to try to go further. Especially as we are increasingly in the spotlight. We must always try to get closer to perfection and I think we are on the right track even if we will never reach it. The reliability side is the notion of reliability. We are increasingly deployed in hospitals and with practitioners, and they have to trust us. If the servers don’t work, for example, this can have a very strong impact. We have a great responsibility and our systems must be unbreakable.  

The last value is learn and grow. This is very important to me. When I do one-on-ones with my teams, I always ask the same questions: do you like the company? and are you bored? A bored developer is someone who leaves, so the growth aspect for our teams is essential. If a developer comes to Doctolib and tells us that he wants to learn alongside us and then plans to create his own company, that’s fine with us. That’s the attitude we want. In fact, we want our team members to have this desire. Anyway, we scale so fast that they will never stop learning and can stay with us for a long time. In fact, that’s what’s happening to me. I’ve been here six years and I’m learning every day. 

When you talk about team autonomy, what does that mean? How do you manage this autonomy? Do you recruit senior staff or do you guide newcomers towards more responsibility? And how do you manage on-boarding to pass on the Doctolib culture? 

As far as on-boarding is concerned, before I arrived there was already something called the Doctolib Academy. It’s a programme aimed at everyone who joins Doctolib. Participants follow a common core curriculum, experience life in the other departments, listen to speakers about the medical world and are trained in the Doctolib culture and world. This academy has been around for several years, we even created the Tech Doctolib Academy which has now become the Tech and Product Camp. This is a two-week training programme which is added to the two weeks of the Doctolib Academy and which introduces people to the Tech and Product mechanism of Doctolib.

We try to make people efficient and autonomous as quickly as possible. To encourage autonomy, we are also trying to get closer to the initial model that existed in the company by bringing together all the different professions in the same team, a feature team: strategy, product, design, tech, etc. How do these teams work? By giving each team a KPI that was initially defined in the strategy. Rather than giving each team 10 topics, we give them one with a single measure and then each team moves forward, prioritises and manages as they wish as long as they keep the result in mind. We’re trying to move more and more towards this model. Each team is accountable for the KPI and not for the projects delivered. 

In terms of KPIs, how are they managed? Are they annual or on a different frequency? 

We want our KPIs to be actionable and easily re-challengeable. There are no hard and fast rules. We don’t organise big meetings dedicated to KPIs or precise rituals. For us, a KPI must be within a certain range and we hope that it will last about nine months. But in reality, we adapt to each KPI and each project. Taking into account the external events and our rapid growth, we have no choice but to be able to question ourselves if necessary.   

You talk about feature teams, how are they composed?  

We apply the Pizza Team rule that comes from Jeff Bezos. Each team contains about 10 people, including, from a full stack point of view, a minimum of 3 developers and a maximum of 6. As soon as a team reaches 6 developers, it’s time to split it into two teams. A good team is made up of 5 developers, 1 or 2 product managers, a data manager, a designer and sometimes other functions depending on the needs. On the data side, we can adapt from time to time and have profiles that are a little more atypical. We also avoid reorganising the teams, we prefer stability. In my opinion, it’s a bad idea to reorganise the teams for each project. A team has to learn to work together and find mechanisms for efficiency. Breaking up a team and a dynamic is, in my opinion, a mistake. We want our teams to be stable over time. Moreover, we have chosen to locate them in the same place.

Since developers have a natural tendency to group together with their core business, we prefer by default to bring them together by team so that they are there and can participate. Today, at the technical level, everyone is either under the CTO/COO or the CPO/CSO. Then there are lots of mechanisms and rituals to ensure that everything works well. In addition, there is also the design hierarchy and the product hierarchy. And as far as security is concerned, it is managed by a central team which deals with other things in parallel. We also have security ambassadors in all the teams who act as relays, as well as feature teams entirely dedicated to security issues.  

On the tech side, the quality of the organization is very important to you. How does this take shape? 

In the principles that are somewhat immutable with us, there is: code that is not tested is not code, quite simply. If there is no automated test, it’s useless, and this code must not go into production. That’s a cornerstone that was there before me and is still there. That’s why we do so much testing. But that’s also why, with our 150 developers, half of whom weren’t there last year, we’re able to put it into production three times a day.  

On the other hand, in this area, we pay attention to the work distribution. A developer spends 50% of his time making new features, 10% of his time is devoted to security, that we mentioned earlier, 15% of his time is for fixing bugs and after that, he has 10% where he has to do technical work, i.e. optimizing, improving and updating the existing system that has become obsolete. The testing side is non-negotiable. Something else that is very important to us is the code review. Absolutely no code can leave without being reviewed by someone else. It is much more than detecting bugs, it’s also about sharing knowledge. The person who writes the code can be junior or senior and the person who links the code can also be junior or senior. In fact, all configurations are acceptable for a code review. It can be the classic: a senior reviewing a junior. They knows the best practices of the company and will be able to give them advice, coach them, etc. But it can be the other way round! A junior always likes to find the flaw in a senior’s code and so will be more subtle, more precise, etc. By reviewing ttheir code, they will see how the senior works, but they will also have fun going further to find the small defects. Another possible configuration is two juniors working together. In this case, they will challenge each other and be more careful because they have a great responsibility. All configurations are great. 

How are the skills of the teams managed? 

As I said, there is the Doctolib Tech Academy which is now the Tech and Product Camp. All the sessions are documented so that everyone can go back if they need to, but there’s something else at Doctolib that I really like too. Historically it was called Starsky and Hutch, today it’s called Unique. As we were confronted with recruitment, growth and training issues, we set up a programme which consists of learning a set of skills (Elastic Search, React, etc.) in duo with another Doctolib employee in order to be successful within the company. The idea is to challenge each other on these subjects until each has reached the minimum level required. It’s voluntary, but in the end all the developers take this co-training. It’s a real opportunity! We have also set up a tech time. Every fortnight, each team shares failures or successes. We also have moments during which the tech holders share their projects with the rest of the teams.  

On the process/organisation side, how do you approach the agile methodology? Do you apply it to the letter or have you adapted it to Doctolib? 

When I discovered these agile methodologies a long time ago, I became a fan and wanted to apply them everywhere. Then, in fact, as my experiences progressed, I realised that it was contextual. When I arrived at Doctolib, I was mature enough to know that we had to adapt. We started with a haphazard methodology that represented the minimum and then we evolved it over the years. The only thing you have to apply from the start is continuous improvement. And the simplest thing is a retrospective, whatever its format. 

Today, at Doctolib, all the teams have a common base. My job is to manage to preserve this common base to ensure that we can control, that the teams remain within the rules, avoid reinventing them each time and pilot more easily at the macro level. There is a common base but, in the main principles, each team chooses the methodology it wants. Some will prefer Scrum by the book with very defined two-week sprints. Others will use planning poker, while others will not. Some teams use the Kanban methodology. Others devote a whole day to bugs to make sure they’ve done their 20%, while others assign this work to one person. Teams adapt and for me that’s the most important thing. There is never a single methodology that you can find in a book and apply as is. It’s very contextual and it has to be done step by step. 

What were the right decisions for you in terms of tech management at Doctolib? 

For me, the best thing is to make the teams responsible. That can be scary! Doctolib is a big machine. When you have a bug in the middle of the day, the impact, the stress and the pressure generated are impressive. We may be afraid; we may want to protect ourselves and leave only the important things to those who know, but in reality, what we have been doing since the beginning is to make people as responsible as possible, and that has many virtues! On the other hand, you have to supervise and accompany, but it is extremely powerful. It helps the teams to become aware of what they are doing and it’s fun for them. In general, the more responsibility you give them, the more they blossom, grow and stay. 

Looking back, are there things you would have done differently?  

Yes, there is the middle management side which is very hard and long to build. On that side, I dragged my feet too much. I wasn’t quick enough to see the prospects for possible development. Even if I had the vision, I was slow to share it and to execute it. And that happened in the early years when I had almost 20 people on direct report. I knew that the right limit is about 7 people, but as I couldn’t find a relay at management level, it took a long time, especially as you should never lower the bar on recruitment. I couldn’t find a manager at the right level and it started to become complicated to manage.

It’s so long and complicated to find the right managers who are in line with the values and who are relevant enough. I made this mistake two different times! Today, I am happy with my management team, but it was very laborious to build it. I think I could have anticipated the management stack better. When you start to think that it’s getting complicated, it’s already too late. It can take years to build the right team.  

As VP Engineering, what are your objectives? 

Today, I think they are very heterogeneous. In the early years, it was very much about recruitment, management, structuring… Today, it’s always about recruitment and monitoring KPIs. I also have to make sure that the teams are in tune and that we share the same point of view.  And at the moment, I’m working with the team on a new mission. Today, Doctolib is no longer a start-up, it’s a scale-up with very strong ambitions. And to go further and continue to evolve, we are looking abroad for inspiration. Our engine is very well oiled, but it will probably not be enough for our ambitions, so we are currently thinking about making a transition to something capable of supporting our growth. Therefore I’m looking at Netfix, Airbnb… Companies that have experienced the scale we’re moving towards.  

Do you talk to them today to find out about their experience and their feedback?  

Clearly, yes. That’s what I love about France. I find that there is a very good tech community. It’s a small world and everyone talks to each other, it is open. Frankly, hardly a week goes by without me talking to a CTO from another company, or a VP, or a director in France. And then there are a lot of French engineers in American start-ups. It’s very easy to find a contact. In addition, as there are many of us at Doctolib today, we benefit from the network of our employees. Having an informal discussion with these companies is actually possible and always very rewarding. 

When you evolve like you do, you realise, on a personal level, that your limits can be reached: technical, skill-related or management limits. How do you manage your career development and the fact that sometimes you may have to recruit your own boss? Does that require a great deal of acceptance of your limits? 

The first thing was the example set by Ivan and Jessy. They were founding CTOs but they came to me to help them. In the end, our trio worked quite well, we managed to create an organisation from scratch from 0 to 80 at the Tech and Product level. It’s a great challenge! But at one point, we were faced with the ambitions of our CEO who wanted to take us to 160 the next year, 320 the year after, then 600, then 1000, so we started to question ourselves. Up until then, I had already used all my skills and tools to go from 0 to 80. That was already great! We decided to recruit someone to take us to the next level. Yvan and Jessy were a good fit because they like to stay close to the code and the product. Even if we have to remain objective in recruitment, I’m not going to lie, when I met Philippe, there was immediately a connection. He had serious skills and we found and trusted each other. He lifted the bonnet, he saw that there was a good engine which worked well, so he trusted me and gave me a lot of freedom. I was very happy to have someone who gave me feedback on my work, who confirmed that I was going in the right direction and who sometimes recommended some adjustments.

On the other hand, the fact that I was there, and everything was going well, also allowed him to take on other roles in the organisation. We’ve moved to a higher level thanks to his seniority and his experiences. I have a mentor again, something I hadn’t had for a few years! So, it’s a decision that may seem hard at first, and if the feeling hadn’t been there with Philippe it would have been complicated, but in reality, it was necessary. You must accept that you still have a lot to learn. We will always have more to learn! 

How do you see your role evolving? Do you have to be always on the cutting edge, keep coding and really understand the tech? Or do you leave that to others?  

This is a personal matter, I think. On a personal level, I regret not coding anymore. The other day, I was tinkering with something for fun, and I had a lot of fun, but from a professional point of view, it’s obvious to me: I don’t have to code anymore. It’s no longer the priority. When you’re a manager, the first thing you have to ask yourself is are people okay? If everything is OK, then I can move on to the next task: are we delivering well?, is the quality there? If everything is fine, I can move on to the next task. In terms of product, are we doing the right thing?, are we going in the right direction? And finally, after all that, there are still more transversal things: do the teams work together? If all that is good, then eventually I can go and code, but even if I manage to do it, there’s bound to be an emergency or an unforeseen event that I’ll have to deal with, so it’s not relevant because I’ll end up dropping out, handing in something that’s a draft, or not having the time to finish it.  

On the other hand, this transition is very gradual. I think that when you first become a manager, you still code 70% of your time. As you become more abstract as a manager, you have to code less. Nevertheless, a quarter of my time is dedicated to technical impact. It’s not through code, nor through code review, but through technical framing workshops, architecture, big decisions on scripts, etc. I think that not being in the code anymore; having been in the code, but not being in it anymore; one has sometimes even more power and hindsight. You have a higher degree of abstraction and that allows you to make better decisions.  

A word about the future. When do you plan your road maps? Because ultimately, given your pace, you must navigate on a fairly short time horizon? 

Absolutely! We’re never more than 3 months away. Of course, we have a long-term strategy, but when it comes to the features to be developed and the projects, there’s no point in looking further ahead. Everything is moving so fast that there are other things bound to happen quickly, such as teleconsultation, Covid, vaccination, etc. We must adapt to the market! We must adapt to the market! Our road maps are not really road maps. As I was explaining, we work more with KPIs per team that we review every 6 or 9 months, and the teams review their projects about every 6 weeks. There are always unforeseen events and changes in priority! 

Is it exhilarating or is it rather scary to be so visible at Doctolib? Do you like this exposure within the group? 

Well, there’s a clear exhilarating and rather fuzzy side. I remember two days after I arrived at Doctolib, I was told that we were going to be on France 2. Today, it’s a little more frequent, but it’s becoming a daily occurrence, and you get used to it. To be honest, it’s exhilarating and exciting, especially to feel that we can have a positive impact! There’s no doubt about it, we have a high degree of visibility at Doctolib.

In the early years, we were seen as the saviors, the super start-ups. Now that we’re more than a few years old, we’ve got a lot more visibility. And now that we’re increasingly visible, there’s this other side of the coin that’s tricky to manage. People point out the bad sides a bit more and criticise us, but I’ve been with Doctolib for 5 years, and from my most sincere point of view, we try to do many positive things. For example, we invest a lot in security, and we try every day to go further to help security in French and European technology. We have passionate people who go out of their way to help the government with vaccination centers and do much more. And then, from time to time, we get a lot of criticism on social networks or on TV. Sometimes it’s clearly unfair. So, it’s hard, but that’s the other side of the coin. It’s also interesting to experience it from the inside, to realize how Doctolib’s image has changed in the media and gone from being a small start-up that is still adored to a larger company that is criticized, while on the inside, nothing has changed. It’s the same passionate and well-intentioned people. 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.