The Cross-Team Problem Nobody Owns

There’s a category of problem that exists at every company above a certain size. Engineers know about it. Managers know about it. Everyone agrees it’s a real problem. And nobody is doing anything about it.

Not because they’re lazy. Because it’s genuinely unclear whose job it is.

The authentication service that three teams depend on but none of them own. The deployment pipeline that works 95% of the time and ruins someone’s Friday the other 5%. The monitoring gap between service A and service B where alerts fall into a void and pages go to whoever happens to be awake.

These problems have a specific shape. They sit at the boundary between team charters. They require coordination across at least two organizations. They’re important enough that everyone wishes someone would fix them, and ambiguous enough that nobody has. They tend to generate a lot of Slack messages and very little forward motion.

I spent twelve years at Facebook, which involved a non-trivial amount of time in hiring committees and calibration sessions. I looked at hundreds of engineers being evaluated for promotion, and I can tell you what separated the ones who made Staff from the ones who didn’t. It wasn’t technical skill - the field thins out by that point and most candidates are technically strong. It was this: the Staff engineers had found one of these problems and done something about it.

Not waited to be assigned. Not escalated until someone else took it. Found it, named it, built the coalition to fix it, and shipped the fix.

Here’s why that pattern shows up so consistently.

When you work on a well-scoped, owned problem inside your team’s domain, you’re doing exactly what your job description says. You’re meeting expectations. You might meet them very well - ship quality, reliable, mentors the junior engineers, writes great docs. But you’re operating inside a box that was drawn for you.

Staff-level work, by definition, operates outside that box. The problems that require Staff engineers to solve them are the ones that can’t be solved inside any single team’s charter. If they could, a senior engineer would have handled it already.

So when you find one of those cross-team problems and you drive it to resolution, you’re doing two things at once. You’re solving a real problem that the organization cares about. And you’re demonstrating exactly the kind of operating model that justifies a Staff title.

The promotion committee doesn’t have to squint to see it. The evidence is right there.

The harder question is how to actually do this. Because the reason these problems persist isn’t that they’re technically difficult. It’s that they’re politically complicated.

Nobody owns them. That means nobody has budget for them, nobody has a team to staff them, and nobody’s quarterly goals include fixing them. If you walk into a room and say “I want to fix the deployment pipeline,” you will immediately run into three teams who each have opinions about how it should work, and none of them can give you the engineering time to build it.

The engineers who actually get these things done follow a pattern I saw repeatedly. They don’t start by trying to get everyone to agree on a solution. They start by getting everyone to agree on the problem.

This sounds obvious. It isn’t.

When you map out a cross-team problem carefully - write down what’s actually happening, who’s affected, what it costs them, where the boundary confusion lives - you create a document that no one can reasonably disagree with. You’re not proposing anything yet. You’re just describing reality. And suddenly you have three teams nodding at the same piece of paper instead of talking past each other.

From there, getting to a pilot is easier than getting to a commitment. “I want to fix this” is a big ask. “I want to run a six-week experiment with Team A’s on-call rotation and measure whether this reduces their incident rate” is a much smaller ask. When the pilot works, you have data. When you have data, the resistance softens.

There’s a tactical side to this that’s worth being explicit about.

The engineers who pull this off tend to be very deliberate about visibility without being annoying about it. They write things down and share them. They send a short update to stakeholders every few weeks, not because anyone asked, but because it keeps the work on people’s radar and prevents the kind of organizational amnesia that kills cross-team projects. Six months in, when they need a partner team to prioritize some integration work, there’s a record. The problem is documented. The progress is documented. The value is clear.

This matters enormously in a promotion review. One of the hardest things about evaluating a Staff candidate is that their work often lives in meetings and documents and alignments - not in pull requests. The engineers who make this legible, who create artifacts that clearly show what they did and why it mattered, make the promotion committee’s job easy. The engineers who do the same work but leave no trail are a harder case to make, even when the technical work was identical.

Write things down. Not novels - short, clear, dated updates. A problem statement. A decision log. A before-and-after on the metric that mattered. This is your paper trail and it’s part of the job.

One more thing about finding the right problem.

Not all cross-team problems are worth your time. Some are ambiguous because they’re genuinely low priority and the organization has correctly not invested in them. Some are political landmines where the real issue isn’t technical at all - there’s an organizational conflict underneath that no amount of good engineering will resolve.

The ones worth picking have a specific character: they have a clear, measurable cost to multiple teams, the root cause is technical or process-based rather than political, and there’s at least one influential person in each affected team who wants the problem solved. That last part is important. You’re going to need allies who can unblock resources and navigate their own team’s priorities. If you’re the only one who thinks this is worth fixing, that’s a signal.

The best version of this is when you hear the same frustration from two or three different engineers in different teams, each of whom thinks it’s someone else’s problem to fix. That’s your opening.

The career implications are direct. If you’re a senior engineer thinking about what it takes to get to Staff, the answer is almost never “be better at the thing you’re already doing.” It’s “find a problem that requires you to operate differently - across teams, with influence instead of authority, at a scope that isn’t handed to you.”

Cross-team problems nobody owns are exactly that. They’re sitting there at every company, generating friction, waiting for someone to take them seriously.

If you’re thinking about how to build the kind of track record that makes a Staff promotion case obvious to a committee, the Senior to Staff guide at Key Career Coaching covers the full picture - what the level actually requires, how to build visibility, and how to position the work you’re already doing.

resources.keycoaching.co/blog/senior-to-staff-engineer