Levels and legible progression
A written ladder is for the engineer first. Performance, eval, and promotion fall out of it.
My first full year as a manager-leaning IC at a startup ended with an appraisal cycle that surprised most of us. We had spent the year getting one kind of feedback (code contribution, the basics of management) and were graded at year-end against a template none of us had seen until December. The scores dipped. The 1:1s afterwards were not the conversations any of us had been preparing for.
The bad scores were the symptom. The actual loss was the year itself. We had spent twelve months unable to answer two questions any engineer is silently asking: 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.
The first thing I want a new EM to internalise: a ladder is for the engineer. Not for HR, not for you. Every team member has a career, and every career needs a yardstick. Build the yardstick 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 Google Sheet, 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.
Roles aligned with 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.
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, competencies as fundamentals. 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. Enablement, Core Values, AI Integration, and a Management bucket for Tech Leads came as the org grew.
Inside each bucket, the move I see most first-time ladders get wrong is reaching for side effects. They put "velocity" on the matrix. 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 is 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 is 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. 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.
Now the operating mechanic. Most teams treat their ladder like a poster on the wiki, pulled out only at promo time. A ladder earns its keep when it is the substrate of the recurring 1:1, not a checklist someone dusts off once a year. In our quarterly 1:1s, engineers rate themselves on every competency, the manager rates them on the same axes, and the conversation is the gap between those two reads. The ladder is the language we are speaking, not the thing we are auditing. "Good quarter" stops being a vibe.
Two things fall out of that, almost for free. Performance reviews stop being a one-shot exercise; a year of quarterly scores is the review. And 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, not 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, not 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.