Understand Engineering Levels — Career Growth for Engineers, Part 1
Career Growth for Engineers · Part 1
Two engineers on the same platform team both have "Senior" in their title. One has been there nine years and is the person everyone asks about the billing service. The other joined eighteen months ago. In calibration, the second is put forward for Staff and the first is told, kindly, that they're "solidly senior". The first engineer is baffled. They know more, they've shipped more, and they've been here longer.
The committee wasn't measuring any of those things. It was measuring how far each engineer's decisions reached. The first engineer's work, however deep, stayed inside one service. The second had spent a year fixing how four teams handled schema changes, and those teams now worked differently because of it.
The working claim for this part: a level describes the scope of problems you're trusted with, how far your collaboration reaches, and the levers you use to get results. Years and expertise feed into those, but they aren't the measure. If you can't name your company's dimensions and place your own work against them, you're aiming at a target you can't see.
Before you start
Find your company's career framework or ladder document. If there isn't a written one, find out who runs calibration and ask what they look at.
Pick your three most significant pieces of work from the last twelve months. You'll place them on the ladder in Step 4.
Note your current level and the next one, with their exact names. You'll need both.
Step 1: Learn the dimensions, not the titles (10 min)
Titles are the least informative part of a ladder. The useful part is the set of dimensions the ladder uses to tell one level from the next.
Dropbox's published engineering career framework is a clear example. It says three things separate levels: scope (how broad your responsibilities are and how much they affect), collaborative reach (how wide your cross-functional partnerships run), and levers for impact (the mechanisms you use to drive results). The framework calls these "the what that determines the difference between an IC3 and IC4". It then assesses engineers across results, direction, talent and culture, plus discipline-specific craft.
GitLab's public handbook frames it differently but lands in the same place. It says that for individual contributors, "a new type of challenge begins with the Staff Engineer role", and it puts Staff level alongside the first management layer rather than above Senior in the same job.
Most ladders follow this pattern, even when their dimensions have different names. Moving up means the problems get wider and more ambiguous, more people are affected by your choices, and the way you get results shifts from doing the work yourself to changing how other people do theirs.
Test you can run: open your ladder and write down its dimensions in your own words, in under a minute. If you can only list titles, you haven't read it yet.
Step 2: See what changes from level to level (15 min)
The same dimensions read very differently at each rung. This table is a generalisation across public frameworks like the two above. Your company's wording will differ.
Level (typical names) | Scope of problems | Reach | Main lever |
Early career (Engineer I/II) | Well-defined tasks | Own team | Doing the work well |
Mid (Engineer II/III) | Features with some ambiguity | Own team, some partners | Independent delivery |
Senior | Systems and multi-month projects | Team plus neighbouring teams | Design and review |
Staff | Problems spanning several teams | A group or department | Changing how teams work |
Principal and above | Problems spanning the organisation | Organisation-wide | Direction and standards |
The jump that surprises most people is in the last column. Up to Senior, the main lever is mostly your own output, done with more independence and better judgment. From Staff, it's mostly other people's output. That's why a deeply expert senior engineer can stay at Senior for years: expertise deepens the first lever, but promotion past Senior asks for a different one.
Test you can run: for your current level and the next, write one sentence each on the "main lever". If the two sentences describe the same activity done harder, you've misread the gap.
Step 3: Separate level from title and from tenure (10 min)
Titles don't transfer between companies. A "Senior Engineer" at a twenty-person startup and one at a large enterprise may be operating at different levels, and some companies compress their ladders while others stretch them. GitLab's handbook, for example, describes at most eight layers across the whole company and pairs Principal with Senior Engineering Manager.
Tenure doesn't transfer either. Time in a role lets you build the behaviours the next level asks for, but it doesn't count as evidence of them. The nine-year engineer in the opening had plenty of time. What they didn't have was work whose reach matched the next rung.
When you compare yourself to someone at another company, compare scope and reach, not titles. Tools that map levels across companies can help as a rough guide, but the definitive answer is always the hiring company's own definitions.
Test you can run: describe your role to a friend at another company without using your title. Just say the widest problem you own and who is affected. Ask them what level that would be where they work.
Step 4: Place your own work on the ladder (15 min)
Take the three pieces of work from "Before you start". For each, answer three questions:
Scope: how big and how ambiguous was the problem when you picked it up? Was it handed to you already defined, or did you have to work out what the problem was?
Reach: whose work changed because of it? Name the teams.
Lever: did you get the result by doing it, by designing it for others to do, or by changing how other people decide?
Then mark which level each answer matches on your ladder. Be strict: if a dimension matches your current level, mark it there, even if you worked very hard.
Most people find their three pieces sit at different levels on different dimensions. A common pattern for a strong senior engineer is next-level scope with current-level reach: big problems solved, but solved inside one team.
Test you can run: count how many of your nine marks (three pieces × three dimensions) sit at the next level. Fewer than three usually means you're not yet operating there consistently. That's useful to know, not a verdict.
Step 5: Ask what the bar looks like in practice (10 min)
Written ladders are abstract on purpose, so they can cover many teams. Calibration happens on examples. The fastest way to close the gap between the words and the bar is to ask people who apply it.
Ask your manager, and if possible someone who sits in calibration, three questions:
"Who was recently promoted to the next level, and what work made the case?"
"What did the committee see as missing in cases that didn't go through?"
"Which dimension do people at my level most often underestimate?"
Write the answers down and compare them with what you found in Step 4.
Test you can run: after the conversation, can you name one concrete piece of work, at your company, that clearly sits at the next level? If not, ask again with that exact question.
Step 6: Choose the dimension you'll grow next (10 min)
Don't try to move every dimension at once. Pick the one where your Step 4 marks lag most, and find a piece of work in the next quarter that stretches it.
If your gap is reach, look for a problem that crosses a team boundary: a shared library nobody owns, an incident pattern that recurs across services, a migration several teams dread. If your gap is scope, ask to take on a problem before it's been broken down, and do the breaking down yourself. If your gap is the lever, take something you'd normally build and design it for someone else to build, then review their work.
Test you can run: write one sentence: "This quarter I'll stretch [dimension] by [specific work], and my manager agrees it's the right stretch." If you can't get the last clause, have that conversation first.
Worked example (composite)
A composite scenario, not a real company or person.
A senior engineer at a mid-sized insurer had been at Senior for four years and expected to be put forward for Staff. Their manager didn't. The engineer asked why and got the answer "you're not operating at Staff yet", which told them nothing.
They did the exercise above. Their three best pieces of work were a rewrite of the quoting service's pricing module, a two-week effort to stabilise flaky integration tests, and being on call for the most complex service. On scope, the pricing rewrite was clearly Staff-sized: the problem was ambiguous and involved regulatory constraints. On reach, all three stayed inside one team. On lever, all three were "I did it".
The pattern was obvious once it was written down. They then asked someone in calibration the questions from Step 5. The answer: the last two Staff promotions had both been people who changed how several teams worked. One standardised contract testing between services; the other led a cross-team incident review practice.
The engineer took on the flaky-test problem again, this time across all four teams that shared the integration environment. They wrote a short proposal, got each team to agree a quarantine rule, and paired with one engineer from each team to fix the worst cases. Within two quarters, the reach and lever dimensions had moved. Their next calibration discussion was about evidence, not about whether they'd "got it".
Trade-offs to make deliberately
Choice | You gain | You risk |
Deepen expertise in one system | Indispensable expertise, valued at Senior | Reach stays narrow; next-level case is thin |
Take cross-team work | Evidence for reach and lever | Less time in your area of depth; slower visible output |
Push for promotion early | Faster feedback on the gap | A "not yet" can shape how calibration remembers you |
Wait for a strong case | A stronger first submission | Time passes without a clear signal |
Common failure modes
Treating tenure as the case. Time helps you build the behaviours; it isn't evidence of them.
Comparing titles across companies. Compare scope and reach instead.
Working harder on the same lever. Past Senior, the gap is usually a different lever, not more effort.
Never reading the ladder. You can't aim at a bar you haven't seen.
Assuming management is the only way up. Many ladders, including the two cited here, have IC levels that run in parallel with management.
Final takeaway
A level is a statement about scope, reach and the levers you use, not about how long you've been somewhere or how much you know. Read your ladder's dimensions, place your own work against them honestly, and stretch one dimension at a time. Your next action: do Step 4 on your three best pieces of work this week, then take the result to your manager.
Sources
Dropbox. Dropbox Engineering Career Framework (overview and level expectations). dropbox.github.io/dbx-career-framework, accessed October 2026.
GitLab. Engineering Career Development and Organizational Structure, GitLab Handbook. handbook.gitlab.com/handbook/engineering/careers, accessed October 2026.
Continue the Career Growth for Engineers path
Next — Part 2: Write a Promo Packet
Part of the Career Growth for Engineers learning path. Related: Grow a Mid to Senior · The Senior Engineer's Blind Spot · The Tech Lead Transition.
