What Staff Engineering Actually Means

There’s a moment in every senior engineer’s career where they hit a ceiling. The code gets better, the systems get more complex, but the promotions slow down. Someone mentions “Staff Engineer” and suddenly there’s a new mountain to climb.

Here’s the thing nobody tells you: Staff Engineer is not Senior Engineer with more years. It is a fundamentally different job.

I’ve been on both sides of this transition. Here’s what actually changes.

The Senior Engineer Trap

As a senior engineer, you’re rewarded for execution. Ship features. Fix hard bugs. Write clean code. Review PRs. You build a reputation for being the person who gets things done.

The trap is assuming that doing more of this — faster, better, harder — is the path to Staff. It isn’t.

I spent a year doing exactly that. I was the most productive engineer on my team. I shipped more than anyone. My code quality was excellent. And my promo packet went nowhere.

The feedback that changed everything: “You’re solving problems. But you’re not deciding which problems to solve.”

What Actually Changes

1. You stop writing most of the code

This is the hardest part for engineers who love engineering. At Staff level, the code you write is maybe 20% of your impact. The other 80% is:

• Defining the technical direction for your area
• Aligning multiple teams on a shared approach
• Writing docs that prevent 50 engineers from making the same mistake
• Saying “no” to the wrong projects before they consume six months

I still write code. But I’m intentional about which code. I write the prototype that proves a new architecture works. I write the migration script that nobody else wants to touch. I write the design doc that becomes the blueprint for a quarter of work.

2. Ambiguity becomes your job

Senior engineers get well-defined problems. Staff engineers get ambiguous situations.

“Our database layer is too slow” is a senior engineer problem. “Our infrastructure won’t support our product roadmap for the next two years and we don’t know why” is a Staff engineer problem.

The difference:

• Senior: Given a problem, find the best solution
• Staff: Given a direction, find the right problems to solve

At Meta, I once spent three weeks just defining the problem before writing a single line of code. The team was frustrated — they wanted to start building. But the definition work saved us from building the wrong thing entirely. That’s the job.

3. Your “team” expands invisibly

As a senior engineer, your team is the 6-10 people you sit with. As a Staff engineer, your team is everyone whose work intersects with yours — and that can be 50-100 people across multiple orgs.

Nobody assigns you this team. There’s no org chart update. You just start showing up in rooms where decisions are being made, because you have context that nobody else has, and you can connect dots across boundaries.

4. You become a force multiplier

The single most important mental shift: your job is not to be the best engineer. Your job is to make every engineer around you better.

This means:

• Designing systems that are hard to misuse
• Writing guidelines that prevent entire categories of bugs
• Mentoring senior engineers toward their own Staff promotion
• Building tools that save 100 engineers 30 minutes each

One well-placed design doc can save more engineering hours than a year of individual coding.

The Skills Nobody Teaches You

Writing

This surprised me. Staff engineering is a writing-intensive job. Design docs, RFCs, postmortems, strategy docs, emails that align orgs. If you can’t write clearly, you can’t operate at Staff level.

I write more now than I ever did in school. The difference is every document has a decision at the end of it.

Saying No

At senior level, you say yes and execute. At Staff level, saying no is one of your most important tools. Every “yes” is a commitment of engineering resources that could go somewhere else.

The hardest nos: telling your own manager that their pet project isn’t the right priority. Telling a partner team that their approach won’t scale. Telling yourself that the technically interesting project isn’t the impactful one.

Navigating Without Authority

You’re not a manager. You don’t have direct reports. You can’t tell anyone what to do. But you need to drive outcomes across teams.

This means influence over authority. You have to be right often enough that people trust your judgment, and humble enough to change your mind when you’re wrong.

The Question I Ask Myself Every Week

“If I got hit by a bus tomorrow, would the team’s technical direction survive?”

If the answer is no — if the strategy lives only in my head — then I’m not doing my job. Staff engineering is about building systems, processes, and people that outlast you.

The Path Forward

If you’re a senior engineer aiming for Staff, here’s my honest advice:

1. Stop optimizing for output. Start optimizing for impact.
2. Find the ambiguous problem nobody owns. Own it.
3. Write everything down. Design docs, decision records, guidelines. Your writing is your leverage.
4. Mentor someone. Not casually — really invest. Their growth is your growth.
5. Get comfortable being uncomfortable. The ambiguity never goes away. You just get better at navigating it.

The title is nice. But the real reward is watching a system you designed handle 10x more load than anyone expected, built by a team you helped grow, solving a problem you helped define.

That’s what Staff engineering actually means.

This is part of an ongoing series on engineering leadership. Next up: how I think about technical strategy at Meta scale.