A business metric has been sliding for a quarter or two. Not falling off a cliff, just drifting the wrong way, quarter after quarter. Several teams’ work feeds the number, so you check where the drop is coming from. Every team’s own numbers look healthy. Nobody’s slipping, nobody’s behind, no single team is the problem, and the number you own is still trending in the wrong direction.
As the operator, you need one person answerable for the number itself. Without intervention, nothing changes. Each team is doing its job, and the shortfall exists in the space between the teams, which no one owns. So you appoint a strong leader to work cross-functionally and close the gap. The leader begins their investigation, convenes a working group, and starts sending thorough summaries. For a month everyone engages and it feels like progress is finally happening, but the number is still slipping. You realize none of the activity week after week has translated into action, and at this point you may begin to wonder if the owner you appointed is up for the task.
Still, the person did their job well, and one thing did improve. The org now understands the number better, what feeds it, and where the loss is coming from. At the same time, no team has changed its priorities, so the problem isn’t getting fixed. Why? Because the leader tasked with ownership has not been given the means to change what those teams are working on.
How do you solve this as an operator? Give the owner a lever to push on. A lever is a mechanism for taking a real failure and making one team answer for it: specific, dated, and pinned to their name.
A lever works by producing a concrete failure that one team owns, put in front of the people that the team answers to. Now it’s a specific item they have to account for, so they weigh fixing it against the work they’d already planned, and it can move ahead in the queue.
The lever is the easy part. Figuring out whether your problem can support one, getting the right owner in place, and holding up your end once they start, are what turn it from a mechanism on paper into the problem actually getting fixed. Each of those is also a way these efforts can fail: an unfit problem, the wrong person, or an owner left to fend for themselves.
Getting the right person
What makes a good owner is specific, and it cuts across the usual temperament categories. The person everyone finds easy to work with, and the person who isn’t afraid to press people, can each succeed or fail here. Success comes down to:
Tolerance for invisible research work. The finding that gets included in a status report is the tip of the iceberg; the digging beneath it is often invisible to others. That work has to get done without visible progress to point to, sometimes for a long time.
Judgment about where to dig. A sense for which threads are worth pulling, and knowing when the picture is precise enough to act on, rather than boiling the ocean or stopping at the first plausible answer.
A track record that earns trust quickly. The owner usually won’t be walking into a situation where they have the teams’ trust out of the gate. What matters is a track record, known to these teams, of being right and delivering on hard things. That reputation lets trust form quickly, so people take the meeting, answer straight, and treat the findings seriously.
Identifying these qualities in a prospective owner is the easy part. The people who fit this description are the ones in a position to turn the job down. They’re in demand, they have other options, and they can see what they’d be taking on: mostly invisible work, with no authority of their own, and a red number that could end up looking like a failure on their part. You recruit them to the role by being honest that it’s a hard job and an opportunity worth taking. For the right person, it genuinely is.
Solving a cross-team problem no one else can crack is exactly the kind of thing that got this person where they are. The work itself is the draw. They get real latitude to dig into something that matters and own the answer, instead of chairing a working group. For someone who delivers hard things, it’s another feather in their cap.
They’ll want to know you’ll stand behind them if it goes sideways. That part is yours to give, and it’s what makes the difference between a hard job they’ll take and one they’ll pass on.
Two types of levers
What follows are two kinds of levers I’ve built and operated. One stages a failure, triggering it deliberately on a schedule. The other collects failures already happening and puts them on the record. (Collecting is the more common case.)
Choosing whether to use a lever, and which type, is your call because it requires a view across the org that the owner doesn’t have, and it requires your authority to make teams act on what it surfaces. Building it is the owner’s job, because it takes close, ground-level knowledge of the failure. You set the intent and the guardrails; the owner works out the mechanics.
When setting the intent, give the team a stake in the fix wherever you can, not just accountability for the failure. With something to gain, the team owns the outcome instead of just complying with a demand.
Staging: Sometimes the failure only shows up under a rare condition, or a process everyone relies on broke at some point and nothing has exercised it since, or the real failure would be too costly to let happen. Rather than wait for it to surface on its own, the owner triggers a controlled failure on a set date, taking a process that one team owns, that everyone assumes works, and testing it. Some fraction of the time it fails. Now there’s a real failure, dated, with one team’s name on it.
Collecting: On their own, defect complaints get handled one at a time. Each looks like an isolated incident, so no one sees the pattern to force an escalation. So the owner builds a running list, every complaint grouped by the team that owns it, kept where those teams and their managers can see it. Once the list is public, the effect is fast. For example, an engineering team that ships a risky change in the morning will see complaints stacking up within the hour, and pull the change back by lunch. Those same complaints used to take days to reach them.
Will a lever work here?
Not every problem can support a lever. For one to work, a few things have to be true:
Something is genuinely broken. If the problem is “we need a new capability that was never built,” there’s no failure, it’s a request for something new.
The responsible team takes ownership of the problem. Exposing a failure only stings if the team accepts it was their job to get right. If they think it’s someone else’s problem, the finding lands as a nag, and they may tune it out.
The problem splits into parts that individual teams can own. If some core of it can’t be divided that way and still needs several teams acting together, that core lands on no one, since no single team can resolve it or make the others act.
These three conditions are also a filter. You’re rarely dealing with just one problem like this, and you can’t put an owner on all of them. The problems that meet all three are where an owner with your backing will actually pay off.
Consider, for example, a liaison role positioned between two engineering teams. One team owns a customer-facing product, and the other owns the supporting backend systems. The person in the liaison role has no authority over either team. The biggest ask of the year from the product team is for the backend team to deliver a new capability their systems were never designed to support. The backend team says as much, estimates the work honestly, and asks for a design before committing. No lever helps here, because nothing is genuinely broken. The team is requesting something new. A request for a capability that doesn’t exist yet takes its place in the queue behind the others.
When a lever can’t help, the problem is the operator’s, not the owner’s. Where the capability doesn’t exist, or the team that should own it won’t, that means negotiating it onto a roadmap. And where a core of the problem genuinely can’t be split into single-team parts, it needs an authority no single team has: a dedicated group with a cross-team mandate, a senior person with the standing to direct it, or your own hand on it. However you do it, the authority has to come from you.
What you actually need tackled
When you appoint an owner, you’re handing them one job in three parts: find out what’s actually wrong, get the teams to prioritize the fix, and report where it all landed. None of it is glamorous. It’s months of failure reviews, weeks sitting with the team that fields complaints, chasing people across other orgs and waiting for the picture to come together. Here’s what it takes to do ownership well:
Research and diagnose the problem. Detective work, separating the real failure from everything that resembles it. Done well, it produces a finding precise enough to act on, not “fulfillment is slipping” but the specific point where it breaks down, under what conditions it happens, and which team owns each piece of it. This is where AI helps most, connecting data that sits in separate systems and surfacing patterns across it faster than a person working by hand, though a person still has to judge which pattern is the real failure. This is most of the job, and everything downstream depends on getting it right.
Negotiate prioritization of the fix. Take the finding to the teams who can do the work, whose roadmaps are set and whose capacity is committed. Make the case, team by team, that their piece of the problem is real, that it’s theirs to own, and ask them to change their existing commitments to accommodate work they didn’t anticipate. A good outcome is each team committing to fix its piece by a specific date, or a clear reason why they won’t.
Report where things stand. Bringing it all together in one place, what each team committed to and by when, what’s still stuck, and who it’s stuck on. Put it in front of the operator and the wider org, not left in scattered conversations. A good report is one where a leader with the authority to act can see exactly what’s been agreed upon, and exactly where to push if progress stalls.
Your part of the deal
Everything in the last section, the diagnosis, the negotiation, the report, only turns into action if your weight is visibly behind it. The owner has no standing of their own with these teams, only what you lend them. There are a few things only you can do to set them up, and their work depends on you doing them. Here’s what they are:
Set expectations, with the teams and with the owner. Tell the teams and their managers that the owner is there to find what’s wrong, not to collect status or run a working group. And tell the owner you’ll evaluate them on the quality of the diagnosis and the case they make to the teams (the things within their control), not on whether the number improves (which depends on others acting).
Put your weight behind the owner’s findings. Tell the teams’ managers plainly that findings from this owner carry your weight and you expect them to be acted on. Then make sure the backing stays visible without you having to chase anything. Have the owner’s report land somewhere you and they will see it, so managers know unaddressed findings reach you.
Step in when the owner is stuck. Most of the time your backing is enough, and the owner never needs you in the room. Sometimes a manager won’t commit their team to the fix, and the owner has pushed as far as they can. In that case, you go to that manager yourself and settle it. Your backing only means something if you follow through when it comes to this. The owner, and the managers, need to know you will.
Knowing early whether it’s working
Early on, the number can’t tell you whether the effort is working. It’s the last thing to respond, long after the effort that turns it around. There are earlier signs to watch, but no single one is completely reliable, each can look bad when things are fine, and look fine when things are bad. So what you’re watching for is the direction the signs are trending, not how they look on any one week:
The owner’s updates should change in character over time. Early on they sound like “here’s what I’m looking at.” Later they should sound like “here’s what I now think is true, and here’s the one thing I need from you.” That’s the progression you want, from surveying to a hypothesis to a specific ask. The absence of that progression means the effort has stalled. A stall can mean the owner isn’t getting it done, or that something outside their control is blocking them, and distinguishing the two is your job.
A healthy diagnosis narrows over time. Early on the owner will have a long list of possible causes and won’t be able to rule any out, and that’s fine. What you’re watching for is the list getting shorter as the owner digs, with potential causes being eliminated, not just added. A list that keeps growing with nothing ever crossed off means the owner is accumulating theories instead of testing them.
Being agreeable isn’t the same thing as being engaged. Taking the meeting costs nothing. What matters is whether a team digs into what the owner found, argues the specifics, checks their own data, or just receives it and does nothing. Performative engagement and flat refusal are different problems, but both mean the owner has hit something the setup you gave them can’t get past, and that’s where your attention is worth spending.
Telling which way an effort is going takes time. Getting it wrong goes one of two ways. You might give up on one that was only slow, or you might keep backing one that has actually failed. The second is the harder mistake, because a failed effort is easy to mistake for a slow one.
Who volunteers next time
Whether you can get someone to own the next cross-team problem depends on how the last one went. Do it right and you’re no longer talking reluctant people into it; you’re choosing from the ones who want it! The people who can do this work talk to each other, and they watch what happens to the person who takes it on. Put someone through a year of chairing a working group with no authority and nothing to show for it, and word gets around. But give someone a real problem, back them the whole way through, and make sure they get the credit, and the next person will already know it’s worth saying yes to—and the best of them will come to you before you have to ask.