What 'Operating at the Next Level' Actually Means (Before You Have the Title)

Most engineers waiting for a promotion are solving the wrong problem.

They’re asking: “What do I need to do to get promoted to Staff?” When the question that actually matters is: “Am I already operating like a Staff engineer, and does anyone know it?”

Those are different questions. The first is about credentials. The second is about behavior.

I spent 12 years at Facebook, and I watched this play out hundreds of times. Engineers who got promoted to Staff weren’t the ones who finally crossed some finish line. They were the ones who had already been doing Staff-level work - visibly, consistently, and in ways that mattered to the organization. The title came after. Sometimes well after.

The phrase “operating at the next level” gets thrown around in performance reviews like it means something obvious. It doesn’t. So let me tell you what it actually looks like.

You’re solving problems your manager didn’t bring you

At the senior level, you execute well on what’s in front of you. You take a ticket, you understand it deeply, you ship it. Maybe you spot edge cases the PM missed or push back on a bad technical direction. That’s good. That’s table stakes for senior.

Staff-level operating looks different. You’re noticing problems nobody assigned to you. Not because you’re going rogue, but because you’ve developed a wider lens on the system - the architecture, the team, the product - and you see failure modes before they become incidents.

At Facebook, I watched one engineer notice that two different teams were independently building nearly identical internal tooling. Neither team knew about the other. He didn’t wait for someone to ask him to fix it. He mapped the overlap, brought both teams together, and facilitated a decision about which approach to consolidate around. That work wasn’t on his roadmap. It probably cost him a few weeks of his “real” work. But it saved the organization months and made both teams more effective.

That’s what operating at the next level looks like: your unit of concern is larger than your own work.

Your decisions survive scrutiny you weren’t present for

Here’s a subtle one. When a senior engineer makes a technical decision, it usually happens in a meeting where they can explain it. The decision and the reasoning travel together.

When a Staff engineer makes a decision, the reasoning needs to survive without them. Their documents get read by people who weren’t in the room. Their architectural choices get implemented by engineers who joined the team six months later. Their API designs get extended by teams in other time zones.

This means the quality of your written communication - not your code, your writing - becomes a leading indicator of whether you’re operating at the next level. Not because writing is intrinsically important, but because durable decisions require durable reasoning.

If you’re not writing things down - actual documents, not Slack threads - you’re operating at a level where you’re still required to be in the room. Staff engineers create leverage by making themselves partially unnecessary.

You’re calibrating other engineers, not just helping them

There’s a difference between being helpful and being calibrating.

Being helpful means answering someone’s question well. A senior engineer does this constantly. They’re a good resource. People ask them things and they give good answers.

Being calibrating means changing how someone thinks, not just what they know today. You’re not just solving their problem - you’re adjusting the model they’ll use to solve the next five problems themselves.

This shows up in code review. Most code review is correctional: “This has a bug,” “This won’t scale,” “Use a different pattern here.” Calibrating code review is different: “Notice that you’ve made the same trade-off three times this week, each time favoring latency over consistency. Is that intentional? Here’s what breaks if we hold that policy across the whole service.”

That second kind of feedback raises the floor of the whole team. It’s harder to write. It takes more thought. But it’s the kind of influence that scales.

If you’re doing a lot of the first kind and none of the second, you’re being a good senior engineer. You’re not yet operating like Staff.

You’ve changed your risk profile

Senior engineers are often rewarded for being right. They propose something, it works, they get credit. This creates a reasonable incentive to propose things you’re confident about.

Staff engineers need a different relationship with uncertainty. The problems worth working on at that level are often the ones where the answer isn’t obvious. If the answer were obvious, someone more junior would already be working on it.

Operating at the next level means taking on problems where you might be wrong - and having a process for finding out quickly. It means being willing to write the document that says “I’m not sure, but here’s my best current thinking, and here’s how we’d know in three months if I’m right.” It means advocating for an approach in the face of skepticism, running the experiment, and updating publicly when the data comes in.

This is uncomfortable for engineers who’ve been trained to be confident. But at the Staff level, intellectual honesty about uncertainty is a form of strength, not a weakness.

The visibility problem

Here’s the uncomfortable part. None of this matters if nobody sees it.

I’ve watched engineers doing genuinely Staff-level work get passed over for promotion because the work was invisible. They were solving the right problems, but quietly. They wrote good documents that nobody read. They gave calibrating feedback in private Slacks instead of public channels. They did the cross-team work but didn’t present it anywhere.

Visibility isn’t about self-promotion. It’s about closing the loop between the work you’re doing and the people who need to understand it.

The concrete version of this: if you’re doing something that’s operating-at-the-next-level, someone above you in the organization should be able to say “yes, I know about that” when asked. If they can’t, you have a visibility problem, not a performance problem.

That means choosing venues. Writing design docs and sharing them in broader channels, not just your team Slack. Presenting at team meetings, even briefly. Making your work legible to people who aren’t watching closely.

You don’t need to be loud. You need to be visible.

Before you have the title

The conventional wisdom is that you prove you can operate at the next level before you get promoted to it. That’s true, and it’s also slightly wrong.

The more precise version is: you prove it over a sustained period, in a context where the right people can see it, on problems that are actually Staff-scope.

The title doesn’t grant you the ability to operate at the next level. But operating at the next level does create the conditions for the title to follow - usually, eventually, if you’re in the right organization and you’re not making the visibility mistake.

Start with the problem selection. What are you working on right now that nobody assigned to you? What decision have you written down that someone else will need to act on without you in the room? Whose thinking have you changed this quarter, not just whose question have you answered?

If the answers are thin, that’s useful information. And it’s fixable.

If you’re preparing for Staff-level interviews or want to sharpen how you present your experience on your resume, the SWE Interview System and SWE Resume System cover exactly this - how to show Staff-level signal on paper and in the room. You can find both at store.keycoaching.co.