The Engineering Career Ladder Trap: When Staff Engineer Becomes a Consolation Prize

Last updated: September 18, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

The title change and the rejection arrived in the same meeting.

A senior engineer on a loan-origination platform had spent most of a year making her case for the engineering manager opening on her team. She ran the incident reviews. She had onboarded the last four hires, two of them from bootcamps, both still there. On a Thursday her director told her the role was going to an outside candidate, and then, in what he honestly believed was the good part of the conversation, told her she was being promoted to staff engineer. Same meeting. Maybe fifteen minutes, start to finish. She thanked him, went back to her desk, and summed it up for a teammate, who repeated it to me months later. “So this is the consolation prize.”

She resigned eleven months after that, on good terms, to run a team at a competitor. I do not blame her.

I have heard some version of her sentence in more engineering orgs than I would like to admit. For years I did not have a good name for the pattern. Then I found out two researchers at MIT had named it in 1985, in almost exactly her words.

This piece is about the engineering career ladder most growth-stage companies build around that moment, the parallel ladder where Staff Engineer is supposed to sit level with Engineering Manager, and why it so often turns into a holding pen. It is also a partial correction of something I wrote. I got it half right. In my Builder-Leader-Advisor Arc piece I called staff and principal roles genuine progression for engineers who want to keep building. I still believe that, wherever somebody actually built them.

If you have not read what a management promotion costs when nobody wrote a transition plan, start there. That piece is about the people who walk through the management door. This one is about everybody you point at the other door, and what is waiting on the other side of it.

What a Dual Engineering Career Ladder Is Supposed to Do

A dual career ladder is a promotion system with two parallel tracks above senior engineer, one for managers (engineering manager, director, VP) and one for individual contributors (staff, principal, distinguished engineer). Each technical level is meant to match its management counterpart in pay, scope, and influence, so strong engineers can keep advancing without taking on direct reports.

Nobody agrees on names. The titles change from company to company, and so do the level codes in front of them. Treat the table below as the shape most mid-market ladders end up with, not as anybody’s official chart.

Look at where that table starts. Will Larson, whose StaffEng guide to getting the title is about as close to a shared reference as this corner of the field has, puts it plainly. “Senior engineer is the career level at most companies.” He adds that most companies “have no expectation that you’ll ever go from Senior to Staff.” I agree with him. It shapes everything below. The dual ladder was never meant to be a staircase for everyone. At most companies only a handful of engineers ever reach the fork.

Which is exactly why the fork has to be real.

The 1985 Study That Already Described Your Staff Track

For a study published in 1985, Thomas Allen and Ralph Katz surveyed engineers and scientists at nine U.S. organizations, a mix of government labs, government-focused not-for-profits, and four private companies in aerospace, electronics, and food. They got 2,157 usable questionnaires back, with response rates between 82% and 96%. That is a serious sample. Their MIT Sloan working paper, published in R&D Management the following year, has a title I wish every VP of Engineering would read before touching a leveling doc. “The Dual Ladder: Motivational Solution or Managerial Delusion?”

They start with the promotion from my Thursday meeting. An engineer who is told they have been selected for the technical ladder, the authors wrote, hears that the organization does not think they will make a good manager. “The technical ladder promotion then becomes a consolation prize, and very often de-motivates an otherwise productive member of the staff.” I read that line twice.

Two more problems follow, and both will be familiar to anyone who has sat through a calibration cycle.

Power comes first. Companies worked hard to equalize salary and perks between the two tracks, but the authors pointed to “one key ingredient of the managerial ladder, which is missing from the technical ladder,” and that ingredient is power. A manager asks for something and a team mobilizes. An engineer on the technical ladder asks for the same thing and gets a thoughtful reply in a thread. Nothing moves. Everyone inside the building can see the difference, so the supposedly equal role reads as the lesser one.

Drift is the other. Promotion criteria get applied carefully for the first few years and then, in their words, “gradually become corrupted.” The ladder turns into a reward for loyalty instead of technical contribution, or into what they called “a repository for failing managers.” Either one, they wrote, destroys whatever reward value the system had. I have seen both.

Then there is the detail I keep quoting to directors. One company weighing a dual ladder informally polled 13 other companies that already ran one. Most reported some degree of satisfaction. Asked whether they would do it again, given the chance, 12 of the 13 said definitely not. They meant it.

Software companies adopted the arrangement at scale decades later, with better titles and equity. The failure modes survived intact. I have watched every one of them play out in fintech alone.

How the Consolation Prize Gets Built Today

Nobody designs a ladder to be a holding pen. It happens anyway. The pen gets built one reasonable decision at a time, usually by a director who is trying to keep a good engineer from leaving. Look under the hood of the ladders I have been asked to fix and you usually find one of three things.

