The Visibility Problem: Why Great Engineers Stay Stuck at Senior

Most engineers who are stuck at Senior aren’t stuck because they can’t do the work. They’re stuck because no one above them can see the work.

That’s a different problem. And it requires a different solution.

I spent 12 years at Facebook watching this play out. Engineers who were technically brilliant, genuinely excellent at their jobs, year after year getting feedback that amounted to: not quite ready. Meanwhile someone else on the team gets promoted, and the stuck engineer looks at that person’s work and quietly thinks: I do that too.

Sometimes they’re wrong. But often they’re right. They do do that work. They just do it quietly.

The Signal Problem

Here’s how the promotion process actually works at a company like Facebook. At the end of a review cycle, your manager walks into a calibration meeting with a stack of cases. Your name is on one of them. Your manager makes a case for you. Then every other manager in the room either supports that case or pokes holes in it.

The managers poking holes haven’t worked with you. They’ve heard of you, maybe. If you’re unlucky, they haven’t heard of you at all. Their skepticism is the default position. Your manager has to overcome it.

What does your manager bring to that room? Evidence. Impact. Stories. Ideally, corroboration from other managers whose teams you’ve worked with.

If your work has been contained within your immediate team, your manager is in that room alone, vouching for you against people who have no reason to believe it. That’s a weak position to be in. Not impossible, but weak.

Now imagine your manager walks in and says: “She led the migration that unblocked three other teams. I’ve got two other managers here who are going to back that up.” That’s a different conversation.

Visibility isn’t about self-promotion. It’s about making your manager’s job easier in that room.

What “Invisible Work” Actually Looks Like

The engineers who stay stuck at Senior tend to cluster around a particular working style. They’re reliable. They execute well. They’re the person their immediate teammates lean on. They fix things quietly. When something breaks at 2am, they handle it without making a big deal of it.

All of that is genuinely valuable. None of it is enough.

The work that goes unnoticed is usually one of three things:

Depth without breadth. You’re the expert in your service. You know it better than anyone. You’ve fixed bugs that would have taken someone else weeks. But that expertise is visible only to the people who already work with you. Outside your team, you’re just a name in a code review.

Reactive work. You solve problems as they come to you. Someone pings you, you help. Something breaks, you fix it. The impact is real, but the pattern is invisible because there’s no artifact, no document, no decision that anyone can point to later.

Heroics without documentation. You pulled the team through a rough quarter. You stayed late. You filled gaps. But six months later, when someone tries to reconstruct what happened, there’s no record of your role in it. The incident was resolved. The retrospective didn’t capture your specific contribution. It just says “the team.”

The common thread: the work exists, the impact exists, but there’s nothing that survives the moment and travels upward.

What Changes at Staff

The clearest mental model I have for the Staff transition: a Senior engineer makes their team better. A Staff engineer makes other teams better.

That’s not just about scope. It’s about where your work lands and who notices it. When a Senior engineer has a great quarter, their immediate teammates know it. When a Staff engineer has a great quarter, adjacent teams know it, and those teams’ managers can speak to it.

This is why the most common piece of feedback stuck engineers get - “you need to increase your scope” - lands so flat. It sounds like you should just do more work, take on bigger projects. But that’s not the actual mechanism. The mechanism is that your work needs to create visible artifacts that cross team boundaries. Other people, outside your team, need to be able to point to something you did and say: that helped us.

A design doc that multiple teams adopt. A framework your team built that two other teams now use. An architectural recommendation that changed how an adjacent team approached a problem. A postmortem that identified a gap across the org and proposed a fix.

These things travel. They survive the moment. They give other managers something to say in that calibration room.

The Practical Part

If you’re stuck at Senior and you recognize yourself in any of this, a few things that actually move the needle:

Write down what you’re doing before you do it. Not a novel. A one-pager. Here’s the problem, here’s the approach, here’s the trade-off I’m making and why. Circulate it to anyone who might be affected. This does two things: it forces you to think at a higher level before diving in, and it creates an artifact that other people see before the work is done. They’re watching when it lands. They can speak to your thinking, not just your output.

Pick one cross-team problem per half and own it. Not as a side project. As something you explicitly bring to your manager and say: I want to lead this. It doesn’t have to be massive. It has to be something where the beneficiary is not your immediate team. The other team’s manager needs to know your name and what you did.

Be specific when you ask for feedback. “What would it take to get promoted?” is a weak question. Your manager will give you a vague answer and you’ll both feel like the conversation was useful. Ask instead: “In the last calibration cycle, what was the specific pushback on my case?” If your manager doesn’t have an answer, that tells you something too - your name might not be coming up at all.

Stop fixing things silently. When you resolve something that would have taken your teammates much longer, say so. Not in a bragging way. In a documentation way. “Here’s what happened, here’s why it was non-obvious, here’s what to watch for next time.” Put it in writing. Send it somewhere that isn’t just your immediate Slack channel.

The Uncomfortable Truth

Some engineers have been told “not quite ready” so many times that they’ve started to believe it’s about readiness - that they just need to get better at the craft, that the promotion will follow naturally when they’re good enough.

It won’t. Technical excellence is necessary but not sufficient, and the gap between necessary and sufficient is exactly what visibility fills.

The engineers I watched get promoted to Staff at Facebook weren’t always the best coders on their teams. They were the ones whose work other people could point to. Their managers walked into calibration with backup.

If your manager is the only person in that room who can speak to what you’ve done, you’re one skeptical question away from another cycle of waiting.

If you’re navigating the Senior to Staff transition and want to think through where you actually stand, the SWE Interview System covers how to communicate your impact in the interviews that come next - once you’ve started building the visibility that gets you into that conversation.