There is a point in cross-team Product work where the org chart starts to look like the obvious villain.
You own an outcome that depends on another team. Their priorities keep moving. A shared platform group has a queue you cannot control. A peer leader makes different tradeoffs than you would. After the third missed dependency, it is easy to think: if those people reported to me, this would be easier.
Sometimes that conclusion is right. I just would not start there. A reporting line is one possible cause of broken work. It is not a diagnosis.
The frustration can be completely legitimate
Imagine a director responsible for an account-management experience that crosses three durable teams. One team owns the customer workflow. Another owns a shared identity capability. A third owns an operational system that has to approve certain changes before they can take effect.
The director keeps seeing the same pattern. Their team finishes its part. The work waits on a shared dependency. A decision bounces between leaders. A release slips. Then the same thing happens the next quarter.
At some point, “put the other team under me” can sound less like empire building and more like a practical response to a recurring problem. The useful question is not whether the leader is frustrated. Of course they are. The useful question is what exactly would become different if the reporting line changed?
Would a decision move closer to the work? Would an overloaded shared capability suddenly have more capacity? Would two conflicting goals become one? Would the technical dependency disappear? Would the customer outcome have a clearer owner? Or would the same bottleneck simply have a new boss?
Those are different answers, and they point to different interventions.
Separate ownership from control
One reason this gets messy is that Product organizations use “ownership” to describe several different things. A team can own a bounded stream of value: a problem space it can reasonably discover, build, operate, and improve. A manager or director can be accountable for a broader outcome that crosses several of those teams. And a reporting line determines who formally manages whom. Those three boundaries do not have to be identical.
A team responsible for curbside fulfillment, for example, can own a meaningful end-to-end slice of that experience without also owning every inventory service, payment capability, customer communication, or store system involved in the larger journey. A director may need to carry the horizontal view across those pieces without having every person involved report into the same organization. “End to end” changes with altitude. The mistake is treating it as one fixed-sized box.
Map the failure before you move the boxes
Before changing structure, I want to see the work.
Where does it wait? Which decisions repeatedly escalate? Which dependency has no explicit service expectation? Where are teams measured against goals that make the shared outcome harder? Which capability requires so much specialized context that it is constantly re-explained at the boundary? Which team is carrying more cognitive load than its scope can reasonably support?
That map usually makes the options more interesting than “merge the teams” or “leave everything alone.”
Maybe the real fix is a clearer decision right. Maybe a shared team needs a different boundary or service model. Maybe a platform capability should become a durable product with an explicit interface instead of an internal favor queue. Maybe the work needs a cross-team operating cadence because the outcome truly spans several organizations. And yes, sometimes the map shows that accountability has been split so badly that the reporting structure should change.
The point is to make the structure answer the work, not use the structure as a substitute for understanding it.
You can own the outcome without owning every person
This is one of the leadership transitions Product people eventually have to make. Earlier in your career, it is reasonable to associate ownership with the work directly in front of your team. As your scope grows, more of what you are accountable for will depend on people you do not manage.
That can feel inefficient because influence is slower than control. You have to create shared context. You have to make dependencies visible. You have to establish decision mechanisms with peers. You have to know when to escalate and when to solve the problem at the working level. You have to make sure people understand what happens before and after their piece of the system.
None of that means weak structures should be tolerated forever. It means leadership at broader altitude cannot depend on continuously pulling every dependency into your own reporting line. If the only way an outcome can succeed is for one leader to own every participating team, the organization may have a deeper coordination problem than the chart can solve.
Sometimes you really would run the team better
There is an uncomfortable version of this conversation where your confidence is earned.
Maybe you build strong teams. People grow under you. Your organization executes. A neighboring team is struggling, and you can see specific leadership problems you believe you could fix. You may be right.
That still does not automatically make scope consolidation the scalable answer. If the organization solves every leadership gap by moving more people under the strongest operator, it can create a different dependency: the company becomes dependent on that leader’s capacity. The organization avoids developing other leaders. Cross-team mechanisms stay weak because absorbing the boundary is easier than improving it.
There is a related pattern sometimes described as empire building: equating leadership success with accumulating people, budget, and scope. It is worth watching for, but I would not use the label as a shortcut. A leader asking for more scope may be responding to a real structural problem. Another may simply be frustrated. Another may have built the capability to carry more. The evidence matters more than the accusation.
The chart may still be the problem
This is not an anti-reorg argument.
A capability can live in the wrong place. A team can own a scope that is too broad to handle coherently. Decision authority can sit so far from the work that every meaningful choice becomes an escalation. A business can change while the organization remains built for the old strategy.
Change those structures when the diagnosis supports it.
Just do not confuse visible friction with proof that the reporting line caused it. Slow execution, painful dependencies, weak ownership, and inconsistent leadership are symptoms. The disease might be structure. It might also be architecture, capacity, incentives, decision rights, capability gaps, or the absence of a mechanism for carrying an outcome across teams.
Before you ask for a different org chart, be able to explain what the new structure changes in the work. Which decision gets better? Which dependency becomes healthier? Which capability becomes more coherent? Which customer or business outcome gets a clearer owner?
If the answer is specific, you may have an org-design problem. If the answer is mostly I could make them move faster, keep diagnosing.