The first is timing. Pull the dates of your last dozen staff promotions and put them next to the dates of your management hiring decisions. At a mortgage-tech company I advised, four of the seven staff promotions in a two-year window landed within thirty days of that same engineer being passed over for a manager role. Nobody planned it that way. Each one was a director softening a no. Stacked together, they taught the whole org what the staff title meant, and the engineers who got it for the right reasons paid for the lesson.

The second is authority, and it is the one Allen and Katz would recognize first. Ask this in your next staff sync. Who made the last decision about your data platform, and was a staff engineer the person who made it? I ran a version of that exercise at a lending platform with about seventy engineers and eight staff titles. I asked each staff engineer to name one technical decision they owned outright, meaning they could make it without escalating and it would stand. Three could. The other five described influence. They wrote proposals, gave feedback, “drove alignment.” I winced. Influence is what an org calls authority it never wrote down. Nothing about the code base was wrong there. The decisions simply lived in hallways and in the director’s head, which is why I now bring a one-page decision ownership map to every ladder conversation.

Then there is the rubric. Eleven expectations for staff engineer, at one company whose leveling doc I read line by line last year. Seven of them described management work. Mentors engineers across teams. Runs hiring loops. Contributes to performance calibration. Leads team rituals. If the way to earn the IC title is to do a manager’s job without a manager’s authority, you have built a management track with a worse deal and a technical-sounding name.

A retention bribe fits the same pattern. So does parking a manager who wanted out of people management in a staff seat with no defined scope. Both can be the right call for the person. Sometimes they are. Both still teach the rest of the org that the title is a place you get put.

Pay Parity Was the Easy Part

Managers still earn more. Anyone designing a ladder should start from that fact rather than pretending it away. Computer and information systems managers earned a median of $175,140 in May 2025, per the Bureau of Labor Statistics, and their finance and insurance median ran to $182,510, which is the corner of the economy where most of my career has been. Software developers in that same federal wage survey landed at $135,980. That is a gap of roughly $39,000 at the median before anyone mentions equity.

Most companies with a serious ladder close that gap on paper at staff. Some overshoot it. KORE1’s staff engineer salary guide sees the same thing from the recruiting side. At most employers the two roles get calibrated as peers, and the base pay difference between them is usually a rounding error.

So money gets fixed. It is the part HR can solve with a spreadsheet and a budget line.

Decision rights are harder. They require a director or a VP to give something up, in writing, where everyone can see it. That is why the power gap Allen and Katz described in 1985 outlived forty years of compensation benchmarking, salary surveys, and leveling consultants, while the pay gap inside those same companies mostly got solved. Matching the band is a finance exercise. Matching the authority is an org design decision, and most orgs never make it on purpose.

The Consolation-Prize Test

You can check your own ladder in an afternoon. I have timed it. None of these require a consultant, and you will not like all of the answers.

• Ask every staff engineer to name one decision they own outright. Write down how many can. If it is under half, your staff title is an influence title.
• Compare staff promotion dates against manager-opening decisions for the last two years. Any cluster inside thirty days is the consolation prize, showing up in your own HR data.
• Were your staff engineers in the room for the last headcount plan? Not consulted afterward. In the room.
• Count the rungs. If the management track runs to VP and the IC track stops at principal, the ladder is telling your engineers exactly how far depth can take them here.
• Read the staff rubric and highlight every line that describes managing people. More than a third highlighted means you wrote a management job description.
• How many people have moved from manager back to staff in the last two years, with title and pay intact? Zero is an answer. It usually means the door only swings one way.

Every director I have walked through this list has argued with at least one item. That is fine. I ask them to show me the data, and most of the arguments end right there. A ladder that passes all six is rare, and it tends to be obvious from the outside, because its staff engineers talk about what they decided last quarter instead of what they suggested.

What a Real IC Ladder Gives a Staff Engineer

The fix is less dramatic than most leaders expect. You rarely need new levels. You need the existing ones to carry something.

Start with scope. A manager’s scope is obvious because it has names in it. Staff scope rarely does. A staff engineer’s scope should be written down just as concretely, naming the problem, every team it reaches into, the decisions that now belong to the staff engineer, and how anyone will know it is getting solved. On a payments platform that might read like this. “Owns the ledger consistency model across the three services that write to it. Final call on schema changes to the ledger tables. Success is zero reconciliation breaks per quarter by Q3.” That is one paragraph. It took the director about an hour. Nothing I recommend does more for a staff engineer’s standing than that hour.

Tie the count to the work. I get asked for a ratio constantly, and I will give one in the questions below, but the better answer is that the number of staff engineers should equal the number of cross-team problems worth a senior person’s full attention. Staff roles can end. When a problem gets solved, the role should either take on a new one or the person should know, well in advance, what comes next. A title that never has to justify itself drifts. Allen and Katz said so.

Build the door in both directions. Moving from engineering manager back to staff, or from staff into management, should be a lateral move inside the same band, with the same pay. The first time a manager steps back to staff and nothing bad happens to their comp or their reputation, the whole org relaxes about the management track. I have watched it happen. People stop taking manager jobs they do not want just to get a raise.

