Why I now like engineering career ladders

When I last wrote about job titles I came to the conclusion that I didn’t really like the concept of an engineering career ladder. I couldn’t help shake the nagging feeling that I was wrong though, as lots of smart companieshave them, and when lots of people who are smarter than me agree on something it’s usually a sign I’m wrong. Usually 😉. This week’s post is therefore a bit of a pulling together of all the reasons you might want to have an engineering ladder in a company, and what a good one might look like. I’ll also consider some of the common pitfalls in such a system and how we might avoid them.

What’s an engineering ladder?

First off, let’s define exactly what I mean when I talk about engineering career ladders. At its core, a career ladder is a description of the progression of roles in a company, from least to most senior. In this context I am specifically talking about the technical engineering track that individual contributors (ICs) stay on. Many companies have a dual track system, where at a certain point the ladder splits in two, with managers->directors->VPs on one track, and engineers on the other.

The precise number of rungs on the ladder seems to be a function of how important regular progression is seen to be in a given company. Some ladders are content with single bands at Software Engineer (SWE), Senior SWE and Staff SWE, others provide two at each level. There also seems to be the perception that bigger companies need more ladder levels than smaller ones, but I’m not really sure on why that is. Perhaps it’s because levels tend to be tied to pay progression in those kinds of company, so a constant sense of progression tends to matter more.

Why have one?

I think that the answer to this question is to be found in few different psychological concepts. The first is everyone’s favourite hierarchy of needs, which I covered in last week’s post on transactionality in remote work. The problem that we are attempting to solve is, I think, how to help people with the top of Maslow’s pyramid, self actualisation. When we, as a business, do that, we not only get great work out of the people we serve, but they’re also far more likely to stick around. This means that we are designing this thing so that it maximises intrinsic motivation, not as a series of hoops to jump through in order to get paid more (aka extrinsic motivation).

The question then becomes how a career ladder does this. This is worth understanding, since when we are designing our ladder we can then make sure we’re doing so in a way that support intrinsic motivation and doesn’t accidentally stray into purely extrinsic motivators like status and money. The most compelling theory of intrinsic motivation that I’ve come across is in Daniel Pink’s Drive. At a high level, he suggests that there are three main pillars to motivation, and like legs on a stool all 3 need to be present for it to function.

The first, purpose, is hopefully solved for already by your company’s wider vision and by the way you use tools like OKRs to create alignment with that vision. The second, autonomy, is also going to be solved outside of your career ladder by carefully selecting and coaching your leadership team so that micromanagement is avoided. When done right, you’re seeking to engage people, not merely achieve compliance with a stated aim.

It’s the final pillar, mastery, that we are addressing with a career ladder, it’s an opinionated view of what constitutes a roadmap to mastery in a profession. It has value because it sets down guideposts along the way that people can work towards. This is really valuable for people at all stages of their careers as whilst they may have a rough idea of their end goal, they probably have no idea how to get there. A career ladder helps institutionalise the knowledge of paths previously trodden, and therefore helps start to create that sense of developing mastery that people need to feel like they are growing their careers.

There is, naturally, a lot more to developing a sense of growing mastery than a simple career ladder (time spent in a flow state for example), but that’s beyond the scope of what I’m writing about today. The point is that having a career ladder plays an important role in building this way of working into your company.

There are, of course, a bunch of other reasons why you might want to have a career ladder, such as:

• It’s hard to hire people without one, as ‘Senior’ or ‘Principal’ software engineers don’t want to make a perceived step backwards into a generic software engineering role. Given the way the world works, it might harm their future earnings to do so. Plus you can bribe people with titles. Yay.
• Standardising compensation, or setting compensation bands. Which is fine as long as everyone works in the same geographical area.
• Helping to eliminate bias in discussions around seniority, compensation etc. by making the process more objective.

As you may have detected, I’m sceptical about these secondary reasons to have a ladder. I think that by including them in your thinking (with the possible exception of the third one) you end up diluting the primary thing that you’re trying to achieve - a roadmap to mastery.

Why don’t people like them?

I’ll keep this section brief, as I think I already covered it pretty well in my previous article on titles. It mostly seems to boil down to cultural concerns around the effect that job titles will have on a company (that they create an internal hierarchy), and that they create a scarcity mindset and needless internal competition. People also worry about title inflation (see my previous comment about bribing people with job titles...), and even get people to focus on the wrong thing, especially in a start up where people having multiple ‘hats’ is quite common.

These are clearly all valid worries, and I would imagine that we’ve all seen examples of all these things in companies where career ladders have been used for evil. Still, I don’t think that this takes away from all the good reasons why you need to have one, it just means that we have to be really careful when designing one, and even more careful in how we implement them.

What does a good one look like?

So, having said all that, how would I go about designing one of these things? As it happens I have recently done just that, so instead of hypotheticals I can be a little more concrete. The first step for me was to write down exactly what problem the ladder is solving, and, just as importantly, the problems it’s not solving.

The three problems I settled on were:

• Preventing the perception that the only way to grow your career is through moving into management.
• To give people a framework in which to develop their careers, and in which to give and receive feedback.
• To give people an externally marketable job title. LinkedIn is a fact of life these days, so this really matters to people.

and the problems that I specifically called out as not being solved were:

• Coming up with a watertight definition of each role
• Creating a scoring criteria for performance assessments
• Defining standardised salary bands
• Creating some kind of internal pecking order so that people could beat each other over the head with their amazing job titles

The company I currently work for is a small one, and there doesn’t seem to be a huge desire for very granular progression, so I decided to go with just four levels on our ladder for now. Software Engineer has two levels, just to demarcate the division between an entry level engineer and a more experienced one who hasn’t made the jump to Senior yet. Beyond SWE are simply Senior and Staff engineer levels. Each of the levels are defined using the same characteristics as the Rent the Runway ladder (mostly because I’m a big old nerd and liked the D&D aspect...): technical skill; getting stuff done, impact; communication and leadership.

Over time I can see there potentially being a need to split out the senior and staff levels into two levels each, and to define a proper management track (there aren’t enough people on it to bother right now, but that’s another post), but for right now it seems like a good fit. Actually, I think that’s actually a really important thing to note - like any other process the ladder needs to change and grow with your company, and it’s probably something that someone in the People Operations / HR team should worry about quite regularly.

Conclusion

So there we are, it might have taken a couple of months but I’ve totally changed my mind on the value that ladders can bring to a company, even when it’s only 100 people. I think that having one not only helps unlock potential, but it’s also a key document to arm your managers with so that they can have the meaningful career discussions that everyone claims they want. Time will tell whether the ladder that I’ve come up with will stick or not, so look forward to the inevitable ‘lessons from my botched engineering ladder launch’ post in a few months!