Career levels are not rungs you climb by doing the same job faster. Each one is a different job, and what changes between them is how much ambiguity you are trusted to own.
Early in an engineering career, most of us carry a mental model borrowed from games: a progress bar that fills as you put work into it. Close enough tickets, ship enough features, fix enough production incidents, and the bar eventually tips over into the next level. The model has an obvious appeal, because it makes advancement feel like something you can grind toward on your own schedule.
For a while, it even seems to work, and for a real reason. An engineer who invests in the technologies their team runs on does tend to advance. Any serious stack has enormous depth in it, and steadily mining that depth earns you larger and more consequential problems. Depth is not the enemy here. Depth is the engine of the entire climb.
But the progress-bar picture quietly gets the mechanism wrong. What earned you the bigger work was never the raw volume of tickets closed; it was that going deep kept putting larger, less defined problems in front of you. Miss that, and you draw the wrong lesson: that the way up is simply more. Past a certain rung, more of the same work stops moving you at all, however well you do it. Sooner or later you watch someone get promoted ahead of you in a year when you shipped more than they did, and the model you had been running on falls apart.
Depth was never the mistake. The mistake was expecting the next level to be the same job scaled up. It is not. Each rung is a different job.
What actually changes as you climb
If you line up the level definitions from almost any engineering ladder and strip away the labels, a single variable does most of the work of separating one level from the next: how loosely defined the problem is when it lands on your desk, and how much you are trusted to resolve that ambiguity without direction.
At the bottom, the work is defined for you and you execute it with guidance. A rung up, you deliver independently inside a clearly scoped problem. Above that, you begin to own outcomes rather than tasks, and you start finding the work instead of waiting to receive it. Higher still, you drive initiatives across team boundaries and connect a business need to a technical solution. At the top of the individual-contributor track, you set direction, translating strategy into a decision about what should be built in the first place.
I have come to think of this as the Ambiguity Ladder. Each rung is defined less by the difficulty of the task than by the vagueness of the problem you are handed and expected to close.
Notice that nothing in that progression depends on what the levels are called. The titles are only local labels for the rungs, and they vary from one company to the next: SWE1 through SWE5 in one place, L3 through L7 in another, Senior and Staff and Principal somewhere else. I have some standing to say the labels are the least important part: I built one of these systems, and the framework my team calibrates against defines five engineering levels, stopping short of the staff and principal rungs that sit above them. Naming the levels was the easy part. What made the framework worth anything was the behavioral progression underneath it. That progression is what stays constant when you move between companies. Learn to read the rung rather than the title, and no relabeling can disorient you.
So set the titles aside and ask the one question that actually locates you: how defined is the work by the time it reaches you?
Ambiguity is not the same as complexity
It is worth slowing down on the word, because it is easy to hear “ambiguity” and substitute “difficulty,” and that substitution hides the whole point. The cleanest articulation I have found is Hunter Gatewood’s, in an essay arguing that ambiguity is a condition of leadership. He reaches, from the leadership side, almost exactly the claim this ladder makes from the engineering side: to ask for advancement (a promotion, a larger project, more responsibility) is to ask for more ambiguity, because decision-making power is precisely the work of choosing a path through what has not yet been defined.
Complexity, in his framing, is a property of the conditions: many moving parts, interlocking systems, layers of people and processes and timelines all in motion at once. Ambiguity is a property of interpretation: how a situation should be read at all, when it honestly supports more than one reading and nobody has told you which one is right. A complex problem often yields to decomposition; break it into smaller pieces and the pieces become tractable, which is the skill strong engineers spend their early years sharpening. An ambiguous problem does not yield that way, because the difficulty is not in the parts. It is in deciding what the problem even is.
The essay has a useful picture of how this sorts itself out inside an organization. New work tends to arrive at the top first, still shapeless, and the more senior a person is, the earlier and vaguer it reaches them. Their job is to sit with that shapelessness, interpret it, commit to the first few moves, and hand down something defined enough for others to execute. Absorbing the unknown on everyone else’s behalf is the work. Not coincidentally, it is also exactly what each rung of the ladder asks you to take on more of.
Which brings the whole thing back to a single word: risk. When a situation arrives fully specified, someone else has already absorbed the interpretive risk for you. You are safe, and you are also denied the only occasion on which you could have shown that you can read an unclear situation and commit to a direction anyway. That occasion is precisely what the higher rungs are testing for. This is also why sheer decomposition skill, however impressive, eventually plateaus. Breaking a complex problem into tractable pieces is a complexity skill. The higher rungs are built out of ambiguity, and ambiguity is not simply more complexity; it is a different kind of problem, and it rewards a different kind of skill.
You cannot fake the base beneath the ladder
There is a floor under all of this that both the ladder and the talk of ambiguity tend to hide. Owning ambiguity is built on a technical knowledge base, and that base does not hold still. The technologies underneath you keep moving, which means the knowledge that made you credible three years ago is not the knowledge that makes you credible now.
This produces one of the more uncomfortable patterns I have watched play out. An engineer accumulates a senior title through some combination of tenure, a well-timed strong stretch, and the general upward drift of a long career, and then stops reinvesting. The technology moves on without them. Within a few years they are being quietly overtaken by engineers several titles below, who actually understand the systems the team is building today.
If you have ever looked up at someone a level or two above you and thought, with quiet certainty, that you handle more ambiguity than they do and ship more besides, you may well have been right, and it is worth being clear about what you are seeing. A title is a claim the organization made about someone at a fixed moment in the past. The work is what is true about them now. When the two drift apart, it is the title that has gone stale, not the work. This is not a reason to dismiss titles or to decide the whole ladder is theater; it is a reminder that a title records where someone was, while the base determines where they are. The market does reconcile the two eventually (I have watched an untitled engineer whose knowledge compounded harder end up out-earning the higher-titled colleague they had long since passed), but it reconciles slowly, and the lag is a genuinely frustrating place to stand.
The lesson runs in both directions, and it is not a glamorous one. Your knowledge base is a depreciating asset. You reinvest in it, or you fall behind.
Once you see the base clearly, you can see that engineers stall in two opposite directions. Some accumulate depth and never convert it into scope: they know their corner of the system extremely well and refuse to reach beyond it, so their impact stops at the team boundary no matter how strong their code is. Others accumulate scope and title while the depth underneath erodes, and eventually the gap becomes visible to everyone around them. Call these depth without scope and scope without depth. They look like opposites, and in a sense they are, but they share a single root cause: a decision, usually unconscious, to stop investing in one of the two things a career actually runs on.
The tell is in the questions
If depth is the base everything else stands on, the practical problem is how you actually read it in a person: a teammate, a candidate, yourself. It does not show up on a résumé. When I look at two engineers holding the same title and try to sense which one is about to move up, the most reliable signal I have found is the questions they ask, and specifically what those questions reveal about how well they understand the system in front of them.
Here is the kind of thing I mean. Two engineers sit in the same design review. One asks questions that reach for the structure of the problem: what the real constraints are, where the trade-offs live, what breaks if a particular assumption turns out to be wrong. The other argues confidently for a specific technical decision (how to decompose a module, which pattern to reach for) without the depth to notice that the decision does not survive contact with the system. You end up walking them through why their preferred approach falls apart, and in the process you learn roughly where their understanding actually stops. It is not a character flaw. It is a measurement.
None of this is an argument against asking questions. Quite the opposite. An engineer who asks a lot of questions is not showing weakness, and the habit of hiding confusion to look senior is one of the most corrosive things in this profession. A question that honestly exposes a gap is doing exactly its job. The tell was never whether someone asks questions; it is what their questions quietly reveal about the depth underneath them.
The title is a claim. The questions are the evidence.
Advancement is finding the work, not waiting for it
Reading the base tells you where someone stands. Moving them requires a change in behavior, and one shift matters more than any other: the move from executing assigned work to owning outcomes and finding the work yourself. In the framework I built, this transition turns on a single question, and I have yet to find a sharper one: when was the last time you identified a problem and proposed a solution without being asked?
This is also where a specific and counterintuitive stall shows up, usually at the more senior levels. I have watched capable engineers, several rungs into their careers, decide that what they really want is to go back to being a pure individual contributor: to close the door, take a well-defined problem, write good code, and go home. There is nothing wrong with loving the craft. But at that level of experience, retreating into the box is not a lateral move. It is a stall, because the ladder above that point is made almost entirely of the ambiguous, cross-boundary, hard-to-delegate work that the retreat is specifically avoiding.
The same instinct shows up one rung down as a refusal to let go. An engineer who should be multiplying the people around them keeps every meaningful decision on their own desk, reviews every design, and makes themselves the bottleneck on their own projects, all in the name of quality. The care is real. The effect is a career that has quietly stopped moving, because the work that would advance it is the work being avoided.
The title is a lagging indicator
So far this has been about what you do to climb. The remaining question is when the title arrives for it, and the answer is later than most people want it to be. The promotion does not start the pattern. It certifies a pattern that already exists. You operate at the next level first (visibly, and for long enough that it reads as your default rather than your stretch), and the title catches up afterward.
This is not a new idea, and I want to be clear that I did not invent it. Organizations have understood its failure mode for over half a century, under the name the Peter Principle: when promotion is treated as a reward for past performance rather than evidence of present capability, people rise until they land in a job they cannot yet do. That is the scope-without-depth pattern from earlier, seen from the organization’s side. The practical defense is easy to state and hard to live: demonstrate the next level before you are promoted into it, not after. Waiting to be handed next-level work before you show next-level behavior is, itself, a sign you are not there yet.
Once you are looking for that pattern, you can see the two ways engineers fail to establish it.
The first is doing the work invisibly. Some of the strongest engineers I know drive genuinely next-level initiatives and then never tell anyone. They do not summarize the outcome, they do not present it, they build no relationships outside the team, and then they are baffled when calibration cannot construct a case on their behalf. The evidence existed; it was simply never packaged. Visibility is not self-promotion. It is the professional skill of making real work legible to the people deciding your level.
The second is doing the work in bursts. This engineer steps up for one large cross-team initiative, operates a full level above their title for a quarter, and then settles back into team-scope work for the next two. They can point to specific moments where they clearly performed at the next level, and they are usually the most frustrated of anyone, because they feel they have already proven it. But calibration does not reward the occasional peak. It rewards the sustained baseline.
The contrast is worth making concrete:
Instead of: “I have been at this level for two years and I am ready. I would like to be promoted.”
Prefer: “Here is the next-level work I have been doing for the last two quarters. What would it take for this to read as my sustained default rather than an exception?”
Finding the rung you are actually on
The advantage of reading rungs instead of titles is that you can run the assessment on yourself, honestly, without waiting for a review cycle to do it for you.
1) Look at where your work comes from. Is it assigned to you, or identified by you? The source of your work marks your rung far more honestly than its difficulty does. An engineer solving hard assigned problems and an engineer finding the problems worth solving are at different levels, even when the code looks similar.
2) Measure the ambiguity, not the effort. How defined was the last significant problem you solved at the moment it reached you? Effort is easy to see and easy to overweight. The vagueness of the problem you can absorb is the thing that actually maps to a level.
3) Find your impact boundary. Where does your influence stop? At your own tickets, at your team’s edge, or somewhere past it? Naming the boundary tells you which transition you are standing in front of.
4) Listen to your own questions. When you engage with a hard technical decision, are you asking to unblock your own execution, or to reshape the problem for everyone working on it? The shift in the kind of question you instinctively ask is one of the earliest signals that a transition is underway.
5) Answer the transition question above your level out loud. Take the defining question for the rung above yours and try to answer it with a concrete, recent example. If you cannot, you have not found a weakness so much as your next assignment.
The climb runs on two investments, not one
The engineers who keep moving are not the ones who found a way to do their current job faster. They are the ones who kept doing two things at once: reaching for larger and vaguer problems than they were strictly handed, and continuing to reinvest in the technical base those problems rest on. Depth without the reach stalls. Reach without the depth collapses. The career is the two of them held together over time.
So the move is not simply to chase ambiguity. It is to be honest about which of the two investments you are short on. If your technical base is genuinely solid, and you are already one of the people others come to when the system behaves in ways no one can explain, then stop asking how to do more of your current job and start asking what larger ambiguity you could take off someone else’s plate and own end to end. If the base is not yet there, that is the more urgent work, because reaching for ambiguity on top of a shaky foundation is how the second kind of stall begins.
You do not climb the ladder by doing your job better. You climb it by quietly starting to do the next one.