Why most engineering ladders are a single track in disguise

Most engineering ladders at startups above 20 people look structurally sound on paper. You have a management track: EM, Senior EM, Director, VP. You have a technical track: Senior Engineer, Staff Engineer, Principal Engineer, sometimes Distinguished. Both tracks branch at Senior. Both lead somewhere.

In practice, most engineers who reach Senior understand, without being told, that management is the serious path and the technical track is for people who chose not to make the transition. This perception rarely comes from anything said aloud. It comes from what the ladder actually rewards.

The dual-track that is not

The tell is in how the levels are described. Look at how most ladders define a Staff Engineer:

"Drives alignment across multiple teams. Defines technical strategy for a product area. Influences decisions outside their immediate scope. Mentors Senior Engineers."

That is a manager. It is a manager who writes code sometimes, but the measurable behaviours — alignment, strategy, influence, mentoring — are all management behaviours. The ladder has a technical track in name and a single management track in practice.

This is not a problem unique to carelessly designed ladders. It happens at companies that thought carefully about this, because the people writing the ladder understand career progression through the lens of management. How do you get more scope? You lead more. How do you demonstrate Senior+ impact? You influence beyond your team. These frames are so natural to engineering leaders that they apply them without noticing, even when they are explicitly trying to do otherwise.

Design flaw 1: Technical roles written in management language

The problem is not that alignment and influence are wrong criteria for Staff Engineers. They matter. The problem is that they appear as the primary behaviours rather than supporting ones. An IC who makes an outsized technical contribution — rebuilds the system that saves 600ms on every request, builds the internal tooling the whole engineering team relies on — can fail to clear the Staff bar because they did not "drive alignment" while doing it.

The fix is to separate the technical track's primary behaviours from its secondary ones, and write the primary behaviours in technical language first. For each level, answer this question: what kinds of technical problems does someone at this level hold that the level below them does not? Then add the collaboration and communication criteria as supporting evidence, not as the bar itself.

At Staff, the primary bar might be: "owns the design and evolution of systems used by multiple teams; makes architectural decisions without escalating." At Principal: "identifies and resolves technical problems whose scope is not yet obvious to others in the organisation." The management-style criteria — mentoring, driving cross-team alignment — become ways to demonstrate impact, not the definition of it.

Design flaw 2: Progress on the technical track stays invisible

Management progression is visible by default. An engineer becomes a team lead. Then they take on a second team. Then they hire three people. These are countable events that appear in org charts and quarterly reviews.

Technical progression is not visible in the same way. A Staff Engineer might spend six months rebuilding the core data model such that three teams ship faster for the next two years. There is no org-chart change, no additional headcount, no item in the quarterly business review. The work happened; the progress is invisible unless someone actively surfaces it.

Companies that do not solve this problem end up with senior ICs who do excellent work that goes unrewarded, and who eventually move into management not because they want to but because it is the only path where progress is legible.

Two mechanisms that work without adding much overhead:

Scope documentation. Every Staff+ IC maintains a short document (one page, updated quarterly) that defines their current technical scope: what systems they own, what cross-cutting problems they are working on, what changed in the past quarter and what the result was. This does not require a formal process; it is the IC's responsibility. It becomes the artefact that makes technical progress visible at review time.

Technical review presentations. Four times a year, senior ICs present a ten-minute technical overview to a mixed audience of peers and managers. Not a project status update — a technical argument: here is the problem I chose to work on, here is why I chose it over other things, here is what I built, here is evidence it was worth building. This creates a regular cadence for making invisible work visible, and has a side effect: ICs who do these presentations consistently tend to self-calibrate against the ladder much more accurately, which reduces surprises at formal review time.

Design flaw 3: The technical track runs out first

Most ladders top out at Principal or Distinguished. At a 40-person startup, Distinguished Engineer is not a real level — not because no one is good enough, but because the scope the role requires does not exist yet. The result is that the technical track has three functional levels (Senior, Staff, Principal) and the management track has five or six. The technical track runs out faster.

This creates a ceiling that managers do not hit. A Principal Engineer at a company of 60 people has nowhere obvious to go except into management. The ladder has the right words, but its architecture still funnels people toward management at the top end.

Two partial fixes. First: do not add levels above Principal until the company is large enough that the scope genuinely exists. A Distinguished Engineer label at 50 people signals that the progression path was invented rather than discovered — and engineers can tell. Second: redefine what growth means at Principal and above. Instead of scope expansion, which has a ceiling at small company sizes, growth at the top of the technical track looks like depth (going further into a hard problem than anyone at the company has), breadth (contributing across domains without owning them), and external contribution (writing, speaking, influencing the field). These forms of growth do not require the company to grow.

Three fixes, in order of priority

The three problems share a root cause: the ladder was built by people whose mental model of career progression is a management mental model, even when they explicitly intended to build a dual-track system. The fixes are surgical changes to an existing document, not a full redesign.

First: rewrite the technical track roles so that technical behaviours are primary. For each Staff+ level, answer the question "what kinds of technical problems does someone here hold that the level below them does not?" Then add the collaboration expectations. This is a half-day rewrite, not a project.

Second: build a visibility mechanism and make it non-optional. Scope documents and quarterly technical review presentations are the lowest-overhead options. Whichever mechanism you choose, it needs to exist before the next promotion cycle, not as a response to someone raising a grievance.

Third: audit the top of the technical track. If the top level requires a scope that the company's current size cannot support, either remove the level or redefine its growth criteria as depth, breadth, and external contribution rather than expanded organisational scope. The goal is a track with no implicit ceiling, not a track with impressive-sounding levels that no one will reach.

A note on keeping the ladder current

The most common failure mode after writing an engineering ladder is that it becomes a reference document nobody looks at until someone files a promotion request. A ladder reviewed only reactively drifts from what the company actually values, usually within 18 months of first being written.

Treat it as infrastructure. Review it once a year, regardless of whether any promotions are pending. The signal that it needs updating is not the promotion process failing — it is the wrong people advancing. When the engineers who excel at running processes advance and the engineers doing the deepest technical work stay flat, the ladder has stopped describing what the company rewards. Updating the document at that point is not a fix; it just names reality more accurately. The fix is updating it before that drift sets in.

The engineers who do not get quietly funnelled toward management are the ones who believe the track they are on is real, visible, and goes somewhere. That belief does not come from the ladder's design alone. It comes from the company consistently acting as though the ladder means what it says.