This article will show you strategies you can use to build a great performing team at scale by being a servant leader, through the eyes of an Engineering Manager.
Doctolib has three missions: improve the daily life of healthcare personnel, improve patient access to healthcare and patient health and build a team of entrepreneurs with humanistic values. Here is a summary of my experiences as an engineering manager (EM) and how it contributes to these missions.
When I joined Doctolib four years ago, there was only one engineering manager. The concept of feature teams was fairly new to us, as we were evolving from a more traditional front/back organization. We were only 10 developers and the role of an EM has changed a lot since then. I myself joined as a full stack developer and grew into an EM position after one year. This job transition is not uncommon at Doctolib.
CEO of your mini startup
The main mission of an EM is to take good care of their feature team. At Doctolib, we believe that your team is your first priority: before working on strategic topics or transversal projects, the most important thing is the wellbeing and efficiency of the team.
At Doctolib, an important fact is that the EMs are accountable for the delivery of their teams, both quality-wise and productivity-wise. But we are expected to help as coaches, not as superheroes. One thing that I came to realize and discover is how important it is to actually build and grow my team. Bear with me to discover what’s exciting about the role.
Building your team
At Doctolib, we grow so fast that creating new teams happens day in day out. A new team can start from the split of a large team or totally from scratch with a brand new mission. In any case, there will be some seats to recruit for. We have a Talent team helping us with that, doing most of the heavy lifting, but your role here is to be the hiring manager: take decisions on whether to recruit or not someone… And give hints to the Talent team in finding the best candidates for you!
You’re in charge of defining what you’re looking for. It’s very hard to detect and close the right talents, especially when you’re looking for some specific skills. That’s the most challenging, but also the most interesting part: as you compose your team, you’re accountable for all the decisions you make. You will have the opportunity to refine every open position: define expectations, what level of seniority you’re looking for, etc. Also, while all of our developers are fullstack, we try to select talents bringing complementarity and diversity to the team. But at the end of the day, the one question you need to answer is: “will this candidate be a good fit for the team?”.
My advice is to focus less on the candidate’s track record and more on what happens during the interview. In my first attempts at interviewing, I was very focused on the previous experiences of the candidates. I quickly realized that this only works to some extent, as many candidates are just following the rules and processes in place. My go-to questions are now roleplay situations: “You’re joining my team, I have a very good performer with high potential, and I’m asking you to mentor them. What do you do?”. I find it more insightful, as you’ll get to see how they use their previous experience and knowledge to solve a problem. This sounds simple, but completely changed my perspective on how to assess candidates.
And even if your first priority will be on your team composition, this is a collective success. Ultimately, what we care about is building the best company, not just the best team. As such, we’re always recruiting even if our team does not have an open role.
Developing your team
Although recruitment is an important part of the job, most of your energy should go into developing your team. You’re in charge of building personalized development plans for all individual contributors of your team, based on their expectations and the opportunities the company can offer.
That’s what I love the most about my job but also what challenges me the most: I have the chance to work with skilled people who deliver super qualitative work. Even if they need my support sometimes, they are mostly autonomous and would do just fine if I disappeared tomorrow. That’s where the difficulty comes: I constantly need to find ways to challenge them, push them to do even better, developing their potential to the maximum.
Recently, I had a quarterly review with one of my teammates, a super good individual contributor who joined the company a few months ago with huge potential. I want to see him shine more and have a bigger impact on the wider company, outside of the team. The encounter quickly shifted from congratulating him for his successes to how to get him out of his comfort zone, which challenges would interest him to pick up. I think this discussion summed up quite well the way we do things at Doctolib: we believe that the best way to grow people willing to develop themselves, especially our top performers, is to push them to stretch themselves and be bold, rather than staying in their comfort zone. Supporting our employees, especially our top performers, is a constant focus.
Through encounters like this, I have discovered a number of learnings on how to develop engineers’ careers, but these two are the most important in my opinion:
You have to adapt to your team
I realized with time how different are my individual contributors’ personalities and aspirations, and the need to adjust my management style to each individual. Diversity is a strength: as engineering managers, we are looking to compose a team, with everyone’s strengths and areas of progress to always have the best set of competencies for every problem. We don’t try to have everyone fitting in one mold at Doctolib, we rather develop customized career paths for each individual.
You need to focus on building up the team spirit
I didn’t quite consider at the beginning of my management career how team spirit is important and is different from what I thought it was. A team is not only a bunch of people working together: I’m spending a lot of time and energy in making the team really act as a team: organizing regular team building activities (we have a cooking challenge in a couple of weeks!), but also simple things like keeping the whole team focused on only one subject at a time.
But… How do we get good at it?
There is a full management framework you can use, with rituals and tools that you can implement. Or choose not to. The most common ones are the weekly one-on-ones you will meet every one of your individual contributors for 30min individually every week. This is used to build your relationship with them. I’m personally dividing my one-on-ones into 3 parts of 10min each: team member update, manager update and follow up on career development. While ramping-up as a manager, I listened to this great series of podcasts by Manager Tools on how to run these management duties.
We collectively try to build the best group of managers, as we know that will be the best way to propagate our culture. To do so, we built internal training programs to accompany our managers in their journey:
- The general manager academy: training sessions held by already established managers, which presents the basics of management at Doctolib
- The EM academy: much more focused on the EM role, with a lot of resources (ex: how to set objectives, how to manage poor performers…)
- The M-Mentor program: regular group discussion between new and experienced managers on their day to day challenges and learnings
- The management clinic: monthly sessions to discuss around a chosen topic, like managing individual contributors’ long term goals
In charge of engineering
What distinguishes engineering managers from people leads at Doctolib is that we are as much focused on the technical side of things as we are on the people’s side. I, as most of my colleagues, am far from being the best techie in my team. My role is to keep a global perspective of what we are doing technically, to maintain coherence and alignment with the global tech strategy.
Even if you’re not expected to be the best developer as an EM, you’re still expected to be hands on in some matters. This goes from challenging architecture, reviewing code and even opening a pull request sometimes!
We are working closely with the Product Manager (PM) of our teams. The role involves giving high level estimations of the effort needed by a project, participating in tech/product workshops, proposing technical shortcuts for our future projects, challenging the solutions so it makes sense technically…
Once the roadmap is defined, we’re in charge of the delivery. It’s one of the main missions of the engineering manager: make sure we’re on time and communicate any delay.
One of the main aspects of the job is to be the voice of tech. In our close relationship with our PMs, we need to be the two faces of a single coin: the PM carries the product vision, with customer needs, dependencies with other teams etc, while the EM is responsible for defending the tech decisions: do we need to add some budget to refactor some piece of code? Will the project generate performance issues? etc. Even if all EMs are expected to have a good product sense to some extent, they are the only guardians of a good, reliable tech.
Actor of change management
The cool thing is that we’re building the best team, but the true team is Doctolib. Similar to how we participate in hiring, we are also encouraged to get involved in various initiatives, and proactively push for change.
As we are growing so quickly, we face many challenges. To counter these, we started a lot of transverse projects, called “Tech Initiatives”. We grouped them under those categories:
- Tech quality: Have the best development & rollout practices, at scale. This contains tech debt management, security by design…
- Product Quality: Have the most reliable product, react well when not. Contains bugs management, performances…
- Dev Efficiency: Make it easy to find information, ramp up, and work with stakeholders. This is about knowledge management, tech onboarding…
- HR/Dev Community: Invest in the growth of our organization and its members. This includes hiring, career growth, diversity and inclusion…
Engineering managers are in the driver seat for these initiatives. Initiatives are open to anyone in engineering, on a voluntary basis, but EMs are typically more involved and expected to make things happen. All EMs are not working on everything: every EM will usually be part of 2–3 initiatives at the time at max. I’m personally working on EM academy, crisis management and hiring initiatives at the moment.
Small scale experiment
Tech initiatives have their importance, but sometimes you don’t need the big guns. One good thing about Doctolib is that we have the freedom to experiment at a small scale.
I have a great working experiment running in my team at the moment: innovation Fridays. One Friday a month is dedicated to personal development and experimentation. At first, it was really innovation oriented: working on proof of concept, trying to introduce new technologies to solve problems. But, today, in my current team, this took another purpose: learning. I had a lot of complaints within the team that we did not have enough learning time, as such I re-introduced this ritual for us but with a different pitch: this is a time for you to learn and discover things. You watch a conference, go through a tutorial, discover a new technology… And since it’s working swimmingly, I have just shared it with my fellow EMs a couple of weeks ago.
To sum up, the engineering manager is a vital organ of the organization. What I love about Doctolib is that as a manager, we put a lot of diligence in building that best team & culture. Overall, we are the servant leaders of the tech team: always there to serve, both our internal employees and our customers.
If you want more technical news, follow our journey through our docto-tech-life newsletter.
And if you want to join us in scaling a high traffic website and transforming the healthcare system, we are hiring talented developers to grow our tech and product team in France and Germany, feel free to have a look at the open positions.
Thanks to Alexandre Ignjatovic, Charlotte Feather and Thibault Martin for reading drafts of this and Gaëlle Malenfant for the cover picture.