DEV Community

Lisa van Gelder
Lisa van Gelder

Posted on

How to implement an engineering ladder at your organization

Why introduce an engineering ladder?

A common complaint from engineers is that there isn’t a clear path for career progression at their company, and reasons for promotion (or being denied promotion) aren’t transparent. Sometimes roles aren’t well defined - what is expected of a team lead? What does ‘senior’ mean at your company? Sometimes the skills needed for a role or a level aren’t clear. Sometimes the different paths to progression aren’t clear - Is management the only way to get promoted or can individual contributors stay technical all the way up? Are those tracks equivalent?

An engineering ladder makes career progression much clearer, makes the promotion process transparent, as well as providing guidelines to engineers at all levels on areas they should focus on growing their skills. It can help with retention as engineers see clearly how they can progress at your company.

I also use the engineering ladder to define what skills to look for in the the recruitment process, and to decide what level candidates should be if we make an offer. It’s really useful for setting salaries when making offers, particularly in conjunction with salary bands. It’s typical for me to explain to an engineer that we’ll be making an offer in the Mid-level range because they didn’t demonstrate specific skills we expect of our seniors, and that if we hired them their manager would work with them to build a plan to work on those skills.

Where do I start?

Great! So now you’re convinced, you’ve reviewed Rent the Runway’s engineering ladder & you know you want to implement an engineering ladder at your company. What’s next? If you just tell your engineers you have defined a ladder and it now applies to them, you may find they revolt!

As VP of Engineering I’ve introduced an engineering ladder at two companies, Stride Consulting and Bauer Xcel. Here are the seven steps I’ve gone through to ensure it has been successfully adopted.

1.Communicate the why

You want your team to feel the ladder is for them. If your company has never had an engineering ladder, you need to be very clear to your team on why you think now is the right time to introduce one and what problems you think it will solve. Explain how they will benefit!

2. Get your team to define the levels themselves

You want your team to feel the ladder is for them rather than imposed on them - the best way to do that is to get your teams to define it themselves. I start by taking Rent the Runway’s engineering ladder and adapting it to the organization. Then I share it with the entire engineering team, along with some other example ladders (Kickstarter, Meetup Intent Media etc) and make the ladder editable by the whole company. Everyone gets the chance to add comments and define levels - including their own level - before the ladder comes into effect.

At Stride I had a series of meetings with the seniors where we went through each level skill by skill & agreed on definitions. At Bauer Xcel I put stories into the sprint for every team to make sure people had time marked out when they could review the ladder & comment. Then we created a slack channel for people to discuss wording they disagreed on & come to a consensus.

3. Communicate the how - how will it be implemented?

  • What happens if people aren’t acting at their current level? Do they get demoted? Is there a grace period?
  • What happens if a role people are doing is redefined? What happens if they feel they can no longer do that role?
  • What happens if people are acting at the next level up? Do they get promoted? how much of the next level do people have to do before they get promoted?
  • How is salary impacted?
  • How will this tie into the performance review/promotion process?

You’ll want to think through all the implications before introducing the ladder to your team. At Bauer Xcel we sent out an anonymous survey asking about team preferences for how to handle level-setting.

4. - Try it out!

Use your new engineering ladder in the performance review process and give folks the chance to discuss where they are on the ladder. I wouldn’t use it for a formal performance review before people have had time to kick the tires a little, so I’d suggest doing a trial run on volunteers before using it for real.

How long does this take? In my experience it takes at least a quarter to roll out an engineering ladder. It takes time to go through the initial comments & create the levels and then if you do a trial run as part of the standard performance review process, you may have to wait until the next performance review starts (at Stride they were every 6 months) That’s fine, it gives your engineers more time to get used to the idea. Hopefully your volunteers are enthusiastic about how much the ladder helped them so others are excited to use it next time!

5. Review

Get feedback from your volunteers - were some areas unclear? Were some skills missing from different roles? Give people a chance to adapt the ladder, based on the review they just did. Open up to a final review round from the rest of your engineers too.

6. Use for real.

Build the engineering ladder into the performance review process. After getting feedback engineers discuss where they are on the ladder with their manager and what they need to work on to get to the next level.

7. Make it a living, breathing document.

Skills & roles are constantly changing & the ladder needs to adapt with them. I allow the ladder to be edited by the whole company before every performance review cycle, lock it during the cycle, and then allow editing again afterwards.


I’ve been really happy with how well introducing an engineering ladder worked at both companies. When I introduced ‘maker’ and ‘manager’ tracks at Bauer Xcel, people from the ‘manager’ side told me that after reviewing the paths for progression on the engineering ladder they realised they were on the wrong track and wanted to switch, which is great as they got a much greater clarity for where they wanted to go in their careers. It brought a lot of clarity to what senior titles meant and who should have them, as well as defining a promotion process and recruitment process that ensured we looked for the skills we needed at each level.

The downside - if your company hasn’t done a good job of defining roles & titles consistently and you want to use the engineering ladder to level set, that is incredibly stressful for your organization. Morale took a big hit at Bauer Xcel while we worked through the implications and I had a lot of hard conversations with people who knew their title was at risk. It takes a while to implement a ladder and that is a long time to leave people in a state of uncertainty about their title and potentially their salary. You risk losing people if you aren’t careful.

In conclusion - an engineering ladder is a really useful tool, but also a big change for your organization, and as with all big changes be careful about how you introduce it.

Top comments (1)

bgadrian profile image
Adrian B.G.

I do not even know where to start and end the hate I have on these ladders. It is a true artifact of bad corporations. Sounds great on papers but how companies implement it leads to nightmares and politics.

The source problem is not in the company, but in our industry. There is no standard way to measure a person seniority, knowledge level and impact on a team and product, so each company tries arbitrary rules.

Reviews - in a wonderful world there would not be bad managers, grudges, bias and nepotism, but they are. This also leads to internal politics and all its ugly hydra heads. The best (bad) examples you can read are in the Amazon employees reviews on GlassDoor.

Seniority in company and/or technology - I agree that they must play a role, loyalty and experience are good things, usually. But ... every now and then (more often in my experience, but maybe I'm biased), a few things happen:

  • you are not promoted because you do not have X years in technology/company. Even if you are better than others at your job, or have more extensive knowledge. It happened to me in a hiring process actually.

  • developers that are actually harming the products are seen as heroes, Jeff Bonforte explain this perfectly and calls them "firefighters":

Unfortunately I do not have a better solution, except for a flat, distributed company where everything is public, including reviews and compensations. I know at least one company that does it, and I agree that most people will not agree with this technique, but as long as these arbitrary reasons that affect the compensation are secret, bad things will happen and good people will suffer.