5 Steps to Go from Senior to Staff Without Managing People
Staff isn't a better Senior. It's a different job. Here's how to grow into it while staying an engineer.
Dallas, USA A place I’ve called home
For a lot of engineers, “senior” feels like the end of the map. Up to that point, the path is clear: write better code, own bigger features, get promoted. After it, the signposts disappear, and the most common advice is “have you thought about management?”
Management is a great path for some people. But it isn’t the only way to grow, and it shouldn’t be the default just because nobody explained the other one. The staff+ track exists for engineers who want to keep their hands in the technical work while widening their impact.
What I find most useful is a line from Will Larson’s Staff Engineer: “A Staff engineer isn’t a better Senior engineer, but someone who’s moved into fulfilling one of the Staff archetypes.” That reframing changes everything that follows. Here are five steps built on it.
Step 1: Pick the kind of staff engineer you want to be
Why it matters. Larson interviewed many staff+ engineers and found their work clustered into four archetypes. The Tech Lead guides the approach and execution of a team. The Architect owns the direction and quality of a critical technical area. The Solver digs into hard, high-risk problems until they’re resolved. The Right Hand extends an executive’s attention across a large organization. He also notes that companies tend to need roughly one Tech Lead for every eight engineers, which makes it the most common way in, while Architect and Right Hand roles usually only appear in much larger organizations.
How to apply it. Look at what your company actually needs and what energizes you. If you love depth, the Solver may fit. If you love shaping a team’s direction, try Tech Lead. Then tell your manager which one you’re aiming for, so you’re working toward a specific role, not a vague “next level.”
Example. An engineer who always ends up fixing the scariest production issues might aim for the Solver archetype, and ask to be pointed at the next problem leadership is worried about.
Step 2: Widen your scope from your team to the organization
Why it matters. In a June 2025 LeadDev article, staff engineer James Socol describes the shift: at staff level, you look for ways to scale your impact beyond your team to a much larger part of the organization. He suggests starting with work that’s collectively time-consuming across teams, like two teams building similar features differently, or engineers repeating the same manual checklist every week.
How to apply it. Spend time outside your team. Talk to engineers on neighboring teams, other staff engineers and managers. Keep a running list of patterns you see repeated, then pick one that would save the most time across teams if it were solved once.
Example. If three teams each maintain their own deployment script with the same manual steps, one shared, automated deploy path saves all three teams time every week. That kind of fix is invisible on one team and obvious across the organization.
Step 3: Do the glue work on purpose, and make it visible
Why it matters. In her talk “Being Glue,” Tanya Reilly describes glue work as the less visible work that makes projects succeed: onboarding new people, reviewing designs, noticing what got dropped, and keeping teams pointed in the same direction. She argues it is real technical leadership, but warns that, left unmanaged, it can be career-limiting, because promotion processes often don’t count it. LeadDev reported in 2025 that as some companies cut middle-management layers, more of this coordination work is landing on senior and staff engineers, and some are burning out as “accidental managers.”
How to apply it. Choose the glue work that matters most and say out loud that you’re doing it. Keep artifacts: design reviews, decision notes, plans that changed a project’s direction. And keep enough technical work on your plate that your engineering skills keep growing.
Example. An engineer notices two teams heading toward incompatible designs, sets up one meeting, and writes a one-page decision note. Saving that note, and linking it to the outcome, turns invisible coordination into visible impact.
Step 4: Write things down so your thinking scales
Why it matters. At staff level, your ideas have to reach people you’ll never meet in a meeting. Reilly’s book The Staff Engineer’s Path is organized around three pillars: big-picture thinking, project execution, and leveling up the people around you. Writing serves all three. A design doc or a short strategy note lets your reasoning travel, get challenged, and outlast the conversation where it started.
How to apply it. For any decision that affects more than your team, write a short document: the problem, the options you considered, what you recommend and why. Share it early, invite disagreement, and update it as you learn.
Example. Instead of arguing for a new caching approach in three separate meetings, an engineer writes a two-page proposal comparing it with two alternatives. Reviewers comment asynchronously, and the final decision is recorded for whoever joins next year.
Step 5: Build your case and find a sponsor
Why it matters. Larson notes that many companies treat Senior as a “career level,” where there’s no expectation you’ll ever move up, and promotion systems can start to feel like gatekeeping. In his survey, about two-thirds of staff engineers got the title through promotion at their current company and the remaining third changed companies. He recommends a promotion packet as the foundation, and says that without leadership knowing who you are, the promotion won’t happen.
How to apply it. Write your own draft promotion case now, using your company’s staff-level expectations as headings. Fill it with evidence. Where it’s thin, that’s your plan for the next six months. Then share it with your manager and find a senior sponsor who will speak for your work in rooms you’re not in.
Example. An engineer drafts a one-page case against the staff criteria and finds strong evidence for technical depth, but little for cross-team impact. That gap becomes the focus: lead one cross-team effort this half and document the result.
The move from senior to staff isn’t about doing more of the same, faster. It’s about choosing a kind of leadership that doesn’t require managing people, and then doing it deliberately: wider scope, visible glue, clear writing and a case others can see.
You don’t have to give up being an engineer to grow. You just have to change what “engineering” includes.
Which staff archetype fits the way you like to work?