Doctolib Engineering Pathways — (Part 1) The ‘Making-Of’
This blog post is the first of a series of 3 about Career Pathways. The objective is to share a story of change at Doctolib, and how we tried to establish a trusted career growth framework in Engineering that would work at a scale of 200+ Engineers.
The articles are as follow:
Motivation
The story I want to share with this post is one of organizational change through the lens of a major project — Career Pathways — which went through several challenges, and the learnings I took away from it. This initiative taught me a few lessons about the increasing need to be proactive to establish a two-way communication with the rest of the organization as your company matures.
Career pathways are an exercise that most companies go through when they reach a certain scale. There are as many career path structures as there are companies, which tends to highlight how complex the task is. At Doctolib, we went through a series of iterations, some of which did not go exactly as planned, and learned a lot about the ‘what’ but also the ‘how’ to come up with a good solution.
The Story
Where we were
Since the start of Doctolib, we’ve always wanted to recognize the diversity of talent we had, as a ‘team of entrepreneurs’. This had moved us in early 2020 to evolve our pathway into something that would reflect this diversity of profiles. We were greatly inspired by?Medium’s Engineering Growth Framework, and decided to replicate the model and call it the Doctolib Growth Framework (DGF).
The DGF, in a nutshell:
What we loved about it was the flexibility and the recognition that Engineers could bring beyond technical expertise. We also liked the continuous progression aspect — while most pathways tend to keep you at a certain level for a few years, you could level-up on a skill every six months. Moreover, another company had already done it, which made the rollout easier. We were extremely excited to launch it, with high hopes and confidence that it would cover most of our needs.
The reality was slightly more complex.
As we went through the first round of level-ups, we received some red flags: team members started to complain about the huge operational load that was put on them, people were adopting weird behaviors like rummaging for points, managers were completely disengaged in the process, and new joiners saw it as an insanely unfair process as they had to start from scratch to prove their value. At some point, DGF memes started popping up in our Slack channels.
That’s when we decided to ring the alarm, 6 months after rollout.
1. Assessing the situation
The first thing we realized was that despite hearing some of the noise, we definitely had blind spots and an unclear assessment of the situation. We could tell there were symptoms, but diagnosing the root cause was more arduous. We had not clarified whether managers could score points on our ‘Fullstack’ track. Site Reliability Engineers had no track of their own. People would gather lists of 50 pull requests to demonstrate they were at the right level. What is more, we discovered these issues quite late in the process and we had to ensure this would not happen again.
So, the first thing we did was to take a step back and ask the organization what was wrong.
The outcome of the survey was a NPS of -30, and a long list of issues to fix. More importantly, we realized that we had lost the trust of the organization (when asked ‘do you think action will be taken as a result of this survey’, less than 50% answered ‘yes’). We knew we would not have many more opportunities to fail.
2. Going back to the why
As we got through the retrospective, I was surprised to see how many people questioned the existence of career pathways as a whole. This was new to me as I had always been exposed to that type of model in my prior experience. So I started wondering — what if they are right? Why would we inflict that type of organizational process if everybody hates it?
Fortunately, this helped us (Engineering leadership group) challenge ourselves and refine the North Star. We ended up with a ‘why’ in two pillars: Personal Growth, and Leveling. Those would become the key structure to what we do next. I will dive into why those pillars are important in my next article.
So, what did we do next? It was time to regain trust!
3. Re-establishing communication with teams
Given the situation, we realized that we had to get the trust back. We presented the outcomes of the retrospective, and set expectations for the future. Here were our core messages:
This required a certain amount of work on our side. I sometimes wondered whether it was necessary to go through that, but got strong signals that gaining the trust back was necessary, and acknowledging our mistakes publicly was an effective step towards that direction.
领英推荐
4. Looking ahead — establishing a two-way communication
As mentioned earlier, drafting career pathways is no simple task. You may wonder why we did not take pathways from another company and replicate them? The truth is that companies have different stacks, cultures, which makes expectations slightly different from one to the other. So, rather than fully copy one, we got a lot of inspiration from what already existed and crafted our own version.
We organized as a small and nimble 5-people task force, with clearly defined roles and responsibilities. Some would ensure we delivered on the ‘Personal Growth’ North Star, others on how we would organize our level-up process. And every two weeks, we would challenge ourselves with the steering committee.
Our secret weapon: setting up a representative ‘Review’ Committee
Learning from our past experience, we decided to create a?representative review committee?which would challenge the work moving forward. The value of diversity is that it introduces the necessary friction that will make the ultimate decision better. So we decided to gather a 15-people panel with representation from all roles, domains, levels of experience, geographies, tenures at the company, gender, etc. What mattered was that every individual could look at it through their own lens, and capture imperfections that we were far from anticipating.
They had only one job: look at everything we build with their own critical lens. Does it look fair? Is it understandable? Does it work from your own perspective? Every decision we made was first challenged by the steering committee. The amount of insights that we gathered from this is truly invaluable. We realized that our proposed V2 system was too complex, some expectations were unrealistic, and did not work well with specific skill sets (e.g. people working outside of the monolith felt completely excluded). We took all of the input into account to build the most inclusive and coherent framework possible.
After 3 months of work, we landed on a completely new pathway which we presented to team members. We did not change our North Star one inch, but we did what we could to keep the fundamentals right and deliver on that vision. This resulted in an increase in Employee NPS on ‘Career Growth’ of 40 points in 6 months.
Want to know what those pathways look like? Check out the next article!
Lessons Learned, and some tips for the future
This journey is not just about Doctolib, and not just about Career Pathways. I extracted many of those learnings on all projects I’m currently working on in the Tech Organization. This experience informed how we organized ourselves to draft our new?Remote Policy.
If there was only 1 advice I’d give to people making organizational change in a fast-growing startup:
Make sure you build and maintain a strong?two-ways communication with the organization.
Involve the entire organization in the build-up of those processes
Very often, we are reluctant to involve too many people for such a complicated topic, for fear of wasting a lot of time and slowing down delivery. But my take-away is that this upfront investment can drive to a much better outcome and time savings. No matter your level of intuition or experience, it will be impossible to anticipate every issue or edge case.
There are ways to keep that feedback loop with a low effort. A simple survey can do the job. But what I found most revealing was the set-up of the ‘review committee’ mentioned above. Here are some tweaks on how to do one well.
Communicate openly, even if you’re not done yet
Be proactive to build and maintain this two-way communication!
Those principles may seem completely common sense. The reality is that they are easy to apply in a small company. Small companies tend to establish trust through proximity — “they know me, they trust me. If they have a problem, they can just reach out”.
As the company grows, you will gradually lose the proximity — the communication and decision-making forums tend to become less effective.?You have to make a proactive effort to maintain trust and self-awareness. And this is the tricky thing: because the growth is gradual, you may not realize you have lost this communication, until you experience it the hard way.
So, the only advice I can give you is to not take this two-way communication for granted and challenge yourself on it.
Hopefully, this story will resonate with some of you, or give simple hints on how to build successful large-scale programs. Career Pathways are just one example, but the learnings can extend to any type of project requiring rolling out to a large population.
Interested in the topic? Check out the next article: (soon)?How we structured our Engineering Pathways.
---------------------------------------------------------------------------------------------
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.
Freelancer AI Solutions Architect and ML Engineer
2 年Super interesting Thibault ! Loved the part 2. Will steal some ideas