Doctolib Engineering Pathways — (Part 2) Structure, Philosophy & Tips
In the previous article, I shared about how we worked on re-establishing trust in our career pathways. This was the result of a multi-month collaborative effort and iterations. This new post shares some insights and tips on how we structured them, in case you’re about to embark on this journey.
Going back to the ‘Why’ of career pathways
As explained in the previous blog post, the first thing we did was to clarify the objectives behind the pathways. We tried to really think of career pathways as a solution to a need, not as a product. I think it’s essential to keep track of those, since it’s easy to drift from the initial vision on a multi-month project. So we set it straight on paper, and referred to it.
After deliberation, we settled on two main objectives for our pathways: Personal Growth and Leveling.
Here are a few thoughts on the north stars:
Personal Growth is often overlooked — Career pathways are a great framework to help employees, and their managers, identify what their next role can look like, and what they need to do to get there. Before being an evaluation mechanism, the purpose behind DGF was to help people see beyond their current role. Note that this is a necessary, but not sufficient, condition. You can find in the next article how we built a Senior IC track beyond the pathways.
To do effective Leveling & Recognition at a certain scale, you need a strong structure. Pathways are a way to give this structure. There are a few reasons for that.
- One of our key values is meritocracy. We want to make sure that Doctolibers who bring the same value get rewarded the same, financially but also in terms of responsibilities. When Doctolib had less than 50 Engineers, we could somewhat keep that consistency as expectations would align through osmosis. Everybody knows each other, you can easily compare people and get to an acceptable outcome. But we started seeing some cracks. With 200+ Engineers, you do not know everybody, the type of work is somewhat different, the management team is much larger which means less consistency in their evaluation. At that scale, the only way to ensure we keep the same standards was to have a common framework that we can refer to.
- This structure also helps us clarify our expectations to Doctolibers. It’s important for us to ensure any member of the company knows what success looks like for them. The worst scenario is to have misunderstandings of what is expected of our Doctolibers.
What we discovered was that there are many other perks with such a system. We use them for other use-cases, such as understanding organizational health (segmenting our org-wide feedback by persona), clarifying the expectations in our interview process to ensure we don’t have blind spots, and other miscellaneous topics.
Lessons learned from our earlier career pathways
Throughout the various retrospectives we had with DGF 1.0, we learned a lot of lessons about what makes good or bad pathways. Here is a list of a few items which I think are interesting to keep in mind to make it successful:
- Give a compass. Our previous iteration wanted to recognize a very large diversity of skills. While great on paper, we realized that this can be quite overwhelming for people experiencing the pathway, especially for more junior profiles. We saw people adopt unnatural behavior, looking to develop skills in the wrong order, and managers uncertain on how to prioritize room for improvement. So, more than a list of expectations, I think it’s important to ensure that you provide a guide on how to navigate those pathways. For instance, explaining that as a junior developer, your first area of focus should be to find technical autonomy rather than expand your influence. This guide is also useful to managers to engage in the process.
- Train your Managers. Career pathways are not ‘tables of the law’. Since managers are accountable for the growth of their direct reports, they are your first line of defense. It’s essential to train them, to explain the philosophy behind it, to explain every detail behind the framework, to explain when they can override the framework. If you want it to work, you need to have them at the center. And so when you’re designing it, you need to ensure that you have their buy-in, that it looks like a framework they will be willing to use. If you fail at doing so, it will likely undermine the trust in the leveling system and make pathways less effective as a personal growth tool.
- Keep it simple As we went through this journey, we struggled converging to the perfect solution. The issue we found was that we’d be tempted to add more and more details, making it super hard for an outsider to understand how this thing works. I think a key aspect is to always acknowledge that people will never put as much thought into it as you, so you should always aim for simplicity over precision.
- Stress-test the model. This echoes the point above. You will spend a lot of time thinking about it, so everything will look very obvious to you. This does not mean you got everything right. The best way to get good career pathways is to confront them with a very large diversity of perspectives. This is why we created the steering committee — to ensure expectations were clear -but also realistic- to all team members no matter what role they have in the company. This added friction to the decision-making process, but ended up in a much simpler structure than initially planned.
Structure behind our current pathways
- We separated 1 path for Individual Contributors and 1 path for Management, and built bridges between them. One motivation was to recognize the ‘diversity’ of talents. We realized that many people would move to Management because it looked like the only way up. We wanted to change that, and started by highlighting that a move to management was a change of role (not a promotion), and made room for Senior IC Roles. We also introduced archetypes of Senior ICs, to recognize their various contribution to the organization. (Cf next article about ‘How we build roles for senior ICs’).
- We tried to give a clear ‘meaning’ to Engineering Levels, and kill any ambiguity between them. There is no perfect framework, but the first thing you want to ensure is that the Engineering Level is as fair as possible. Why? Because it is at the core of many things, including compensation bands. As such, you want to ensure that almost no employee feels out of place in their level. So, when designing the pathways, make sure that the ‘first order’ is correct. Every single employee should be able to understand what differentiates a Level 1 from a Level 2, etc. This will help them 1/ feel that their leveling is fair, 2/ understand what is expected of them and what it means to be successful, 3/ understand what they need to do to get to the next level. A quick tip can be to try to do an elevator pitch of each level, in 1–2 sentences, as a rule of thumb.
As you can see above, the general philosophy is that growth is shown across a few dimensions: moving from tasks to programs, moving from execution to leadership, moving from self to others. The question becomes: how do you characterize that? Just go to the next bullet point!
- We structured pathways around Core Attributes and Sub-Attributes.
Why Core Attributes? Rather than give 16 areas for development, we narrowed this to 3 dimensions of impact: Technical Expertise, Project Delivery and Influence… and a 4th special one: Enablers (cf below). This made it simpler to navigate.
Why Skills? They help you be more precise in the feedback and expectations. “Being Technical at Doctolib” is too vague. An Engineer can be exceptionally good at software design but struggle with other aspects of writing code. This is why we decided to provide a cardinal set of skills for each attribute, and set expectations for those at each level. For instance, Technical is composed of Software, Craft, Security and Operations. Those skills helps managers give precise and actionable feedback.
Why Enablers? Enablers play a specific role in the pathways. They are not taken into account in level-up discussion. Indeed, how would you calibrate somebody’s level of ‘grit’? However, they tend to be a useful tool to look at soft skills which are ‘enablers of performance’. This helps managers pinpoint not just technical improvements but also levels that will make engineers more effective.
How does this relate with Archetypes? As mentioned above, we wanted to differentiate various contributions starting with Level 4. Each archetype has a different combination of levels by attribute — some have higher Technical expectations, some have higher Influence expectations. This is a way to recognize the diversity of needs, and skills, that we have in the organization.
Structure behind our ‘level-up’ process
Pathways are not the end-goal, they are a tool for managers to achieve the two missions: Personal Growth and Leveling/Recognition. We have built, and keep building, many things around them. I will not go through all of them, but share how we revamped our level-up process with this new framework. With the new system, a ‘level-up’ is a change in Engineering level. This is therefore a less frequent, but more significant step in an Engineer’s career.
There is extensive research about biases in performance reviews and how they disproportionately affect underrepresented minorities. We built multiple things in place to fight this bias and establish a fair process. Especially:
* Managers (not their reports) are accountable for the end-to-end process for their direct report.
* Every application is supported by a written level-up case
* Cases are reviewed by a level-up committee.
Manager Accountability
What matters most to us is to reduce bias, and ensure we promote the right people. This is why we put responsibility on managers for the end-to-end process for their direct reports. They are in charge of identifying people who should be up for a level-up (even if those people did not ask for it). They are also in charge of filtering out those who ask for it but are not at the level yet (we do not want to build a culture where managers feel like their role is to have their reports level-up even when they are not ready for it).
And if managers don’t do this job properly, their own performance will be impacted.
Level-Up Case
To avoid some of the biases (focusing on only a few skills, introducing sophisms with words like ‘great’, ‘impactful’, listening to the loudest voice in the room), we decided to introduce a structured written case.
We provided multiple resources for managers in that process: templates, office hours, examples of a ‘good case’, bias training. In return, we were very clear that no level-up could be approved if the quality of the case was not there.
Level-Up Committees
Committees come with a trade-off: how to ensure consistency and quality, but make it scale and low-cost.
We decided early on that in order to scale, Domains would run their own committees for levels up to 3. For applications to Staff or above, we would have a centralized committee.
Decentralizing the level-up process can introduce a whole set of biases, which is why we added safeguard mechanisms. The main one we added was to have an ‘Outsider Director’ which serves as a Bias champion. With specific training on biases, they participate in a committee of another domain. Their job is not to assess the performance of individuals, but rather be the gatekeeper of the quality of the process. They flag potential biases, challenge managers and the committee members. This was a low-cost way of keeping some level of quality and consistency.
So, what next?
With all of this in mind, we tried to build a scalable structure which helps build a fair performance system. There are still improvements to make but the process is quite well perceived. We’re now actively investing in the second part of the mission: personal growth.
Next article will focus on the first battle we wanted to fight: build a strong Expert / IC path. This is a critical piece to making Doctolib successful, and a well-known challenge throughout the industry.
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.
