TL;DR: One of the questions we hear a lot from engineers in our recruiting process is what kind of career path exists for technical specialists within Criteo. Their concern stems from the fact that they have already reached the top of the technical path in their current company and their only option for progressing is to become a manager. In Criteo R&D we have created separate career tracks, along with a levelling process to address this issue.
Given a sufficiently large team – such as our R&D team – take a few moments to think about how you can answer the following questions:
- How do you recognize the competencies and abilities of each team member?
- How do you decide whether one person is “more senior” than another?
- How do you reward team members fairly?
- What does “career development” mean?
- What does getting promoted mean, and how do you decide when to promote someone?
|It’s a vague reference to this kind of matrix||But we’re talking about this kind of matrix|
The columns of the matrix represent levels of seniority, increasing from left to right. The rows represent types of competencies that the person is expected to have for each level. A similar approach is used by many other companies in the industry, such as Facebook, Google, Microsoft, and Amazon, to name just a few.
Note the emphasis on competencies. In some other industries, you may see levels defined based on job scope – e.g. “I manage people therefore I am more senior than someone who doesn’t”, or “I manage 15 people therefore I am more senior than that other guy who only manages 5”.
In a technology company such as Criteo, a leveling system based on job scopes doesn’t make any sense. Instead of incentivizing people to solve technical problems, a “job scope”-based system forces them to become managers to be more senior than individual contributors, and then to “grow their team” to increase their seniority as managers. This is counter-productive as it creates a glass ceiling for engineers who enjoy to write code and who would like to continue doing so instead of becoming managers. It also leads to a lot of politics since the main incentive for managers will be to grow their team, instead of focusing on their team’s impact on the business.
Our leveling matrix has 7 columns that determine how performant (or senior) you are. Levels 1 and 2 correspond to junior, fresh-out-of-school engineers and level 7 targets a truly exceptional and experienced engineer, whose impact is enormous both inside and outside the company.
The general distribution of levels in R&D looks (predictably) something like this:
We have quite a few juniors, a bunch of senior engineers, and less of the higher-leveled ones.
Engineering level 7 is just below the “Director” level. Larger companies (e.g. Microsoft or Google) introduce 1-2 individual contributor levels above level 7 – usually these are called “Distinguished Engineer” and “Fellow”.
The important thing about the engineering matrix is that you do not need to become a manager to increase your seniority at Criteo. If you like to code, we encourage you to keep on doing that, without worrying that you’ll never get a promotion if you don’t become a manager.
When it comes to performance, we evaluate a wide range of skills. For engineers, these include:
- The quality and complexity of the code you write. As a level 2 engineer, you’re expected to write well-structured and readable code. As a level 6 engineer, you’ll be developing the most difficult code across multiple products or services.
- Your focus on measuring and increasing quality. This is important since we don’t have dedicated “testers” in R&D. Our engineers are in charge of writing all the automated tests for their code.
- Your contribution to the development cycle. For instance, a level 6 engineer will work with other (typically less senior) engineers to help them identify and mitigate the risks in their code.
- Your technical skills. A senior engineer will produce complex designs spanning multiple projects or teams.
- How well you understand product and business needs and use them to drive the technology development.
- How well you work with other engineers on your team and with other teams.
- How involved you are in recruiting. This is a big thing for us since we’re hiring a lot.
- Your level of ownership, accountability, judgment, and initiative. For instance, we expect senior engineers to be role models in terms of judgement and initiative, and to enable other engineers to take initiative.
What we like about this
This structure has a few properties we have come to love:
- The promotion process is clear: if you match most of the required skills for the level n+1, you can apply for a promotion and get it. A “promotion” is a move to the next higher level in the same track. You’ll get recognition from your peers, higher expectations from your manager, and a better compensation package.
- When you get hired into the R&D team, we’re careful to place you at the right level depending on the competencies you’ve demonstrated in your past jobs and during the interview process. This allows us to reward you fairly compared to your peers and to have the right level of expectations when we review your performance, which happens twice a year.
As your seniority increases, promotions also become more demanding. Thus it’s fairly usual for a good junior engineer who started at level 2 to be promoted after 1-2 years, while a promotion from level 5 to 6 typically takes longer.
At Criteo R&D, we have different profiles of engineers. We have Juggling Jena, who can keep up with an impressive number of very different projects, and make sure that they go in the right direction, without surprises. We have Coding Charlie who is already a senior developer and keeps exceeding expectations. We have Wise Wendy, who is not the most senior person in the team, but excels at managing a strong, consistent, focused, and motivated team. We would like to offer challenging and rewarding career choices to each of them, in line with what they like doing and what they’re good at.
This is why we don’t actually have a single leveling matrix, but several ones, each corresponding to a different career track. Some of the career tracks we have include:
- ENG (Software Engineer): “I am Coding Charlie, I write code (and tests, and review code, and participate in design discussions, and give interviews, and give talks about technical subjects, and participate in conferences, etc.)”.
- EDL (Dev Lead): “I write code (and tests, and… see above), and I manage a small team”.
- EMG (Engineering Manager): “I am Wise Wendy, I manage a whole department inside R&D, several dev leads and a few dozen engineers”.
- EPM (Engineering Program Manager): “I am Juggling Jena, I coordinate many projects across R&D and Product teams”.
- RSC (Researcher): “I make sure we’ll still have cool new projects to ship next year. Oh, and did I mention I’m a top-notch expert in machine learning?”.
- OPS (Operations): “I keep the lights on in the datacenters and make sure the hardware and software are there for the code monkeys to mess with”.
These career tracks describe the different types of positions in R&D. They aim at being largely independent of seniority. This means that it is possible to have very senior employees (level 7) in all tracks. Obviously, some positions are not accessible to junior employees though (e.g. sorry, you can’t apply for an EDL, EMG, or EPM position if you’re a junior engineer who has no previous experience in coding and shipping products).
Juggling Jena, who’s a level 3 EPM, has an unfulfilled craving for writing code. One day she decides that she’d like to do this full-time and joins Coding Charlie on an exciting new project. She changes tracks from EPM to ENG, while keeping her level.
We’ve defined the levels on different tracks carefully so that they roughly correspond to the same level of seniority. Thus you usually keep the same level while moving from one track to another.
Some important things to note:
- Changing tracks is not a promotion: a move from ENG to EDL, for example, or from EDL to EPM is a lateral career-track move. It comes with a different set of expectations about your work, but no change in level and thus pay (thus sorry, you won’t get paid more simply by changing to a management position). Also, it would be possible for Coding Charlie to try and be a dev lead for a while, but if he feels he cannot have as much impact because he can’t be as focused on code, he will be allowed to go back to an ENG position, and it won’t be frowned upon. Basically, changing tracks is a fairly lightweight move that many people take advantage of (almost 20% of our R&D changed tracks in 2014!).
- No track is “shorter” than the others, they all go to the top. Our most performant employees are in the track they chose, where they excel, whether it’s writing complex code or leading teams effectively.
- This system gives everyone a clear, precise vision of what is expected of them, both in their current level and in preparation for a promotion.
Some skills are important across all career tracks (like teamwork for example) and some are more important in some tracks but not all (such as how well you can write code). It’s pretty important to us that everybody can find a track where they develop the skills they want.
It’s just a guideline
Although this system gives us a strong guideline when assessing the performance of engineers, it’s not at all set in stone forever.
In fact, we constantly adjust the details of what is considered good performance at a given level in a given track. The written definition is here to give us the coarse-grain version and to provide guidance to everyone, but the real, precise calibration happens every six months, during the performance review committees, where we both talk about individual performance and also fine-tune the details of exactly what it means to be a level 4 ENG, for example.
If you love coding but feel that in your current company the only way to level up is to become a manager, consider applying. Now you know you won’t have to make this choice if you worked at Criteo. And we are hiring! (check here)