From Senior to Staff: What Nobody Tells You

I’ve been operating at staff level for the past couple of years — first under the Lead Frontend Engineer title, then officially as Staff Engineer. I remember the first week at that level vividly. Not because of any grand revelation, but because of how disoriented I felt. I’d spent years getting really good at a certain set of things, and suddenly those things weren’t the point anymore.

If you’re approaching this transition, or you’re early in it and wondering why everything feels different, I want to share what I wish someone had told me.

It’s not “Senior but more”

This is the biggest misconception, and it’s the one that tripped me up the hardest. I assumed Staff meant doing Senior-level work at a larger scale: bigger systems, harder bugs, more complex architectures. And while that’s partially true, it misses the real shift entirely.

At Senior, your job is to solve problems. At Staff, your job is to make sure the right problems get solved. That sounds subtle, but it changes everything about how you spend your time. You go from asking “how do I build this?” to asking “should we build this at all?” and “what will the second-order effects be across the organisation?”

The first few months, I kept gravitating back to deep technical work because it was comfortable. It felt productive. But the most impactful thing I could do on any given day was often a 30-minute conversation, not a pull request.

The skills that got you here won’t get you there

This one stings. You got to Senior by being technically excellent. You wrote clean, performant code. You debugged things others couldn’t. You shipped reliably. Those skills are table stakes now — they’re assumed, not rewarded.

What gets rewarded at Staff is different: written communication, building alignment across teams, navigating ambiguity, knowing when to push back on leadership and when to commit even if you disagree. I had to develop muscles I’d never seriously exercised. Writing design documents that persuade, not just inform. Running meetings that actually produce decisions. Giving feedback to people who don’t report to me.

None of this was in the job description at Senior. It felt like starting over in some ways.

Influence without authority

Nobody tells you how much of this role is persuasion. You don’t manage people. You don’t control roadmaps. But you’re expected to shape technical direction across teams you don’t belong to.

The only tool you have is trust, and trust is built slowly. You earn it by being right often enough, by listening before prescribing, and by actually caring about other teams’ constraints rather than just pushing your own agenda. I got this wrong early on. I’d show up to cross-team discussions with a strong opinion and a detailed proposal, thinking I was being helpful. What I was actually doing was making people feel steamrolled.

The approach that works is slower and less satisfying to the ego: ask questions, understand context, offer options instead of answers. Let other people arrive at good conclusions with your gentle nudging rather than your forceful direction. It takes patience I didn’t naturally have.

The loneliness is real

At Senior, you’re part of a team. You have peers at your level. You pair program, you share the struggle, you celebrate together. At Staff, the dynamic shifts. There are fewer people at your level. You’re often the most senior technical person in the room, which means people filter what they say to you. They’re less likely to challenge you, and more likely to just agree.

That sounds nice until you realise how dangerous it is. You need pushback to make good decisions, and you have to actively create the conditions for it. I started explicitly asking people to poke holes in my ideas. I sought out the junior engineer who looked sceptical but wasn’t speaking up. I learned to say “I’m not sure about this” more often, because it gave others permission to disagree.

There’s also the ambiguity. At Senior, the problems are usually well-scoped. At Staff, you’re often working on things where nobody has the answer, and part of your job is figuring out what the question even is. That kind of open-endedness can be isolating if you’re used to the satisfaction of closing tickets.

Saying no to interesting problems

This was the hardest personal adjustment. I love solving hard technical problems. It’s why I became an engineer. But at Staff, some of the most important work is deliberately not doing the thing you’re most excited about.

That gnarly distributed systems issue? It’s fascinating, and you could probably solve it faster than anyone. But if a Senior on the team can solve it in twice the time and grow from the experience, that’s the better outcome for the organisation. Your job is to make sure they have what they need, not to take the keyboard.

I still struggle with this. There are days where I want nothing more than to disappear into a codebase for eight hours and emerge with an elegant solution. Sometimes I do — Staff doesn’t mean you never write code. But I’ve had to accept that my highest-leverage work often doesn’t look like engineering at all.

The impostor syndrome never fully goes away

I thought getting the title would quiet the voice that says “you don’t belong here.” It didn’t. If anything, it got louder for a while. The scope of what you’re supposed to know about expands dramatically, and there’s always someone in the room who knows more about any given topic.

What did help was accepting that being Staff doesn’t mean being the expert on everything. It means being good at synthesising across domains, connecting dots that others can’t see because they’re deeper in a single area. Your value isn’t in knowing the most. It’s in understanding the system as a whole.

I also learned to be honest about what I don’t know. Saying “I haven’t thought about that deeply enough to have an opinion” is one of the most powerful things a Staff engineer can say. It builds trust, and it models the intellectual honesty you want in your engineering culture.

Why it’s worth it

After all of that, you might wonder why anyone would want this job. One word: leverage.

When you’re a Senior writing great code, you make one project better. When you’re a Staff engineer operating well, you make entire teams better. You shape the technical culture. You prevent the bad architectural decisions before they get built. You create the conditions where other engineers do the best work of their careers.

There’s a particular satisfaction in watching a Senior engineer you’ve been mentoring nail a system design that you helped them think through. Or seeing two teams collaborate smoothly because you spent weeks quietly building the bridges between them. Or knowing that a company-wide technical decision went well because you asked the right uncomfortable question in the right meeting.

It’s less visible than shipping code. The feedback loops are longer. But the impact is deeper.

If you’re on this path, the disorientation is normal. I wrote more about what the day-to-day actually looks like once you’re past the initial shock. It does get easier. Not comfortable, exactly, but easier.