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, but the real 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.

If you are a new EM, the thing to settle before anything else is who the ladder is for, and the answer is the engineer, whose career needs a yardstick, and neither HR nor you. Build it for the engineer first and the things you stress about as a manager (promotion process, calibration, "fairness", HR's annual ritual) become mechanical translation problems. Build backwards from "we need a promotion process" and you get a worse ladder, because a promotion process answers to whoever has to defend the decision, so the document drifts toward the appearance of fairness and away from the engineer's real question, which is whether they are 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, and 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.

There are 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, and if it sits way above, nobody outside your company will value your titles, and your engineers will quietly resent carrying a title the market discounts.

Build a continuous path

Look at your ladder from any rung and ask whether someone standing on it can see the next move. A random jump does the same damage as an unreachable rung, and so does a level defined as "you'll know it when we see it": all of them make growth feel like a lottery. If you cannot articulate what gets someone from rung N to rung N+1, that gap is the part of the ladder you have not written yet.

Buckets first, then competencies

A matrix has two layers. Buckets are the broad categories, things like Hustle or Technical Expertise, and inside each bucket sit a handful of competencies, the specific things you score an engineer on. Get the buckets right first, because 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, and 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 I run on every competency is whether it describes a fundamental property of how the engineer works or a side effect of other properties, and only the fundamentals earn a row.

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, either your industry has stood unusually still or the matrix has, and I know which one I would bet on.

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, and the arrangement is stable because nobody needs the poster until a promotion is contested, at which point it gets read as ammunition rather than as a yardstick. A ladder earns its keep when it lives in the recurring 1:1 instead. 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 becomes the language the conversation is held in rather than the thing being audited, and "good quarter" stops being a vibe, because both of us can point at the exact cells we read differently.

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, and 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 need the ladder written down more than you need it to be good. Two buckets will get you most of the way at a small org, so 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, and you should ship it anyway, because every week it stays unwritten is a week your engineers spend guessing at the bar.

---