And make senior a place people can stay. This is the part of the 1985 data that surprised me most. It still does. Of the 1,495 respondents with a clear preference, 32.6% wanted the management ladder and 21.6% wanted the technical ladder. The largest group by far, 45.8%, wanted neither. They wanted challenging, interesting project work “irrespective of promotion.” Among engineers already sitting on the technical ladder, only about 30% said it was the career they preferred. The dual ladder assumes two kinds of engineers. The data found three.

That third group is most of your best senior engineers. Titles bore them. They need the good problems to go to them, not to whoever is angling for staff. If your ladder quietly implies that staying senior means stalling, you will push people up a track they never wanted, and you will create exactly the consolation-prize staff engineers this whole piece is about. It is the org-level version of the myth I spend a lot of time arguing against, that the best engineers eventually have to stop being technical to keep growing.

When the Ladder Needs an Outside Hire

Sometimes the honest answer to the consolation-prize test is that nobody inside the org has the scope yet. You have a staff-sized problem, a real one, and three good senior engineers who each own a piece of it, none of whom has the standing to tell the other two teams that the schema is changing next quarter whether they like it or not. Promoting one of them into a role with no defined authority is how this whole mess starts. I have made that mistake.

That is when bringing in a staff engineer from outside is the cleaner move, with the decision rights written into the offer so the existing team can see them on day one. The same logic applies on the management side. If the engineer you would have promoted wants to stay technical, hire the engineering manager instead and give your senior engineer the problem, not the consolation title. Searches at this level are nearly always direct hire, and KORE1’s twelve-month retention on placements runs at 92%. That number matters more than usual here, because a staff engineer who leaves in month eight takes the scope document with them.

If the ladder itself needs rebuilding, with levels, rubrics, and the decision map that sits under them, that is org design work. KORE1 does it through its engineering org design advisory practice, and a ladder rebuild sits squarely inside that work.

Settle These Before the Next Calibration Cycle

Is a Staff Engineer Really the Same Level as an Engineering Manager?

On paper, at most companies with a dual ladder, yes. Staff engineer and engineering manager usually share a band and a pay range. In practice they are equal only if the staff role owns decisions the way a manager owns a team.

Check the band, then check the authority. If one of those is missing, the equivalence is a line in a spreadsheet.

How Many Staff Engineers Does a 60-Person Engineering Org Need?

Three to five, in my experience, tied to named cross-team problems rather than a percentage. A 60-person org usually has two or three architecture problems that no single team can own, plus one or two platform or reliability areas that need a senior owner.

If calibration keeps producing more staff engineers than you have problems, the extra titles are rewards. Rewards are allowed. Budget them honestly, or stop handing them out.

Can a Manager Move Back to Staff Without It Reading as a Demotion?

Only if you make it a lateral move with the same band and the same pay, and only if you announce it the way you would announce any other role change.

The move reads as a demotion when it happens quietly, when comp gets “adjusted” a cycle later, or when the new staff role has no scope. It can go well. Every good version I have seen had a scope document ready before the announcement, and a director who talked about it as a good decision, because it was one.

Senior vs Staff, Where Does the Line Actually Sit?

The line is scope, because a senior engineer owns a system inside one team, while a staff engineer is accountable for a cross-team problem and makes calls other teams have to live with.

Technical skill is often similar. I have worked with plenty of senior engineers who were stronger coders than the staff engineer on the next team over. What differs is the blast radius of their decisions and how much of their week goes to problems nobody assigned them.

Do We Even Need a Staff Level Under 30 Engineers?

Usually not, because below about 30 engineers most cross-team problems still fit inside one team or land on a tech lead or the head of engineering. A staff title at that size tends to become a reward with no scope.

Build the level when the first real cross-team problem shows up and needs an owner. Not before, and not because a competitor’s job post said Staff.

Should the Staff Rubric Include Mentoring?

One line of it, measured by whether other engineers ship better work rather than by hours spent in one-on-ones.

Mentoring belongs on every senior ladder. The trouble starts when it becomes the main thing the staff rubric measures, because then the fastest route to staff is doing a manager’s job without the authority. Cap it at a line or two, and make the rest of the rubric about decisions and outcomes.

Give Every Staff Title a Job

The dual ladder is a good idea that most companies implement as a polite no. The fix is not complicated. When I help a company repair one, the list stays short. Each staff engineer gets a written scope with named decisions in it. They sit in the room while plans get made, not after. People cross between tracks without losing face or pay, and senior turns into a career rather than a waiting room.

Then look at your last few staff promotions and ask the question that engineer from the Thursday meeting asked her teammate. Was this a promotion, or was it a consolation prize? If you are not sure, your team is not sure either. They usually know first.

DM me on LinkedIn with your leveling doc and I will name the first of the six checks it fails. I read these for fun, which says something about me. When the fix turns out to be a hire rather than a better process, talk with KORE1 about the staff or management hire before anybody writes the job description.