The IC track at most engineering companies isn't a track — it's a waiting room

Every engineering organisation above 30 people has this conversation eventually. A strong senior engineer schedules a growth check-in with their manager. They've been shipping reliably for three years. They want to keep growing without managing people. Their manager pulls up the internal levelling guide. The Staff level exists on paper. Nobody at the company actually holds it in a way that means anything to a new hire. The conversation ends without resolution. Six months later, the engineer is at a competitor, where they tell this story to a recruiter as the reason they left.

This isn't a retention problem. It's a ladder design problem. The companies that solve it don't do it by adding more levels or writing longer expectations documents. They do it by changing what their IC levels are actually measuring.

IC levels measure complexity of work — management levels measure scope of ownership

Most engineering ladders were copied, directly or loosely, from companies that were, in turn, copying other companies. The template is familiar: Junior, Mid, Senior, then a branch point. Management to the left, IC to the right: Staff, Principal, Distinguished.

The management track has a legible shape. The Senior Engineer becomes an EM, the EM manages a team, the team grows, the EM becomes a Senior EM. What people at each level own is concrete: headcount, performance reviews, team output. You can audit it. You can have a disagreement about it. It means something definite.

The IC track, in most companies, has no equivalent clarity. 'Staff' gets described as: does the work of a senior but thinks across teams. 'Principal' becomes: thinks very broadly and is respected across the organisation. These are descriptions of cognitive posture. They tell you how someone thinks, not what they decide. They don't answer the one question that motivates ambitious engineers: what specifically is mine to own?

That gap is the load-bearing design flaw. Most retention problems in senior IC pools trace back to it, even when they look on the surface like compensation or scope or management quality problems.

What management tracks give engineers that IC tracks mostly don't

When an engineer becomes an EM, something concrete shifts. They own a set of 1:1s. They own performance reviews for a group of people. When a deliverable slips in their team, it's their problem to fix, not just to flag. They're in headcount planning meetings. They get pulled into compensation conversations for their reports.

None of this is glamorous. But it's theirs. The scope of ownership is legible. When something goes wrong in their area, there's no ambiguity about whose job it was to prevent it.

Strong senior ICs who don't want to manage people aren't asking for headcount. But they're asking for the equivalent: a thing that is theirs to own, where their judgment is the deciding call, where something would be measurably worse if they left. An IC track that can't offer that is offering visibility and a salary band, not a career. Most engineers above a certain level can tell the difference.

What a real parallel track looks like

A useful diagnostic: for each IC level, can you finish the sentence 'this person owns _____ and has final say on _____'? If you can't, you haven't written a level. You've written a character reference.

The right-hand column is harder to define cleanly than a headcount number, but it isn't impossible. The test is ownership, not participation, not expertise. The Staff engineer isn't just the person who knows the most about the payments infrastructure; they're the person who decides how payments works when there's a real tradeoff, and who's accountable for that call six months later. If your Staff engineer isn't in the room when architectural tradeoffs are made in their area, your Staff level is a title.

The Principal level is harder to pin down in smaller companies. A reasonable definition: a Principal engineer holds a technical position before it's obvious to everyone else. They call a direction when the data is still ambiguous, own the outcome, and earn credibility through being right more often than not. That's meaningfully different from 'very experienced' or 'writes thorough design docs.'

Two failure modes worth naming

Level inflation. This is using IC titles as retention mechanisms rather than role designations. A strong senior engineer gets promoted to Staff not because their technical scope has grown, but because they're five years in and the company doesn't want them to leave. It works once. Then there's a building full of Staff engineers whose actual scope doesn't require the title, and nobody who genuinely owns the Staff-level decisions. The next strong engineer hired looks around, sees Staff on everyone's badge, and either exits quickly or concludes the ladder is decorative.

Vague expectations. The second failure is writing IC levels that describe quality of thinking rather than scope of decision. "Thinks across teams," "influences architecture," "is a force multiplier" — these are things you can say about any good senior engineer. They give neither the engineer nor their manager a concrete test for when the level fits. You end up promoting people who check the right cultural boxes rather than people who have demonstrated the right kind of ownership.

Both failures share a root cause: the expectations were written for the people already in the room, not for the role the company actually needs to fill. Fix the root, and the symptom disappears.

A three-question audit for your own ladder

If you're designing or revising a career ladder, these three questions surface most of the problems before they become retention incidents.

1. For each IC level above Senior: can you name one decision this person made in the last quarter that an EM wouldn't have made? If not, the level isn't doing work in your organisation — it may exist on paper but it isn't functioning as a career destination.
2. Does the IC at the top of your ladder have any equivalent of headcount, something that's their responsibility even when nobody is watching? If not, you've given them a title, not a role. The test is whether the responsibility persists when you're not in the room.
3. If your most senior IC left tomorrow, would the team notice in how decisions get made, or only in how much work gets done? The first answer means they have real scope. The second means they're a force multiplier, genuinely valuable but not what a career track promises. Both profiles matter; only one of them is Staff.

None of this means every engineer should want decision-making authority. Deep individual contribution — writing code that other engineers treat as a reference implementation, building systems that outlast the team that shipped them — is genuinely valuable and doesn't require title inflation. The point is that if your IC track only works for that profile, you've built one path for one kind of engineer. The engineers who want to grow into technical leadership without managing people need somewhere to actually go.

Most engineering ladders were designed, implicitly, for the people who stayed — engineers content in their scope, not asking hard questions about what they owned. That works until it doesn't, typically around the time you hire the first engineer who has seen a company where those questions were answered seriously.

What you're designing when you build a career ladder isn't an HR document. It's an answer to the question: what kinds of growth can we make room for? If the only legible path to owning something goes through managing people, that's not accidental — it's a position. The organisations that retain strong technical contributors are the ones who have owned that position deliberately and changed it.