How to build a career ladder for Engineering teams
A step by step practical guide on how to design a career ladder that will fit your engineering team
Hello,
In the previous post we discussed the importance of having a good career ladder in place for your engineering team. As it's often the case, that's easier said than done.
Once the decision is taken to have a career ladder, many teams don't really know how to design one.
In this article I'll guide you through the process I use.
Step 1: Define how many levels and titles you will need
Before you start defining expectations for each level, you will have to define the actual levels you want to use at at your company. Here is how I suggest you do this:
Start with whatever levels your company have already in place for the generic career ladder. If your company already has different levels for ICs and Managers, use that as the starting point for your work. Leverage the work of your HR department.
Define which levels you intend to have in your organisation. Do not reinvent the wheel. Go for a dual career track. Ideally the highest level on the IC track should equate to the second level on the managers track.
For a small team you might want to keep the levels to a minimum, something like this:
Dual track ladder for a relatively small team For a bigger team, especially if you're planning to grow it substantially in the next 12-18 months, you might want to factor in more levels to account for growth. In this case you might settle for something like this:
Dual track ladder for a bigger team Define where your branching point for the manager track is going to be. A very common pattern is to branch after the Senior Software Engineer level. You generally want managers to have reached that level to be able to support their team effectively.
Step 2: Collect input from various members of your team
Once you have landed the number or levels you want to have, or as you make progress on that work, you will want to have one or two sessions with members of your team to collect their input.
Here is how I usually do it:
Set aside a couple of hours for a workshop. Invite prominent members of your team: engineering managers, senior engineers and / or people that have experience with this process, and care about it.
This is an expansive step, you will want to bring in as many different voices as possible, but keep it manageable. Try to stick to no more than 7-9 people. If you need more due to the size of your organisation, consider running multiple sessions.
Break down the workshop in 2 parts:
Brainstorm: Anyone can write in a physical / virtual post-it one skill, capability, competence, trait that they believe should be covered in the ladder. I use Miro for that, but any equivalent software will do. The format doesn't matter.
Make sure people don't censor themselves, or each-others. Make sure people consider both hard skills and soft skills. There is no stupid input at this stage. Be flexible with the format.
At the end of this session you will typically end up with a ton of post-its, usually grouped by the author. Have each author go through their tickets and explain why they believe the item is important.Group similar items: The team starts grouping post-its around topics or themes in a self-organised way. You can help guide the conversation, but make sure you don't do all the work. Parallel processing at this stage is very useful.
You will naturally see some common categories emerge, such as: Coding skills, Testing, Automation, Communication, Stakeholder Management, etc. At the end of the session you will end up with a board similar to the one below.
Miro board of a real session I did with a team. This is for illustrative purpose, yours will be different. Keep in mind this one is for a relatively small team. Yours might be very different. What matters is that you start surfacing key areas of competences that you will want to include in your ladder.
Step 3: Define competency areas for the ladder
A few days later, get back to the data you have collected during the workshop. This will help you come back to it with a fresh perspective. You might discover new ways to group skills, areas that have different levels of importance and that might be grouped together, or even entirely missing pieces.
Give yourself the liberty to edit the results as you please. Keep in mind you don't have to go through collective processes for every decision. After all, I think making decisions is part of your job description.
If it isn't, this work is your best opportunity at rectifying it!
Once you feel comfortable with the results, it's time for the hardest decisions of all: you need to decide which tool you're going to use to define and share the career ladder with the rest of the organisation!
I do recommend going with the best intersection of what are commonly used tools internally at your company, and tools that you feel comfortable with. I personally tend to use Google Spreadsheet as I like the table structure, but you could use Notion, Confluence, Figma, Miro, a purpose built blockchain protocol…
I genuinely don't care. My only recommendation is: don't over-engineer. So, maybe drop that blockchain idea right away.
Once you've finally made the call on the tool, use it to prepare a table that will include the following:
On the coluns you'll list the different levels of your career ladder, from the lowest to the highest
On the rows you'll list the different competence areas and potential sub-areas that you have identified with the work done so far.
You will end up with something like this:
Once you're comfortable with the result, I recommend you share it with the team. Keep this part time-boxed by communicating an explicit due date for them to provide input. Some people will do, some won't. What you want at this stage is to make sure you didn't miss anything significant from the initial workshop.
Making changes to the structure after this stage will become increasing expensive as you add more details to the ladder.
Step 4: Fill in the blanks for the first level
This is often the hardest part. There is no right or wrong content here. It's your opportunity to define clear expectations for members of your team, and shape the overall culture of the engineering team by defining what is rewarded and valued at your company.
I typically recommend to use a mix of descriptive and prescriptive approach. On the descriptive side, you will want to reflect in the competences a big chunk of what is already covered in the organisation. On the prescriptive side, you will want to cover gaps you have identified in terms of skills, abilities or behaviours.
You don't necessarily need to start from Level 1. My recommendation is to start from the level where you think most of the people in your team are. For most teams that might be Level 2 or Level 3.
The reason is that this will allow you to test the ladder against a broad set of people, and you will be less likely to be biased by few individuals.
Spend some time to fill the entire column for this level. Do a few iterations on your own by alternating writing, and editing. It's OK to take one or two weeks to get this done.
Aim to avoid generic statements around knowledge such as “Knowledge of Python”, or “Good knowledge of Security topic” as they are ambiguous and will be very difficult to evaluate.
Avoid being both too narrow or too specific: don't over-index on specific technologies, as these are transient in nature. Do emphasise core technologies though. If your stack is entirely Javascript based, make sure specific requirements in this space are included.
I find it useful to describe abilities rather than generic knowledge. I encourage you to use statements such as the following:
Is able to turn an ambiguous problem statement into a detailed architectural plan
Is able to break down complex projects into small incremental deliveries
Is consistently driving technical decisions within the broader engineering team
Performs vendor evaluations that encompass both technical and financial aspects
Is able to deliver software with little guidance and low defect rate
Writes test automation and infrastructure automation autonomously
Introduces new standards through a process that ensures contribution from a broad representation of the engineering team
Is regularly sitting in meetings with Clients and is able to address their questions with comprehensive and accurate answers
Once the definition for this first level is complete, share it with your team for a full round of feedback.
Incorporate the feedback that you think makes sense - remember, you decide - and then declare the first level finalised.
Once you've gotten to this stage, 70-80% of the most difficult work is done. What follows is typically a downhill ride, as you will be building on the work done so far.
Steps 5-N: Rinse and Repeat
What I recommend doing next is the following:
Pick another 1 or 2 levels, typically the levels above and below the one you've just completed.
Repeat the same process by filling in all the relevant columns for these levels. Only focus on the delta: every level is supposed to include all the competencies from the level below. This will save you a lot of copy-paste and editing in case you change wordings on one of the lower levels.
Spend more time with the team on the levels that are likely to be most controversial.
In one company I worked with that happened to be the Senior Software Engineer level. Aligning all the EMs on what are the key differentiators between SWE and Senior SWE was not trivial. That took a lot of discussions, and I was glad we did it as we ended up creating a very strong alignment on what it meant to be a Senior SWE at that company.
At another company I had a very similar discussion with Staff Software Engineer. As usual, YMMV.Once you are done with the Individual Contributors (IC) levels, move over to the manager roles. Here I recommend you to start with the first level for managers, typically the Engineering Manager role. Then move up the ladder.
I recommend starting this work with a similar workshop used to surface the competency areas for ICs. You will want to involve key people in your leadership ranks: EMs, Directors, etc.What about your own level? In theory it should not be your responsibility to define your level. In practice you might be in a situation where you report to the CEO, who lacks the expertise to provide such a fine grained definition for your role.
What I found working well in this case is to write the first draft for your own level, then discuss it with your manager (the CEO), incorporate their feedback and finalise the definition.
This is also a great opportunity to surface misunderstanding or misalignments between the two of youIt's likely that you will have multiple specialists in your team: SREs, Security Engineers, SDETs, etc. You should go through the same process for each area. These iterations will be much faster as they'll build on the generic ladder you've already created.
It fact, most of the soft skills and some of the hard skills will turn out to be the same as the ones you've already identified.
You can even consider delegating this work to other trusted members of your team.
Conclusions
This article provides you with a clear set of steps and instructions to follow in order to design a career ladder that is tailored to the needs of your team and your organisation.
Though I recommend you to do the work from scratch and avoid cargo culting whatever Big Tech is doing, I also know it can be daunting to start with a blank slate.
For that purpose, I have put together this template that you can use to kickstart the process. Starting with some structure in place can save you a lot of time and hesitation, while still giving you ample room for adjusting the template to your own needs.
While you can reuse that template as you want, I will ask you to do two things if you do so.
Please leave a comment in this post to let me know you found the template useful
Share this newsletter article with your team, inviting them to subscribe.
One More Thing…
I have done this exercise a few times with teams of different sizes.
If you believe you would benefit from some external help to go through this process with your team, please contact me and we can discuss arrangements.
I would be delighted to help you deliver your own career ladder!