Doctolib is an online and mobile booking platform that helps to find and a specialist doctor nearby and make an appointment.
Founded: 2013 by Thomas Landais, Ivan Schneider, Steve Abou Rjeily, Jessy Bernal, Franck TETZLAFF, Stanislas Niox-Chateau
- City: Paris, France
- Funding: 54.3M€
- Company size at time of writing: 304
- Tech team: 40 (from 5 a year ago)
What’s on your pizza ?
Eggplants, potatoes, tomatoes, gorgonzola at a small shop near Parc Monceau
You and the VP of Engineering Job
“I like to compare myself to the motor oil in a running engine”
Where do you come from ?
I come from an engineering school, then worked at OCTO Technology for some time as an architect, agile coach and tech lead. I’m a tech guy first, but I work on methodologies quite a lot.
I then moved to San Francisco to work for Viadeo for a bit more than 2 years to see something else than consulting, before coming back to France and starting at Doctolib.
How did you join Doctolib?
Doctolib was already about 100 people when I joined, mostly non-tech. We had 2 front-end freelancers and a back-end intern, and Ivan and Jessy (note: the founders) were working on the entire stack.
These two are ridiculously good and efficient and they tried quite a few times to grow the team but it didn’t work too well. It’s like catching a bullet train at full speed, you needed to get on board and deal with it, which doesn’t really work for everybody.
They knew they had difficulties when it came to onboarding and they needed a VP of Engineering to take care of the team’s integration. That’s where I came into play. My goals were to scale the tech team, hire fast and right, build feature teams that would become autonomous.
There’s a lot of methodologies and responsibilities that I needed to move around, as at the time only the founders were pushing to prod. That didn’t scale. At all.
So what’s your job, exactly?
I like to compare myself to the motor oil in a running engine. Real tech people can get trapped in their tech stuff, and forget to communicate — which is absolutely vital for a team to function.
We don’t want tech rockstars that don’t chose their fights and just play around with technology without thinking about the impact.
So that’s my job : I need to know enough about the stack to dive in when necessary, but I mostly see everything from a higher point of view to make sure everybody works at their best and is happy about the job.
Has your job changed since you started ? How ?
A lot. Really a lot. At the beginning it was mostly about showing by example: I would work with the team and show how things should be done, and it was great. We spent 4 months on continuous integration, 4 months on product processes, 4 months on interfacing needs, etc.
Then it became pure management — the type that makes a person grow in their job. Really time consuming, and really necessary. It was doable because of the limited number of people in the team.
When we started growing the tech team, I had to find relays that would do this job in their smaller teams, and that was quite a challenge, because we wanted to keep a flat hierarchy.
My job is basically to take the great vision of the founders and help them share it to the rest of the company — by showing it to my team in a clear way.
Tech tech tech
“Tens of thousands of doctors and some hospitals use us, and if Doctolib is down they just can’t work”
What’s your stack ?
Rails, React, and RxJS with a bunch of custom code. We’re not hosted on AWS because we have legal needs that make us run on servers hosted in France, that are cleared to manipulate health data.
We chose this stack because the cofounders are ridiculously good at Rails. And it’s a pragmatic choice for the web.
Have you had to change it since you started?
We run a big monolithic app, on Rails and Postgres, and we used to run all the search on the full-text search capabilities of Postgres.
We made a big switch to Elasticsearch, because with the growing load, the production environment was becoming slower. The migration complexified our stack, which we didn’t like — you need new expertise — but was necessary.
We have a Postgres expert that will join the team soon — maybe we’ll be able to go back to full-text search in the database with the right performance.
Have you ever faced a crisis ? Site down or something ?
We run on small hosting providers, so they don’t have Amazon’s SLA. Some things can be down a bit from time to time.
Now that we’re getting big, it’s a real issue: tens of thousands of doctors and some hospitals use us, and if we’re down they just can’t work. So we’ve built a passive datacenter that replicates all the data and that can take over if the first one fails.
In theory, the failover should take a few minutes. Last time it happened, it took us longer that than to come back online — need to reheat the caches, reroute DNS, recreate VPN and IPSec tunnels, etc.
So there’s still some work to be done on that side!
The VP life
What’s the hardest thing in your job, right now?
Build a rockstar team, and define what we mean by “rockstar”. There’s a certain mindset that we’re searching for and that is not easy to find: we’re not here to make the web change, we’re here to use the web’s best practices to build the best product.
But when you hire the best tech people around, they can have a tendency of wanting to build the best technologies, and not necessarily the best product.
What is your most important responsibility?
Align all the devs on the vision of the founders. I came to Doctolib for the vision, and I knew I would be helpful at communicating it to others team members in an explicit manner.
So I need to keep that balance between having bright, very exigeant cofounders and not over-controlling everything. When you don’t control everything, some errors might slip in, and it’s OK. My job is to make sure these errors are as small as possible, and that is achieve by all being on the same page.
If you had to change something you did since you started?
Use more case studies to share the vision of the founders and their way to build products. Technology is an enabler and not an end by itself, and we are not taking enough time to show what that really means — with concrete examples.
So we’re being reactive when there’s a problem, and we should change that to being proactive.
The Doctolib people
“Never lower the bar. For somebody to join the team, they have to be better than somebody currently in the team.”
Describe your tech team
When you have good and bad devs in a team, productivity issues arise. The developers we have in the team belong to the top 1%, if not the top 1‰.
Our tech team is already brilliant, and can become magical if the product vision really settles in
What is the main thing you are looking for when hiring?
Pure tech level and pragmatism.
I used to spend 50% of my time interviewing during the first 6 months, to grade tech tests. Now we have somebody that takes care of tech HR.
A hiring tip?
Never lower the bar. For somebody to join the team, they have to be better than somebody currently in the team. I often ask the junior guys if they think the person they just interviewed is better than them.
You’ve talked a lot about vision
Where do you see the company in 2 years?
The tech team should be about 60 people, and fully autonomous. My goal is to become useless! When I talk about autonomy, I talk about product, performance, crisis management, security, architecture, etc.
We’ll also be the incontestable leader in Europe.
What are the biggest problems that you will face to get there?
Address all doctor’s specialties while keeping the product simple and intuitive. They all have specific needs, but we’ll have to find a way to stay focused.
Interconnecting with software packages that hospitals currently use is getting harder and harder as well, because the technologies might be old and very slow to move.
We’re already at our fourth version of the interconnection platform to keep simplifying it!
Jobs : https://www.doctolib.fr/jobs
Article written by Alban Dumouilla and originally published on CTO.Pizza