Doctolib Engineering Pathways — (Part 3) How we built a Senior Individual Contributor Path

Illustration Credits to Lyne Dang

This is the last episode of a series of 3 blog posts. You can find out about how we built our pathways in the Part 1- Why we changed our pathways and Part 2 - How we structured our pathways.

In this post, I want to share our strategy to invest in the Senior Individual Contributors Path in the Engineering Organization. In other words, how to get rid of the feeling that ‘management is the only credible way to grow’.

Do we really have a problem? Why would we want senior ICs?

We did not come out of nowhere. Anticipating that there would be a need for more senior profiles, we had created a new role (“Principal Engineers”). We had 6 of them, with 1 open role. This did not go far enough, and we realized that the global perception was that unless you were part of that small group, there was nothing for you.

The first question we asked ourselves was: do we really need Senior ICs? And what do we need them for?

Why large companies need Senior ICs

As Doctolib was a small organization, our structure was fairly simple: 1 feature team = 1 pizza team. We had a small group of managers, each responsible for the team, and our growth would go through the number of teams we created. Our product and organization were simple enough that everything could be solved within the feature team. Worst case scenario, we had our two co-founders Ivan & Jessy to save us. But as we’re getting to a different size, things change.

As we grow into a larger company, we need those senior profiles! Once you go beyond a certain number of teams, everything becomes more complicated. We have larger technical challenges (e.g. product line), and organizational challenges (e.g. alignment). We hire senior managers or directors, but they can only do so much as they already have many responsibilities within their teams. Having senior ICs is a way to raise the bar on topics that require a lot of technical expertise, or cross-team alignment.

Why Doctolib needs Senior ICs

One analogy I like is that as you’re trying to build a cathedral, you will need new roles (e.g. for coordination, or technical specializations). Software Engineering is no exception to the rule. At Doctolib, we’re exactly there. We are launching new products, rolling existing products to new countries and doubling the size of our team every 18 months. Those all bring new challenges that require a full-time effort, beyond the existing feature teams. Having full-time experienced team members is very valuable to us. They will talk about those challenges better than me, so I highly recommend you look at how we restructure our Architecture, or how we try to address technical debt and propagate that mindset to teams.

No, our managers are not ‘people managers’

Now, don’t get me wrong! This does not mean that Engineering managers at Doctolib are ‘People Managers’ focused only on HR responsibilities. There are many technical challenges within their teams, and they are expected to be a key contributor to the technical vision of their team and outside. But it’s helpful to have people with a dedicated focus, bandwidth and expertise to address key topics.

Step 1: Create clear expectations for the role, and make it attractive

If there is no need for the role, or if the people in those positions do not feel that they have the level of influence they would have as managers, you will very likely fail in building the senior IC path. So the first thing you want to do is to give space for those roles.

Carve out space for those roles

• There is zero point in having a path for Senior ICs if you don’t have a need for Senior ICs. One thing we did was to carve out more space for those roles, and try to clarify what types of profiles we needed, and how they will contribute to making the organization better.
• Obviously, once you have established the business need, you need to open a certain number of positions for the role. We more than tripled the number of Level 4+ positions in 2022.

Set realistic expectations for those roles

• A big reason people go to Management is because it’s the only opportunity that they see. Very often, Senior IC expectations, we ask people to be good at everything, or they don’t know where to go. One thing we did at Doctolib was to set a clear North Star so people feel they actually have a place to go.
• It’s not one-size fits all: the more senior you get, the harder it is to be an expert in everything. We were actually greatly inspired by the staff-eng blog and decided to create 4 Archetypes (Architect, Solver, Project Lead, Right Hand). Those archetypes have different attribute expectations, which focus on their strengths. Rather than reinventing the wheel, we took the learnings from other more mature companies and implemented those archetypes, adjusting them for Doctolib. This helped us ensure we would not be too far from a true business need.

Give those roles influence in the organization

