She got promoted to Staff, spent 18 months in crisis, and left for a Senior role. The staff engineer trap is real — here's how to avoid it.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
I watched one of the best engineers I've ever worked with get promoted to Staff, spend 18 months in existential crisis, and quietly leave for a Senior role at a smaller company — for less money. She told me, "I got promoted out of the thing I was good at." Nobody warned her. Nobody warns anyone.
The staff engineer role is the most prestigious and least understood position in software engineering. It pays $450K+ at top companies. It carries enormous scope. And it makes a surprising number of talented engineers deeply unhappy — because the job they trained for and the job they got are almost entirely different things.
This is the article I wish someone had written before I watched smart people walk into that trap.
Let's start with the compensation, because that's what makes the trap so sticky.
At FAANG-tier companies, Staff engineers earn $500K-$700K in total compensation. LinkedIn's median Staff comp is $450,700. Principal Staff at LinkedIn clears $1.13 million. Even at mid-tier companies, Staff roles typically pay $250K-$400K total.
The premium for AI specialization is growing: at Staff level, AI-focused engineers earn 18.7% more than generalists, up from 15.8% the prior year.
Now here's the paradox: these numbers represent a massive pay increase over Senior Engineer (typically 30-50% more total comp), but the job satisfaction often decreases. The engineers who reach Staff are the ones who were exceptional at the Senior level — shipping code, solving hard technical problems, building systems. The Staff role is about almost none of those things.
The career ladder looks clean on paper:
| Level | Typical YoE | Scope | What You Actually Do |
|---|---|---|---|
| Senior | 5-8 years | Team | Ship features, mentor juniors, own systems |
| Staff | 8-12 years | Multi-team | Set technical direction, write docs, attend meetings |
| Principal | 12-15+ years | Org-wide | Define strategy, influence executives, write more docs |
| Distinguished | 15-20+ years | Company/Industry | Shape industry direction, rarely write code |
Notice the pattern? As you go up, the coding decreases and the ambiguity increases. That's the trap. Only 30% of companies even have clear IC advancement paths beyond senior level. For the other 70%, "Staff Engineer" is a vague title attached to whatever the organization needs from its most senior IC — whether or not that matches what the engineer wants to do.
Will Larson's research at StaffEng.com identified four archetypes that staff engineers fall into:
Tech Lead — Guides the execution of a single team. Partners closely with one or two engineering managers. This is the archetype closest to "normal engineering" and the one most staff engineers want.
Architect — Sets the direction, quality, and approach for a critical technical area. Thinks in multi-year horizons. Writes RFCs and design documents. Reviews other people's designs. Rarely writes production code.
Solver — Parachutes into the hardest problems across the organization. Fixes the thing nobody else can fix, then moves on. This sounds glamorous. In practice, it means never owning anything and constantly context-switching between unfamiliar codebases.
Right Hand — Extends the authority and bandwidth of an executive. Operates at the VP level but without the VP title or direct reports. This archetype only exists at companies with many hundreds or thousands of engineers.
Here's the breakdown of how time typically gets spent:
| Activity | Senior Engineer | Staff Engineer |
|---|---|---|
| Writing code | 60-80% | 20-40% |
| Code review | 10-15% | 15-25% |
| Design docs & RFCs | 5-10% | 20-30% |
| Meetings | 10-20% | 25-40% |
| Mentoring | 5-10% | 10-20% |
| Strategy & planning | 0-5% | 15-25% |
Staff engineers consider 20-40% coding time (1-2 days per week) as ideal. But many find themselves coding far less. And the coding they do is different — proofs of concept, not production features. Investigation spikes, not implementations. The code they write is throwaway; the document they write about it is the deliverable.
As one staff engineer put it: "Writing code is rarely the highest leverage thing you can spend your time on." That sentence is factually correct and emotionally devastating for someone who became an engineer because they love writing code.
You spent 8-12 years becoming an exceptional coder. Your identity — your self-worth, your professional confidence, your flow state — was built on writing software. Now you're in a role where the primary output is Google Docs, Slack messages, and conference room conversations.
The feedback cycle changes too. Staff work operates on longer timeframes — weeks, months, years instead of the quick feedback loop of shipping code. You might spend three months building organizational consensus for an architecture change. The emotional reward of git push is replaced by... a meeting where people nod.
This isn't just uncomfortable. It triggers a genuine identity crisis. You were promoted because you were great at X. Now you're expected to do Y. And Y doesn't feel like engineering.
Staff Engineers must influence without authority. You can set technical direction, but you can't tell anyone what to do. You write the design doc recommending a migration to gRPC, but the team lead decides to stick with REST. You identify that the deployment pipeline is the biggest bottleneck, but the platform team has other priorities.
You have responsibility without power. You're accountable for technical outcomes across teams you don't manage. If the architecture goes wrong, people look at you. If the team ignores your recommendation and it works out fine, nobody remembers your input. If they ignore it and things break, everyone asks why you didn't push harder.
This is the management track's most thankless quality, transplanted into an IC role. Except managers at least have the authority to make staffing decisions and set priorities. You have... persuasion.
There's a category of work that every organization needs but nobody gets promoted for: facilitating cross-team communication, documenting tribal knowledge, onboarding new engineers, running retrospectives, coordinating incident responses, writing the migration guide.
This is called "glue work," and staff engineers do a lot of it. The impact might come from mentoring junior engineers, fixing problems that waste 15 minutes of every engineer's day, or preventing rework by spotting issues before implementation.
The trap: glue work is essential but invisible. It doesn't show up in performance reviews as a shipped feature or a resolved outage. It shows up as "things went smoothly" — which is indistinguishable from "nothing happened." If you spend 60% of your time on glue work, your promotion packet looks thin. If you don't do it, the teams you're supposed to support fall apart.
The expectations of the staff engineer job vary wildly across companies. At Google, Staff (L6) has a relatively well-defined set of expectations. At a 200-person startup, "Staff Engineer" might mean "the person who's been here the longest and knows where the bodies are buried."
Staff engineers across many companies weren't quite sure what was expected of them, which is a source of stress. Are you supposed to write code? Set strategy? Mentor? All three? In what proportion?
Without clarity, you're left to define the role yourself — which sounds empowering but is actually exhausting. Every quarter, you're building a case for why what you did mattered, because there's no shared understanding of what you should have been doing.
This is the trap that keeps people stuck in the other four traps: the money.
At $450K-$700K total comp, stepping down to Senior (or leaving for a smaller company where the title means something different) could mean a $150K-$300K pay cut. You've adjusted your lifestyle — mortgage, childcare, savings rate — to the Staff salary. Walking away feels financially irresponsible.
So you stay. You attend the meetings. You write the docs. You wonder why you feel less fulfilled at $500K than you did at $250K. And you can't explain that to anyone without sounding ungrateful.
I don't want to be entirely cynical. The staff engineer role works beautifully when three conditions are met:
1. The company has a clear framework. Companies like Google, Meta, Stripe, and Dropbox have well-defined expectations for each IC level. You know what Staff means, what's expected, and how you'll be evaluated. Dropbox published their career framework publicly, including specific behaviors for each archetype.
2. You actually want to do the work. Some engineers genuinely prefer design docs to pull requests. They get energy from aligning teams, setting multi-year technical vision, and solving organizational problems. If that's you, Staff is not a trap — it's a destination.
3. You have the right archetype match. If you're a Solver who gets dropped into a Tech Lead role, you'll be miserable. If you're a natural Architect forced into Right Hand duties, you'll quit. The archetype has to match your strengths and interests. Most companies emphasize one or two archetypes, so you need to know which ones before you accept the role.
When all three conditions are met, Staff engineers have enormous impact. They prevent multi-million-dollar architectural mistakes. They unblock entire organizations. They make 50 engineers more productive, which is worth far more than any individual contribution.
But when even one condition is missing, the trap opens.
Before pursuing (or accepting) a Staff promotion, ask yourself these questions:
Do I know what the role means at this specific company? Ask the hiring manager or your skip-level for concrete examples. "What did the last staff engineer on this team actually deliver in the last six months?" If they can't answer clearly, that's a red flag.
How much of my identity is tied to writing code? Be honest. If your happiest work days are the ones where you're heads-down in your IDE for six hours, Staff will take that away. You'll code maybe two days a week, and even those days will be interrupted by "quick syncs."
Am I comfortable with ambiguous impact? Staff impact is measured in quarters and years, not sprints. If you need the dopamine hit of shipping features regularly, you'll feel adrift. The work matters — it just doesn't feel like it matters in the moment.
Can I influence without authority? This is a genuine skill, and not everyone has it. Some brilliant engineers are terrible at persuading peers. If your natural mode is "I see the right answer, let me implement it," Staff will frustrate you deeply because the right answer needs to be adopted, not just coded.
Would I take this role at a 20% pay cut? If the answer is no, the compensation is the reason — not the role itself. That's fine for a while, but it's not sustainable for a career.
Engineering managers and staff engineers sit at roughly the same level on most career ladders. But the jobs are profoundly different in ways that should inform your choice:
| Dimension | Staff Engineer | Engineering Manager |
|---|---|---|
| Authority | None (influence only) | Direct (hire/fire, assign work) |
| Feedback cycle | Months to years | Weeks (1:1s, retros, sprints) |
| Output | Documents, designs, reviews | Team outcomes, delivery |
| Coding time | 20-40% | 0-15% |
| Career risk | Role undefined at many companies | Role well-understood everywhere |
| Compensation | Often higher at top companies | More consistent across companies |
| Satisfaction driver | Technical impact | People impact |
| Worst day | Three meetings and no code | Firing someone |
Here's the thing nobody says: engineering management is a better-defined role. There are hundreds of books, thousands of courses, and a century of management theory to draw from. The EM knows they'll do 1:1s, run sprints, handle performance reviews, and advocate for their team. It's hard work, but it's clear work.
Staff engineering is a younger, less codified discipline. Will Larson's book was published in 2021. StaffEng.com launched in 2020. Before that, most staff engineers had no roadmap at all — just a title and a vague mandate to "have more impact."
The irony: many staff engineers end up doing management work without the management title. They facilitate. They align. They resolve conflicts. They onboard. They do everything a manager does except hire, fire, and run 1:1s — and they don't get the management training or organizational support that comes with the EM role.
If you find yourself doing 60% management work as a staff engineer, you might actually be happier as an engineering manager. At least then the expectations would match the work.
There are alternatives to the traditional staff track that more engineers should consider:
The Senior-Forever Path. Some companies (notably Shopify and GitLab) have created well-compensated Senior roles with no expectation of moving to Staff. You stay technical, ship code, mentor juniors, and earn competitive compensation. The ceiling is lower, but the work is more aligned with what most engineers actually enjoy.
The Founding Engineer Path. Join an early-stage startup as engineer #1-5. You'll have Staff-level scope (or broader) with Senior-level coding time. The comp is lower initially, but the equity upside can be enormous, and you get to build the thing instead of writing documents about how the thing should be built.
The IC-to-Management Pendulum. You don't have to pick one track forever. Some of the best engineering leaders I know alternate: 3-4 years as an IC, then 2-3 years as a manager, then back to IC. Each stint makes you better at the other. The management experience makes you a better staff engineer because you understand organizational dynamics. The IC stints keep your technical skills sharp.
The Niche Expert Path. Become the world expert in a specific domain — database internals, compiler optimization, distributed consensus, ML infrastructure. Companies will pay Staff-level compensation for domain expertise without the ambiguous "technical leadership" expectations. You write code, publish papers, give conference talks, and solve the hardest problems in your niche.
The Staff-at-a-Smaller-Company Path. "Staff Engineer" at a 50-person company is a completely different role than Staff at Google. At smaller companies, staff engineers often retain 50-60% coding time because there's nobody else to do the work. The scope is narrower but the hands-on ratio is much higher.
If you're a Senior considering the leap, here's what I wish someone had told me:
The promotion criteria and the job are different things. Getting promoted to Staff usually requires a big technical project with multi-team impact. Being Staff requires sustained influence, organizational navigation, and documentation. The thing that gets you promoted is not the thing you'll spend your time doing.
Your manager's support isn't enough. Staff promotions typically require a "promo packet" reviewed by a committee of senior leaders. Your manager sponsors it, but the committee decides. You need visibility across the organization — which means your work needs to be legible to people who've never worked with you.
The first six months will feel like imposter syndrome. Even the most qualified new staff engineers feel lost. The feedback loops are longer, the expectations are vaguer, and the work product (documents, alignment, strategy) feels less tangible than code. This passes, but it's disorienting.
You'll need to market your own impact. As a Senior, your tech lead or manager tracks your output and advocates for you. As a Staff, you're expected to make your impact visible yourself. If you don't write the quarterly summary, attend the leadership forum, and present your work — nobody will know what you did.
Read the book. Will Larson's Staff Engineer: Leadership beyond the management track is the definitive resource. Read it before you decide, not after you're promoted.
The staff engineer role, as it exists at most companies in 2026, is poorly designed. It takes the best coders in the organization and asks them to stop coding. It gives them responsibility without authority. It rewards ambiguous, long-term work but evaluates on short-term performance cycles. And it locks them in with compensation that's hard to walk away from.
The problem isn't the concept — organizations genuinely need experienced ICs who set technical direction. The problem is the implementation. Most companies haven't done the work to define what Staff means, how it's evaluated, or how success is measured. They created a level on the career ladder because engineers demanded growth beyond Senior, then left the role undefined and hoped the smart people would figure it out.
Some do. The best staff engineers I've known genuinely thrive. They love the strategic work. They're energized by influence over implementation. They find purpose in making an organization better rather than making a feature ship. But they're the minority — maybe 30-40% of people who hold the title.
The rest are in the trap. They're highly compensated, broadly frustrated, and quietly wondering if they made the wrong choice. They won't say it publicly because admitting you're unhappy at $500K invites zero sympathy. But in private conversations, over drinks at conferences, in anonymous Blind posts — the complaints are remarkably consistent: "I don't feel like an engineer anymore."
My advice: don't treat Staff as the natural next step after Senior. Treat it as a career change. Because that's what it is. The skill set, the daily work, the feedback loops, the definition of success — all of it changes. Some people want that change. More people than you'd think don't.
Know which one you are before you raise your hand. The golden handcuffs are real, and they're very, very comfortable.
Sources: Levels.fyi End of Year Pay Report 2025, Levels.fyi LinkedIn Staff Engineer Salary, Levels.fyi LinkedIn Principal Staff Engineer Salary, Levels.fyi AI Engineer Compensation Trends Q3 2025, StaffEng — What Do Staff Engineers Actually Do, StaffEng — Staff Archetypes, StaffEng — Staying Aligned with Authority, Will Larson — Staff Engineer Archetypes, LeadDev — To Code or Not to Code for Staff Engineers, LeadDev — How to Get the Most Out of Staff Engineers, Graham Gilbert — Path to Staff Engineer, Dropbox Career Framework, Hakia — IC vs Management Career Path 2026, Denis Zhbankov — IC vs Manager Career Ladder, Pragmatic Engineer — What is Staff Engineer, Pragmatic Engineer — Staff Engineer's Path, MEV — Software Engineer Career Path.