The Staff Engineer Invisibility Trap

Most engineers who get stuck at senior level aren’t doing bad work. They’re doing invisible work.

There’s a pattern I saw repeatedly at Facebook. A senior engineer would quietly carry a system that half the org depended on. They’d fix the gnarly bugs, answer the questions no one else could answer, and keep things running through reorgs and shifting priorities. Genuinely valuable. The kind of person where, if they left, you’d feel it for months.

And they’d get passed over for staff, year after year.

The work wasn’t the problem. The visibility was.

What Changes at Staff

Senior engineers are expected to be excellent at execution. You take a problem, you solve it well, you deliver. That’s the bar.

Staff is different. The expectation isn’t just that you do excellent work - it’s that your work shapes what the team or org does next. You’re not just solving problems that are put in front of you. You’re identifying problems worth solving, convincing people those problems matter, and creating clarity where there was confusion.

That’s a fundamentally different job. And the audience for your work changes too. At senior, your peers and your manager evaluate you. At staff, people two and three levels up have opinions about you. Those people think in different terms than you do.

Here’s the part most engineers don’t internalize until too late: if no one knows you’re doing it, it doesn’t count.

I don’t mean that in a cynical “office politics” way. I mean it structurally. Staff-level impact is, by definition, cross-functional. It requires alignment, buy-in, and coordination with people outside your immediate team. If your work isn’t visible to those people, it literally cannot have staff-level impact. You can’t influence what you can’t be seen.

The Four Ways Engineers Go Invisible

They work in the wrong places. The most common version of this trap. You’re doing real, hard, important work - but on a system or problem that your skip-level has never heard of. At Facebook, the engineers who made staff fastest were almost always working on problems their VP knew about. Not because they were chasing visibility, but because high-visibility problems are high-visibility for a reason. They matter to the business. Working on them puts you in the room with the people who make promotion decisions.

This also means developing a sense for which problems have the most business impact, not just the most technical complexity. A gnarly distributed systems problem that nobody upstream cares about is still a gnarly distributed systems problem. A simpler problem that’s costing the business real money is a career accelerator.

If you’ve been heads-down on the same infrastructure component for two years and your org’s leadership couldn’t name it, that’s worth thinking about.

They don’t narrate their work. Engineers tend to believe that good work speaks for itself. It doesn’t. Not at senior levels, and definitely not at staff. The engineers I saw promoted to staff were consistently good at making their work legible - through design docs, postmortems, tech talks, or even just well-written updates. Not self-promotion for its own sake, but a habit of making their thinking visible so others could build on it, critique it, and give them credit for it.

The engineers who got stuck were often doing equally good work. They just had no artifact trail. When it came time to write a promo packet, there was nothing to point to except a list of PRs.

They wait to be given a staff-level problem. This is probably the subtlest version. You’re good. Your manager knows you’re good. And you’re waiting for someone to hand you the big cross-org project that will demonstrate your staff-level impact.

It doesn’t work that way. The people who get those projects are the ones who have already demonstrated they can operate at that level - which they demonstrated by creating their own opportunities first. Smaller scope, but staff-level thinking: identifying a problem no one owned, proposing a solution, getting alignment, executing. Do that a few times and the bigger opportunities start finding you.

They speak the wrong language. This one is sneaky because you can get the first three right and still fall into it. You’re working on a visible problem. You’re narrating your work. You’re creating your own opportunities. But when you talk about your work, you describe it like an engineer talking to other engineers.

That works fine for your peers. It doesn’t work for your skip-level, and it really doesn’t work in the room where promotions get decided.

Senior leadership thinks in business outcomes: revenue, costs, reliability as a customer experience metric, time-to-market. They don’t retain “rewrote the caching layer to reduce p99 latency from 800ms to 120ms.” They retain “cut checkout failures by 12%, which was costing us $2M a year.”

The underlying work is the same. The translation is different. And it’s a skill most engineers never develop because they’ve spent their entire career communicating with people who share their technical context.

This matters at every step. When you’re choosing what to work on, ask yourself: can I articulate the business impact of this in one sentence that a non-technical executive would understand? If you can’t, either the impact isn’t there or you haven’t found it yet. When you’re writing that design doc or giving that update to your skip-level, lead with what changed for the business, not how you changed it. The technical details are the evidence. The business outcome is the headline.

The engineers I saw at Facebook who moved fastest into staff roles had this instinct. They’d finish explaining some genuinely impressive technical work and then, almost as an afterthought, translate it: “which means we can onboard new regions in days instead of quarters.” That last sentence is the one their director remembered.

What Visibility Actually Looks Like

This isn’t about sending status updates or making yourself sound busy. That’s noise, not signal.

Actual visibility at the staff level looks like this:

• You wrote the design doc that a team three doors down referenced when building their system
• You ran the incident postmortem and the changes you proposed got adopted across two other teams
• You gave a tech talk that changed how your organization thinks about a specific problem
• Your skip-level manager, when asked what you’re working on, can answer in terms of business impact without checking with your manager first

Notice that all of these are about the output of your thinking reaching people beyond your immediate team. And notice the language: the further from your immediate team the audience is, the more the framing shifts from technical to business. That’s what cross-functional impact looks like in practice. It’s not schmoozing. It’s your work escaping the boundaries of your immediate context, described in terms that land at each level.

A Concrete Place to Start

If you’re a senior engineer who suspects you’re in this trap, here’s a useful question: can your skip-level manager describe what you’re working on and why it matters to the business?

Not your manager. Your skip-level. The person two levels up. And not “they’re working on the caching layer” - that’s a technical description, not a business one. Could they say something like “they’re reducing page load failures that are costing us X in conversion”?

If the answer is probably not, that’s worth taking seriously. It doesn’t mean doing less work. It means two things: making your work visible, and making it visible in the right language. Pick one thing you’re working on right now that actually matters, and ask yourself two questions. First, who outside my immediate team should know about this? Second, what’s the business impact, in one sentence, that would make them care?

A design doc. A tech talk. An email to a broader distribution list. A write-up of what you tried and what you learned. Something with a longer half-life than a Slack message.

Do that consistently, and over time you build the artifact trail that makes the senior-to-staff case legible to people who don’t work with you daily. That’s not a hack. It’s just what staff-level work actually looks like from the outside.

The Promotion Conversation

One more thing worth saying plainly. Promotion to staff requires your manager to advocate for you - but your manager cannot be the only person in the room who knows who you are.

At Facebook, staff promotions went through a calibration process where multiple directors and senior managers would weigh in. If your manager is the only person in that room who’s heard your name, the conversation gets hard fast. If two or three other people have seen your work, read your design docs, or sat in on a postmortem you ran, your manager has allies instead of doing a solo convincing job.

And here’s the thing about that room: the people in it are comparing candidates across teams. They’re not deep in the technical details of your work. The case that lands is “this person reduced incident response time by 60%, saving us three engineering-weeks per quarter” not “this person redesigned the alerting pipeline with a novel fan-out architecture.” Both describe the same work. One of them survives a conversation among people who have thirty other candidates to discuss.

You cannot manufacture that. But you can create the conditions for it by doing work that reaches beyond your team’s boundaries consistently over time. Not once, not in the month before review cycles, but as a pattern of how you operate.

That’s what the invisible engineers I saw stuck at senior were missing. Not skill. Not drive. Just the habit of making their work visible to the people whose opinions would eventually matter.

If you’re working through the senior-to-staff transition and want a systematic framework for the interview side of it, the Software Engineer’s Interview System covers how to articulate staff-level impact in the interviews themselves - including how to talk about cross-functional work without it sounding like you’re taking credit for other people’s output.