• Make them part of your leadership forums. Too often, some decisions are reserved to the ‘manager group’. But senior ICs should be key contributors to decision-making, beyond purely technical discussions. They interact with other team members, they have a perspective on the company. Rather than thinking in terms of “Engineering Management”, it can be helpful to think in terms of “Engineering Staff”. Senior ICs don’t have to be in every single discussion, but they should have a default seat at the table. This is what we are doing, our Staff Engineers are in the Domain Staff meetings alongside managers, they are also involved in level-up committees, for instance.

The Senior IC Archetypes at Doctolib

Our Staff Engineer Archetypes at Doctolib

Now that we had a North Star, we had to make it happen.

Step 2: Build a path, and make it achievable

Another learning from our previous model was that despite already having Senior IC roles with ‘Principal Engineers’, what we missed was the path to get there.

Here are a few tips on how you can build this path.

Make the path continuous

• Make your path truly incremental, with intermediary realistic milestones. If you create too much distance between two levels, you will make it very hard for people to both project themselves in the role, nor will you trust them to be successful in this role.
• Give people the opportunity to step up in their current roles, by giving them stretch assignments. Our philosophy around pathways is that a level does not give you ‘exclusive responsibilities’ and career growth should always be seen as a continuous progression. As such, make sure to always find ways for your employees who are comfortable in their level to take some, not all, of the responsibilities from the level above. For somebody close to ‘Staff Engineer’, this could mean taking a leadership role in cross-team rituals (prioritizing technical debt within a domain), in an initiative (shaping how we run interviews), or in specific cross-team projects. You need some practice in order to be ready for the next level.

Be flexible when designing the roles

It’s pointless to ‘codify’ the work of a very senior employee. There are many ways you can bring value. It’s ok to be experimental — if they don’t see a good fit, we can tweak the model. What matters, ultimately, is that we’re landing on a model that brings value both to the company and to the employees. This is why, sometimes, you’ll see archetypes step out of their role and do what is best for Doctolib, not what is written in their job description.

Step 3: Find role models, and showcase them

Many companies will claim they have a Senior IC path. But when you dive into it, you’ll sometimes realize that what they mean is that they have codified pathways, and maybe 1 senior IC that fits the role.

The issue is that nobody likes to think in terms of abstract concepts. If you cannot ‘see’ it, then it’s as if the path does not exist. So, you want to make it as concrete as possible.

The main tip I would have for you is to find role models, and give them visibility. Concretely, this means identify people who could serve as pioneers, put them in the position, and ‘showcase’ them. This has two main advantages.

• Role models are the best ambassadors for the IC Path. People can identify with them (you need to find a diverse set!), they can ask them questions, learn from them. Rather than asking “what role do you want to have”, you can ask them “whose job would you like to have”. This makes career discussions much easier.
• Role models can help stress test the model — you can see what works, what does not, and adjust expectations accordingly. As they get more maturity in the role, their responsibilities and the way they interact with other people get clearer. And it becomes more obvious to anyone what is required to be successful in this position.

Luckily enough, we had a few different personalities who could serve as role models for each of our archetypes. All of them went through the management path at some point, but realized they were more fulfilled in an IC position (hear about one of the stories in this blog post).

Last, but not least, we launched a dedicated initiative to amplify their internal and external visibility of those role models.

• Internally, we are investing in mentoring, internal videos, live-my-life sessions, so our more junior folks can understand what this looks like and project themselves in one of those archetypes.
• Externally, we’re hoping that they can show more about how they contribute to Doctolib’s strategy and execution in an expert position. You can hear about their work below.

Some of the articles we wrote:

• Michel’s (Right Hand) approach of Technical Debt
• Jonathan’s (Architect) work on modularization
• Nicolas’s (Architect) description of our Vaccination efforts)
• Nicolas’ ‘On my way to Staff Engineer’(for now in French)
• Nicolas’s ‘Life my life as a staff Engineer at Doctolib’ (for now in French)’.

This is the end of the blog series on Career Growth. I hope that this gave you a few hints behind the why and how we’ve invested in the topic at Doctolib.

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.