Writing an engineering ladder

Every few months someone on the team asks, in some form, “what would it take for me to get to the next level?” For a long time my answer was a version of “do great work and I’ll notice”, which is both true and completely useless to the person asking. So this quarter we finally wrote an engineering ladder. Here’s what I learned doing it, because the writing taught me more than the document itself is probably worth.

Some background. Years ago I wrote a Programmer Competency Matrix, a big grid of skills (data structures, source control, defensive coding, and so on) with four levels each, from “can’t find the average of an array” up to the deep end. People still email me about it. It’s useful for seeing the shape of the territory, and completely unusable as a career ladder, which I say as the person who made it. Nobody is uniformly at one level across thirty-odd rows, and if you try to promote someone by averaging the grid you get absurd results, where a brilliant engineer who doesn’t care about build automation scores the same as a careful mediocre one.

So the first thing I did was accept that the matrix is a map, not a ruler. A ladder answers a different question. The matrix asks “how good are you at X?”; a ladder asks “what should the company expect from someone at this level, and what should it pay them?”

Levels and scope

We landed on five levels for individual contributors, which for a team our size was already one more than we strictly needed, but I wanted room above where our most senior person is now so that growth didn’t mean “become a manager”. That last point mattered more than I expected. The moment you have only a management track, your best engineers either leave or reluctantly become bad managers, and I’ve done both.

The thing that made the levels click was realizing they’re mostly about scope, not skill. Roughly:

• A junior owns a task. You give them a well-defined piece of work and they get it done, asking for help at the right times.
• The next level owns a feature. They can take something fuzzy, break it down, and deliver it without someone decomposing it for them.
• The one after owns a system or a service, including the parts that aren’t fun: the on-call, the migration, the thing that breaks at 3am.
• Above that, scope crosses team boundaries. They make other people better, and they’re trusted to make calls that affect more than their own work.
• The top IC level sets technical direction that the whole engineering org feels.

Skills grow alongside this, obviously, you can’t own a service without knowing how it fails, but when I tried to write the levels as skill checklists they were useless, and when I wrote them as “how big is the thing you can be handed and trusted with”, they suddenly described real people I could name.

The parts I got wrong first

My first draft was a grid. Of course it was, I’m the competency matrix guy. Five levels across the top, a dozen skill rows down the side, a sentence in every cell. It took a week and it was beautiful and when I showed it to two of the engineers they both did the same thing: scanned down their own column, found the one cell that didn’t match them, and got anxious about it. The grid invites you to find the box you’re failing, and it buries the actual message, which is about scope and trust, under a pile of detail.

So I threw out the grid and wrote each level as a few plain paragraphs: what work you own, how you work with others, what we’d point to as evidence. I kept a short list of concrete examples under each (“led the such-and-such migration”, “is the person three others go to about the payments code”) because the abstractions mean nothing without them. It’s shorter and less impressive-looking and much more usable.

The second thing I got wrong was thinking the document was the deliverable. It isn’t. The ladder is only worth anything if promotions actually track it, and that means I had to go back and sanity-check it against everyone currently on the team. That was uncomfortable, because it immediately surfaced two people who, by the ladder we’d just written, were being paid below their level. Which meant the ladder’s first real act was to cost the company money, as it should have, and if it hadn’t I’d have known the levels were set to flatter the budget rather than describe reality.

Compensation, and keeping it honest

I put a pay band on each level. Not exact numbers in the shared doc, but a band, so that “what would it take to get to the next level” has a money answer and not just a vibe. I went back and forth on whether to publish the bands and landed on: the levels and their descriptions are open to the whole team, the specific band numbers I share with each person for their own level and the one above. Fully open comp is a bigger cultural bet than I was ready to make this year, and keeping the bands entirely secret would just be me saying “trust me” in a nicer font.

The other honesty check is that levels can’t be a participation trophy for tenure. Being here three years doesn’t move you up a rung. Owning bigger things does. I wrote that explicitly, because the alternative, where everyone drifts upward by waiting, is how you end up with a team full of senior titles and no one who actually operates at that scope, and then your next hire reads the titles and has no idea what they mean.

Does it work?

Ask me in a year. What I can say after a month is that the one-on-ones are better. “What would get me to the next level?” now has an answer that points at specific work rather than at my mood, and twice already someone has pushed back with “but I think I already do that”, which is exactly the argument I want to be having, because it’s concrete and we can look at the evidence together.

If you’re writing one of these, my advice is: start from scope, not from a skills grid; write it in sentences a person can read about themselves without flinching; check it against your real team before you publish it and be ready for what that turns up; and put money on it or don’t bother. The grid I spent a week on is in the version history, where it belongs.