What Staff Engineers Actually Do Differently (That Senior Engineers Don't See)

What Staff Engineers Actually Do Differently (That Senior Engineers Don’t See)

Most senior engineers who are stuck think the gap is technical. They assume staff engineers know more, code faster, or have solved harder problems. So they go deeper on their current stack, take on harder projects, and wait.

They wait for years.

The gap isn’t technical. It’s behavioral. And the behaviors that define staff-level work are largely invisible from the senior engineer seat - not because they’re secret, but because you can’t see what you’re not doing yet.

I spent 12 years at Facebook. I sat in meetings where we calibrated engineers across levels. I sat in the rooms where promotion decisions got made. The senior engineers who made staff weren’t the ones who wrote the cleverest code. They were the ones who had already started operating at the next level before anyone officially asked them to.

Here’s what that actually looks like.

They Solve Problems Nobody Assigned Them

Senior engineers are good at execution. You give them a problem, they solve it well. That’s genuinely valuable - and it’s not staff.

Staff engineers notice problems that haven’t been named yet. They see the friction in a process, the architectural decision that’s going to cost six teams six months in two years, the oncall pattern that’s quietly degrading reliability - and they do something about it without waiting for a ticket, a project, or permission.

At Facebook, I watched this distinction play out constantly in calibration discussions. A senior engineer might deliver everything on their roadmap perfectly. A staff engineer who delivered slightly less would get promoted because they’d also quietly fixed the deployment pipeline that was blocking three other teams, written the RFC that resolved a year-long architectural disagreement, and caught the database migration that would have caused an outage before it shipped.

No one asked them to do any of that. They did it because they saw it needed doing.

This isn’t about working longer hours. It’s about a different definition of your job. Senior engineers think their job is their assigned work. Staff engineers think their job is making the system work better - and their assigned work is just part of that.

Their Unit of Concern Is the System, Not the Feature

Senior engineers care deeply about their service. They know its code, its failure modes, its technical debt. They advocate for it.

Staff engineers care about the system - the whole thing. Their own service is just one node in a graph they’re thinking about.

This shows up in code reviews, design discussions, and incident retrospectives. A senior engineer reviewing a PR is asking: is this correct, is this well-written, does it match our patterns? A staff engineer is also asking: how does this interact with the downstream consumer? What happens at 10x load? What assumption does this bake in that we’ll regret?

When I was building the EU SRE presence at Facebook, the senior engineers I managed were focused on getting their services to pager-acceptable reliability. The engineers who grew into staff roles were the ones asking questions about cross-region consistency, about how our operational patterns would need to differ from the US, about which of our US playbooks were actually solving EU-specific problems and which were just copied because they were familiar.

They were thinking about the system before the system existed yet. That’s a different cognitive mode.

They Write Things That Outlast Them

Staff engineers write things down. Not because they’re told to. Because they understand that their knowledge has no organizational value if it only lives in their head.

Design docs. Postmortems that actually explain the contributing factors rather than just listing action items. Internal guides that become the reference engineers point to three years later. Decision logs that explain not just what was decided but why, so the team doesn’t relitigate the same debate six months from now.

Senior engineers often resist this. Writing takes time, the situation will change anyway, verbal is faster. All true. And none of it changes the fact that institutional knowledge that isn’t written down disappears when people move teams, take PTO, or leave the company.

At Facebook, the engineers whose impact was clearest at promotion time were almost always the ones with a document trail. When calibrators asked “what did this person actually do this year?”, their managers could point to artifacts - docs that shaped decisions, postmortems that changed processes, design proposals that other teams adopted. The engineers who relied on “trust me, they did a lot” had a harder time.

Write things down. Make your thinking legible. It’s not bureaucracy - it’s how your work compounds.

They Say No to Work That Doesn’t Matter

Senior engineers say yes to everything. They want to be helpful. They want to demonstrate capacity. They take on every request that comes in because turning things down feels like letting people down.

Staff engineers have learned that saying yes to the wrong work is how you fail at the right work.

This is genuinely hard to learn. When you’re junior or mid-level, saying yes is how you build trust. Yes accumulates goodwill. No feels risky. By the time you’re senior, the habit is deeply ingrained - and it starts working against you.

Staff-level scope is too large to execute everything that comes at you. If you try, you become a bottleneck, your most important work gets diluted, and you burn out without accomplishing what actually mattered. The judgment about what to work on - and what to explicitly not work on - is a core part of the job.

I’ve seen senior engineers turn down the staff promotion they’d been chasing for years because they couldn’t bring themselves to stop attending every meeting, stop picking up every small bug that crossed their path, stop helping every engineer who asked. They wanted staff-level impact but couldn’t let go of senior-level habits.

Saying no isn’t a personality trait. It’s a skill. And it’s one that staff engineers practice deliberately.

They Make Other Engineers Better

This one gets talked about in every staff engineering write-up, so I’ll skip the vague version and give you the specific version.

Making other engineers better doesn’t mean being a good mentor. It doesn’t mean being nice in code reviews. It means changing how other engineers approach their work in a durable way.

What does that look like in practice? The engineer who writes the code review comment that makes the junior engineer think differently about a whole class of problems - not just this PR. The engineer whose design docs become the template the team uses because they’re so clear. The engineer who runs the postmortem so thoroughly that the team’s incident investigation process genuinely improves. The engineer who asks the question in the design review that everyone else was thinking but didn’t ask, which makes every future design review slightly better.

Multiplier effect is the right framing. Staff engineers aren’t trying to do more work - they’re trying to increase the output of the people around them. An engineer who makes five other engineers 20% more effective has more organizational impact than any amount of individual execution.

At Meta, this showed up in calibration as: “when this engineer is in the room, the room produces better outcomes.” That’s not about technical knowledge. It’s about how they engage.

They Operate in Ambiguity Without Asking for Permission

Senior engineers need a clear problem statement. Give them one and they’ll execute excellently. Ask them to figure out what problem to solve and they’ll come back asking clarifying questions until there’s effectively a clear problem statement anyway.

Staff engineers take ambiguous situations and make them concrete. They define the problem. They identify the constraints. They propose an approach, get the right feedback, and move.

This is the behavior that most senior engineers find hardest to develop, because ambiguity feels like a defect - something to resolve before starting real work. But at staff level, ambiguity is the starting condition. The ability to work productively in it isn’t just nice to have. It’s the job.

I’ve seen this in incident response, in organizational changes, in new product launches, in anything where the situation is genuinely unclear. Senior engineers wait for clarity. Staff engineers generate it.

At Meta, the engineers who performed best in chaos - datacenter emergencies, major architectural transitions, reorgs - weren’t necessarily the most technically skilled. They were the ones who could say “here’s my read of the situation, here’s what I think we should do, here’s what I need from each of you” and get people moving. In ambiguous situations, action beats analysis. Staff engineers know this.

The Common Thread

All six behaviors share something: they require acting on your own judgment before you have external validation.

Senior engineers wait to be recognized at staff level before behaving like staff engineers. Staff engineers start behaving like staff engineers and get recognized as a result.

You can’t get promoted into this mindset. You have to develop it first. That’s the transition most senior engineers don’t see - not because it’s hidden, but because it requires operating differently before you have permission to, and that feels uncomfortable until it doesn’t.

The engineers I’ve watched make this transition successfully didn’t do it by working harder. They did it by working differently - widening their scope, writing more, saying no more deliberately, and starting to think about the system they were part of rather than just the feature they owned.

That’s the real gap. And it’s closeable.

If you’re building toward Staff and want someone who’s been in those calibration rooms to look at your specific situation, book a consultation. I coach senior engineers through exactly this transition - the scope shifts, the visibility work, the behaviors that actually move the needle in calibration.

If you’d rather start with a self-guided approach, the SWE Interview System covers how to demonstrate these behaviors in the interview room - not just technical answers, but the reasoning and judgment that calibrators are actually evaluating.