How We Built an Engineering Job Ladder from the Ground Up
By: Xing Chen
When I joined Thumbtack four years ago, the team was 25 engineers, and was completely flat. No managers, job levels or titles — everyone was a “Software Engineer”. This worked well for a small startup, but we always knew it had to evolve. Over the next three years, as we scaled to nearly 150 engineers, one of our perennial debates centered around when to introduce a job ladder with levels.
There were strong reasons on both sides of the debate. We heard from some engineers that they wanted a structured career ladder, which would bring transparency and a clear roadmap to their growth. But other engineers argued that they didn’t come to a startup to climb a job ladder. They were concerned that ladders and promo systems could take focus away from creating a great product and company.
Last summer, as we surpassed 100 engineers and kept growing , we made the call that it was time to have a job ladder and levels. But we wanted to make sure that we built something from the ground up that worked well for our team, for Thumbtack engineering specifically. Our team has always valued certain things like ownership, collaboration, and impact. It was important to us that both the process of developing the ladder and the outcome reflected our values.
Here is a summary of Version 1.0 of the Eng Career Growth Framework at Thumbtack. For more on how we developed and rolled it out to the team, read on…
A transparent development process
We started by nominating an engineering career growth committee to build the job ladder. Our committee formed with four engineers and one manager (myself) to write the ladder. It was important to have the committee be representative of the overall eng team — more engineers than managers, with a diverse mix of backgrounds, product teams, platforms (native mobile, web FE, backend, etc), and previous experiences (eg. big company vs. startup). The committee was tasked with writing the criteria for each job level, which would later be used by eng managers to assign levels to the team.
The career growth committee then began a highly transparent writing process. We reached out to peer companies to do research on how they had developed their ladders. The group then started writing a draft of our ladder as an open shared doc that gave comment access to anyone in the company. Notes were sent out every few weeks with updates, and we had a Slack channel for discussion. As we got to milestones in the ladder, we hosted brown bags with the entire team to discuss what we had so far, and heard feedback.
One of the challenges we immediately ran into was how to release early versions of the ladder without triggering premature conversations among the team against an unfinished job ladder. That had the potential to create confusion and frustration. One solution was to release “ flat” versions of the ladder initially — essentially a draft with level numbers removed. We wrote out a set of performance criteria structured under five pillars (technical, collaboration, leadership, citizenship, and impact), but did not specify any mapping from criteria to levels. With this, we were able to get feedback from folks on whether they felt the criteria were right, without worrying about people starting slotting discussions prematurely.
Debating team values
Getting feedback early turned out to be incredibly important for writing a career ladder that the engineering team believed in. Folks had strong opinions on the values that we were encoding into the career ladder as criteria. We discussed questions like: does leadership matter at all levels of engineering? We decided yes — our eng culture really values ownership of problems and proactively driving solutions, even for junior engineers. The concept of collaboration was also really important to us as a team. Collaboration starts with clear communication and a willingness to help others, but also encapsulates concepts around being a team player, and being able to compromise and help move decisions forward.
We also encoded pillars of criteria around technical expertise, impact, and finally citizenship. Citizenship is the concept of sharing responsibility for “sweeping the floors” and contributing to the engineering community. For example, tasks like cleaning up code that doesn’t have a clear owner, or contributing to shared libraries, or even just being willing to answer questions on Slack from someone on another team — all of that is important to our team working well.
One of the hardest concepts to balance was the objectivity of the ladder vs. the individuality it allowed in career growth. Criteria that are nebulous are simply not helpful to engineers for understanding how to grow. Vagueness in the ladder can also create too much subjectivity and potential for inconsistency in the promotion process. To optimize for objectivity, we could have made each criterion concrete and specific, and require that everyone must achieve that criteria to advance. For instance, imagine if we said that being able to design a clear service API was a requirement for technical expertise at L5. That creates a consistent bar to meet, but would ignore the fact that not everyone has interest (or opportunity) in building backend service APIs.
Ultimately, a job ladder cannot be a checklist of items to mark — it should be a higher level roadmap that describes different ways to grow. Everyone is different and should have the flexibility to grow in different ways. We decided to write top level criteria that were higher level and achievable in many ways. But to make it concrete, we added many examples under each criterion to illustrate the range of possibilities for achieving it.
Looking back, the biggest benefit of transparency was that it let us have an open discussion with the team on our values. We were able to say yes to a lot of the feedback from the team and incorporate it early on in the doc. This helped us write a better ladder that the team understood and bought into.
Rolling out the job ladder
As the writing committee converged on the final drafts of the ladder, we had to figure out how to roll it out to the team. This meant assigning levels for over a hundred engineers for the first time (previously, everyone was a “SWE” with no level or title). Needless to say, this was a daunting task. As we do with many projects at Thumbtack, we iterated our way towards the goal.
One of the major iterations we did was a test calibration. We asked engineering managers to use a late draft of the ladder to try assigning levels to their reports. The goal was to understand if the job ladder was usable as a tool for consistent leveling and promotion for the management team. We were particularly interested in things like whether levels were clearly differentiated, or whether we had under-specified growth paths for certain “archetypes” of engineers. For example , we discussed whether the ladder created sufficient clarity for product engineers, especially those working on client platforms like native mobile. We also talked about how engineers in tech lead roles should fit in vs. those in deep IC roles. This feedback went back to the writing committee and led to more revisions in the final ladder.
Another major step in the rollout process was to ask every engineer to fill out a self assessment against each of the ladder criteria. For instance, we asked folks to try to evaluate their level of technical expertise, collaboration, leadership, etc. This helped us in two ways. By forcing every engineer to read and evaluate against the ladder, it let us test the usability of the ladder as a roadmap to personal growth. The self evals also helped the management team understand how much alignment we had between the engineering team and manager evals. Finally, we did a calibration exercise among the eng management team to assign levels to the team using the ladder.
Ultimately, we were fortunate to have a high level of alignment in how engineers and managers read the job ladder. This meant we were able to have clear conversations with our team about career growth, which was critical for a successful rollout. We credit a lot of that to the transparent process we took. The feedback loops forced us to write the ladder in a way that was understandable and usable to both of our audiences: to individual engineers as a roadmap for growth, and for managers as a tool for consistent leveling and promo. That said, there are certainly still improvements to be made in our ladder. For instance, we know we need more clarifying examples of growth paths in different platforms or roles (eg. being a mobile engineer, or a tech lead). That’s why this is only V1.0, and we will continue to evolve and improve it as we grow.
Originally published at https://engineering.thumbtack.com on July 31, 2019.
