Levels and legible progression

My first full year as a manager-leaning IC at a startup ended in an appraisal that surprised the whole team. We had spent the year getting one kind of feedback (code contribution, the basics of management) and were graded in December against a template none of us had seen. The scores dipped, and the 1:1s afterwards were nothing like the conversations we had been preparing for.

The bad scores were the symptom; the loss was the year itself. We had spent twelve months unable to answer the two questions every engineer wants answered: what is expected of me, and what does the next step look like. When you cannot answer those, every appraisal is a verdict instead of a forecast.

First thing for a new EM: a ladder is for the engineer; not for HR, not for you. Every career needs a yardstick. Build it first, and the things you stress about (promotion process, calibration, "fairness", HR's annual ritual) become mechanical translation problems. Build backwards from "we need a promotion process," and you produce a worse ladder. You optimise for the appearance of fairness rather than the engineer's real question: am I growing.

I started one after that cycle. We sat down, role by role, and wrote a competency framework as a spreadsheet, with roles across the top and expectations down the side. The first version was deliberately simple. It still let an engineer open it and read what an SDE-1 was, what an SDE-2 was, what we expected at each rung. The conversation in 1:1s changed within a quarter.

Four things to get right when you write yours.

Anchor to the external market

Your SDE-2 should mean roughly what the market means by SDE-2. If your bar sits way below the market, you will surprise people the day they interview elsewhere. If it sits way above, nobody outside your company will value your titles, and your engineers will quietly resent that. Anchor to the outside world.

Build a continuous path

Look at your ladder from any rung and ask: can someone at this level see the next move? Random jumps, unreachable rungs, and "you'll know it when we see it" levels all do the same damage: they make growth feel like a lottery. If you cannot articulate what gets someone from rung N to rung N+1, that gap is your homework.

Buckets first, then competencies

A matrix has two layers. Buckets are the broad categories, things like Hustle or Technical Expertise. Inside each bucket sit a handful of competencies, the specific things you score an engineer on. Get the buckets right first. They are harder to change later, and they shape everything inside them. A small org can ship with one or two. Ours started with Hustle and Technical Expertise. More came as the org grew:

• Enablement
• Core Values
• AI Integration
• Management (for Tech Leads)

Inside each bucket, the mistake I see most first-time ladders make is reaching for side effects. They put "velocity" on the matrix, but velocity is a side effect. You cannot directly train for it, and rating someone on it teaches them nothing about what to change.

Take our Hustle bucket:

• Delivery. Whether you can handle work of a given complexity. An SDE-1 ships a component, an SDE-2 ships a feature, an SDE-3 ships a module.
• Predictability. Whether the rest of the team can plan around you. Do you estimate accurately, surface delays early, break work into shippable pieces?

Both are trainable, both are observable, and "velocity" falls out of them. As we grew, we expanded Hustle to include Stability & Performance, because the cost of production regressions scaled with the org.

The test for every competency: is this a fundamental property of how the engineer works, or a side effect of other properties? Keep the fundamentals. Throw the side effects out.

Treat the matrix as living

The first version is wrong, and that is fine. Bars move, and the AI era is the live example right now. The bar on code quality at SDE-2 looks different than it did two years ago, and a Tech Lead in 2026 is expected to think about AI tooling strategy in a way they were not in 2023. If your matrix has not changed in a year, you are either in a freakishly stable industry or you are not paying attention.

Run it in the 1:1, not at promo time

Most teams treat their ladder like a poster on the wiki, pulled out only at promo time. A ladder earns its keep when it lives in the recurring 1:1, rather than as a checklist someone dusts off once a year. Our quarterly 1:1s run on three moves:

• Engineers rate themselves on every competency.
• The manager rates them on the same axes.
• The conversation is the gap between those two reads.

The ladder is the language we are speaking, rather than the thing we are auditing. "Good quarter" stops being a vibe.

Two things fall out of that, almost for free:

1. Performance reviews stop being a one-shot exercise. A year of quarterly scores is the review.
2. Promotion stops being an event. To move from SDE-1 to SDE-2, you have to be performing at the SDE-2 average for a couple of quarters first. Feedback in 1:1s is given against the next rung's bar, rather than the current one. When someone hits the bar consistently, the promotion is mechanical. When they do not, the gap is named on the same axes they have been seeing all year. The HR template at year-end becomes a translation problem, rather than a surprise.

You do not need a beautiful ladder; you need a written one, today. Start with the buckets; two will get you most of the way at a small org. Fill each with the two or three competencies you can defend, sketch what each level looks like in plain English, and get the thing into the 1:1 cycle this quarter. The version you ship in week one will embarrass you by week twelve. Ship it anyway. The cost of waiting is not that you lack a tidy promo process; it is that the engineers on your team spend the year unable to answer the only two questions that matter to them.

---