The engineering IC track most companies say they have — and what a real one looks like

At most companies, the career ladder splits in two after Senior Engineer. One path leads to Engineering Manager. The other leads, nominally, to Staff Engineer, Principal, and beyond. On paper, the engineering IC track exists. In practice, it's a management track with a consolation prize attached to it.

The consolation-prize version looks like this: Staff Engineer is the title you get when the company can't promote you to EM right now, or when you've made clear you don't want to manage. The role is vaguely defined. Your promo case depends on how much you 'led', which in practice means how much you herded people. Compensation tops out below what the EM path would have paid. There's no Principal role. If there is, nobody really knows what it means.

Only about 30% of companies have clear advancement paths for ICs beyond Senior Engineer. Most others claim to. The gap between these two groups isn't intent — it's structure.

Three signs your engineering IC track is fake

Sign 1: scope is defined by team size, not problem type

If the main differentiator between Senior and Staff is 'works across multiple teams' or 'influences a larger org', you've encoded a management-flavoured expectation into a technical role. Senior engineers already do cross-team work. Staff engineers do different work, not just more of it. The distinction should be about the nature of the technical problems, not the headcount influenced.

At companies with real IC tracks, a Staff Engineer is the person whose technical judgment the team would trust to define the problem before anyone writes a line of code. That's different from 'shows up to alignment meetings for multiple squads.' The first is a technical judgment call. The second is coordination. Valuable, but not a Staff-level differentiator.

The practical test: can you describe, in one concrete sentence, the difference in scope between Staff and Senior at your company, without using the words 'bigger', 'more', 'strategic', or 'cross-functional'? If not, the scope definition is doing no real work.

Sign 2: promo cases read like manager promo cases

Pull up three recent IC promotions from Senior to Staff. If more than half the bullet points are about people (mentored X, aligned Y team, drove consensus on Z), your evaluation process doesn't distinguish between a senior IC and a junior EM. Both will score well on the same criteria. Neither will know why one got promoted and the other didn't.

Real IC promo cases cite technical artifacts: a design document that changed the architecture, a debugging session that found a class of bugs rather than a single bug, a migration plan that nobody else on the team could have written. The output is code, documents, and decisions. Not meetings attended.

Sign 3: compensation is embarrassing above Staff

The companies with genuinely real IC tracks tend to pay Principal and Distinguished Engineers at or above what manager equivalents earn at the same organisational level. Some pay Distinguished Engineers more than most VPs. That's not accidental. It's the only structural way to stop your best ICs from concluding that management is the only path with economic dignity.

When the IC band embarrasses anyone above Staff, the message is clear regardless of what the company says at all-hands. Engineers read pay bands. The pay band communicates where the company actually puts its money, and a discounted IC track signals that deep technical expertise is valued in the abstract but not in practice.

What Staff scope actually means at a 60-person company

The most useful articulation of Staff Engineer scope is that the role exists for technical problems that, without this person, would either go unsolved or get handed to an EM who'd have to learn the domain from scratch.

At a 60-person company, that might look like: the engineer who owns the database migration strategy for a schema that's become load-bearing, has never been properly documented, and has four years of undocumented assumptions baked in. Nobody else on the team knows enough to make the right calls. The Staff Engineer isn't the person who executes the migration. They're the one whose judgment the team trusts to define what 'right' even means before execution begins.

That's a different thing from 'leads multiple squads' or 'drives roadmap alignment.' It's a specific type of technical judgment that most engineers don't develop. Not because they couldn't, but because they were never given problems that required it.

The implication: Staff scope is partly a property of the engineer and partly a property of the problems you give them. If your Staff-level engineers are doing glorified ticket execution, the IC track isn't failing. The roadmap is. You can't develop Staff Engineers without Staff-level technical problems to put in front of them.

Writing promo criteria that don't secretly favour managers

The most common structural error is writing IC promo criteria that look technical on the surface but actually measure manager-adjacent behaviours. The contrast matters:

The right column isn't wrong for an EM promo — those behaviours matter for managers. But they describe the overlap between good ICs and good EMs, not what distinguishes them. When your promo criteria live in the overlap, promotions become inconsistent and engineers can't tell what to actually work toward.

The structural fix that matters most

Everything above (scope definition, promo criteria, compensation) follows from one upstream decision: who is responsible for an IC's career development.

At most companies, the answer is the engineering manager. The EM writes the promo feedback, identifies growth opportunities, and coaches the IC on what Staff scope looks like in practice. The problem: the EM was almost always promoted from Senior Engineer straight to EM. They have never done Staff-level IC work. They don't know what it looks like in practice, which means they're structurally unable to sponsor it.

The companies that have genuinely solved this assign a senior IC, either Principal or Distinguished, as an explicit career coach for engineers who want to stay on the IC track. Not a mentor (ad-hoc, relationship-driven, informal) but a coach: someone with a defined responsibility to write promo feedback, identify the right problems for growth, and model what excellent looks like at each level.

This sounds like significant overhead at a 30-person company. In practice it's one focused conversation per month between a Principal Engineer and a mid-to-senior engineer, with a short written summary of what was discussed. The overhead is low. The signal it sends lands clearly: the company takes the IC track seriously enough to assign someone whose role includes developing it.

The EM can still support the IC's career. They should. But for engineers who want to stay IC, the most useful career input comes from someone who actually did it.

You need real ICs at the top first

None of this works if your most senior technical people are EMs who used to be engineers. If your Principal Engineer title belongs to an EM who codes on weekends, you don't have a Principal Engineer. You have an EM with a different badge.

The IC track is downstream of having people who actually took it. If the founding team, the VPs, and the technical leads all went the management route, the IC track will be designed by people who never lived it. It will reflect that in every detail: the vague scope, the manager-flavoured promo criteria, the comp band that trails.

The single most effective thing a company can do to make its IC track real is hire or develop one person at the Principal or Distinguished level who is genuinely, visibly staying IC. That person becomes the proof of concept. Engineers below them can see where the path goes. That's harder to fake than any amount of ladder documentation.

Closing

Engineering ladders don't fail because companies are indifferent. They fail because the IC track is designed by people who went the management route, for a career path they didn't personally take. The result is a path that's technically available but practically invisible: nobody to model it, nobody to coach it, nobody who can articulate what excellent looks like at each level.

The fix isn't a better template or a more carefully worded competency matrix. It's a structural commitment: real scope definition at each level, promo criteria that actually distinguish IC from EM, compensation that doesn't signal which path the company really values, and at least one senior person on the IC track who actively invests in developing the people below them.

That last one is where most companies stop. It's also where the gap between a real IC track and a consolation prize becomes visible.