At media scale, the bottleneck is the space between teams

When a media or telecom delivery org slows down, the reflex is to find the team that is dragging. It is almost never a team. It is the wait between them, and the cure most leaders reach for makes it worse.

Media and telecom organizations carry a delivery load that would unsettle most industries: content, platform releases, and campaigns landing more or less continuously, across dozens of teams spread over time zones and vendors. When the whole thing slows, the search starts inside the teams. Which group is behind, which lead needs a conversation, which roadmap slipped. That search is honest, and it usually finds nothing worth fixing, because the teams are mostly doing fine. The work that is actually stuck is the work that lives between them.

Dependencies are the real backlog

Picture one team waiting on an application programming interface (API) from a second team, which is waiting on a shared component owned by a third, which needs a sign-off from a group several org-units away that does not know it is on the critical path. None of those waits appears on any single team’s board. Each board looks healthy. The delay is real, and it is invisible, because it belongs to the spaces in between, and those spaces were never anyone’s job to watch.

That is the backlog that matters at scale, and almost no one is managing it. Teams refine and burn down the work in front of them with real discipline. The queue between teams, the hand-offs and dependencies and waits, sits unmanaged because it has no owner and no board of its own. So the first job is not to make any team faster. It is to make that hidden queue visible: map the dependencies, see where the work goes quiet, and treat the line between teams as something you manage on purpose rather than discover after a release slips.

The instinct to add coordination, and where it turns

Here is where good intentions take a wrong turn. Once leaders see the dependencies, the natural response is to coordinate them, and coordination has a price most people underestimate. You add a scaling framework. You add ceremonies to keep teams in sync, roles to own the syncing, and a planning layer above the planning layers. Each addition is defensible on its own. Together they accumulate into a second organization whose whole job is managing the first one.

Past a point, that coordination machinery costs more than the dependencies it was built to manage. The meeting to align eight teams consumes more capacity than the one hand-off it untangles. The framework imposed everywhere slows the four teams that had no dependency problem in order to govern the two that did. The overhead becomes the constraint, and because it arrived as a fix, no one suspects it. I have walked into organizations where the most over-coordinated teams were the slowest, and the coordination was the reason, not the remedy.

The art is not the most coordination you can run. It is the least structure that makes the real dependencies visible and resolves the actual constraint.

Choose the lightest framework that fits

The better move is to diagnose the specific constraint before reaching for a named solution. Sometimes the answer is a heavyweight framework, and when the dependency web genuinely warrants it, that is the right call and worth its cost. Often the answer is lighter: a thinner coordination layer over a few teams, a shared view of the dependencies that lets teams resolve their own hand-offs, a framework borrowed in parts rather than adopted whole. The skill is matching the weight of the structure to the weight of the problem, and being willing to remove coordination as readily as you add it.

We took exactly that approach inside a global financial-data company, reorganizing 18 teams into a product operating model and blending LeSS, Nexus, and SAFe rather than forcing a single framework onto a problem that did not fit one. Product waste fell from roughly 90% to under 5%, and the gains held because the structure stayed proportionate to the work. You can read how that came together. The framework choice mattered less than the discipline of fitting it to the constraint, which is the same judgment we bring to choosing a scaling framework.

Make it visible, then coach the people who decide

Visibility is the foundation. Teams configured to surface cross-team dependencies, status, and flow give leadership a view of reality instead of a deck, and let teams stop colliding by surprise. That is real, and it is necessary. It is also not sufficient, because a dependency map shows you the constraint but does not resolve it. People resolve it.

What decides whether the lighter structure sticks is the behavior of the leaders sitting above the teams. The director who keeps escalating around the new hand-off owner instead of through them. The VP who asks for the old status report alongside the new shared view, so teams maintain both and trust neither. The leader who, the first time a dependency surfaces uncomfortable truth, reaches for the heavyweight framework again. Coaching those leaders to hold the lighter structure, to let the visible queue do its work and resist the urge to coordinate every gap, is most of what makes the change last. The tooling shows the constraint. The leaders decide whether it gets resolved or buried, and that is where this work is won or lost.

If you want to see where your dependencies are actually stalling delivery, see where delivery is getting stuck.