The jump from mid-level to senior is mostly about getting better at what you already do. Write better code. Design better systems. Handle more complexity. It is a straight line — do more of the same, but harder.
The jump from senior to staff is completely different. It is a right turn. The skills that got you promoted to senior are necessary but wildly insufficient for staff. And the worst part? Nobody tells you what the new skills actually are. You are expected to figure it out, and most people spend years in a frustrating limbo wondering why they are not progressing.
“Being a senior-individual-contributor is not just a way station on the path to management. It is a real job that is critical for companies to do well.” — Charity Majors
The Four Shifts
The senior-to-staff transition comes down to four fundamental shifts. Each one requires you to let go of something that made you successful.
| Dimension | Senior Engineer | Staff Engineer |
|---|
| Scope | Team-level — your team’s codebase, your team’s goals | Org-level — cross-team systems, company-wide direction |
| Output | Code and systems — measured by what you ship | Decisions and alignment — measured by what the org ships |
| Communication | Peers and your manager — technical discussions | Leadership and cross-functional partners — strategy discussions |
| Impact | Features and components — individual contribution | Systems and platforms — organizational contribution |
Scope: Team to Org
As a senior engineer you own your team’s technical quality. You know the codebase, you set patterns, you make sure things are built right. But staff-level scope means seeing how your team’s work fits into the broader system. I once watched a senior engineer build an absolutely beautiful caching layer for their service — perfectly designed, well-tested, great performance. The problem? Three other teams were building their own caching layers at the same time, all slightly different. A staff engineer would have seen the org-level pattern and proposed a shared solution before anyone started building.
Output: Code to Decisions
This is the one that breaks people. Your identity as a senior engineer is built on shipping excellent code. At staff level, your most valuable output is often a single comment on a design doc that redirects a team away from six months of tech debt. No code written. No PR merged. Just the right observation at the right time.
Communication: Peers to Leadership
You need to explain complex technical trade-offs to a VP who has not written code in a decade. You need to translate business strategy into technical direction for your engineering peers. You need to build relationships with staff engineers on other teams to align on shared problems.
Impact: Features to Systems
Staff engineers shape the systems that features are built on. Your work often has no direct user-facing output — and that can feel existential if you are used to pointing at a product and saying “I built that.”
Expanding your scope does not mean abandoning depth. It means developing the peripheral vision to see how your deep expertise connects to problems outside your immediate team.
Demonstrating Staff Work Before Getting the Title
Here is the uncomfortable truth: you generally need to be doing the job before you get the title. Most companies will not promote you to staff on potential — they want evidence you are already operating at that level.
This creates a chicken-and-egg problem. How do you do staff-level work without staff-level scope? The answer is to find the gaps. Every organization has problems that fall between teams, decisions nobody is making, and coordination nobody is doing. That is your opportunity.
In one project, before I had any formal staff scope, I noticed three teams duplicating API client code. Nobody owned the problem because it spanned team boundaries. I wrote a proposal, built a shared package, migrated the most critical consumers, and documented the approach. That was staff-level work — cross-team problem identification, solution design, and execution — done entirely on my own initiative.
Keep a “brag document” that tracks your cross-team impact, decisions you influenced, and systems-level thinking. When promotion time comes, this is infinitely more valuable than a list of PRs you merged.
The Glue Work Trap
There is a category of work that looks like staff-level contribution but is not recognized as such: glue work. Organizing meetings, writing docs nobody reads, onboarding new hires, fixing flaky tests. This work is essential and disproportionately done by people from underrepresented groups.
The trap: glue work is necessary for the org to function, but it is often invisible to promotion committees. You will be praised informally (“we couldn’t do it without you!”) but not promoted formally.
The distinction is intentionality and scope:
| Glue Work | Staff Work |
|---|
| Fixing a flaky test | Designing a testing strategy that eliminates flaky tests org-wide |
| Onboarding one new hire | Creating an onboarding program that reduces ramp-up time across all teams |
| Running a meeting | Chartering a working group with a clear decision-making mandate |
| Writing ad-hoc documentation | Authoring an RFC that sets architectural direction for multiple teams |
If your manager cannot articulate how your current work maps to staff-level expectations, that is a red flag. Either the expectations are not clear, or your work is not aligned with them. Have this conversation explicitly and early.
| Element | What It Looks Like |
|---|
| Pattern of org-level impact | A sustained track record — not one big project — of thinking and operating beyond your team |
| Evidence of technical leadership | RFCs you authored, architectural decisions you drove, design reviews that redirected work |
| Peer recognition | Engineers on other teams citing your influence on their work |
| A sponsor | At least one senior leader who can advocate for you in a room you are not in |
| The right opportunity | A role or project that demands staff-level work and makes the business case for the level |
Common Mistakes
I have seen the same patterns repeatedly from senior engineers reaching for staff:
| Mistake | Why It Happens | What to Do Instead |
|---|
| Going deeper instead of broader | Depth is your comfort zone | Deliberately seek cross-team problems |
| Waiting for permission | Senior work is assigned; staff work is found | Identify gaps and propose solutions proactively |
| Solving everything yourself | You are fast and capable | Solve through others — teach, delegate, enable |
| Ignoring organizational dynamics | ”Politics” feels dirty | Learn how decisions get made and work within that system |
| Neglecting writing | You would rather code | Treat writing as a core deliverable, not overhead |
| Optimizing for being right | Technical correctness feels safe | Optimize for being effective — the right answer nobody adopts is worthless |
The Mindset Shift
The deepest change is not a skill — it is a mindset. You have to stop measuring your value by what you personally produce and start measuring it by what you enable. That means some days you will feel like you accomplished nothing because you did not write any code, even though you unblocked three teams and prevented a bad architectural decision.
If you are a senior engineer reading this and feeling like the gap is enormous — it is. But it is also crossable. Start expanding your scope intentionally, start writing more, start looking for problems between teams, and start measuring yourself by your multiplier effect. The gap will close faster than you think.