Stop Scaling. Start Broadening.

Every PI Planning ceremony, every dependency board, every Release Train Engineer exists for one reason: the organization defined its product too narrowly.

Narrow definitions create boundaries. Boundaries create dependencies. Dependencies create coordination demand. Coordination demand creates roles and ceremonies. And the roles and ceremonies create career incentives to preserve the boundaries that created the problem. The loop is self-sealing.

The standard response is to coordinate better: bigger ceremonies, smarter boards, dedicated coordinators. The structural response is different: remove the boundaries that create the coordination demand in the first place.

Three domains, independently, reach the same conclusion.

125 people, two days, same board

A scaling framework prescribes a quarterly planning ceremony. 125 people in a room for two days, mapping dependencies on a board. After a year, the board shows the same dependencies between the same teams. Why would anyone ask why? The ceremony is working: dependencies are visible, tracked, managed, escalated. The fact that they reappear every quarter is not treated as failure. It is treated as the normal cost of working at scale.

The dependencies are symptoms. They exist because the organization split one product into multiple narrow products, each with its own backlog, its own owner, its own teams. What customers experience as one thing, the organization manages as six things that need coordination. Every feature that crosses a product boundary creates a dependency. Every dependency creates a coordination interface. Ten teams produce forty-five interfaces. The math is combinatorial and the ceremonies grow to match.

Around the visible dependencies, infrastructure accumulates: a ceremony to identify them, a role to manage them, a board to track them, a metric to report on them. None of it questions why the dependencies exist. And none of it can afford to. The role needs the dependencies. The ceremony justifies itself by the dependencies it surfaces. The board provides visible evidence of "good management." Removing the dependencies would orphan the infrastructure: no dependencies means no board, no ceremony, no role, no metric. The infrastructure's stakeholders become advocates for the structural status quo.

The ceremony captures two kinds of dependencies. Known recurring ones (team A always needs team B's API, team C always blocks on team D's platform) are not invisible. Everyone already knows them. They do not need 125 people and two days to surface. They need structural solutions: shared backlogs, team redesign, broader product boundaries. Emergent dependencies, the ones discovered during the work, cannot be predicted three months in advance. No planning ceremony can surface what does not yet exist. The ceremony captures the dependencies that do not need a ceremony and misses the ones that would benefit from early detection.

Bryan Finster made the point cleanly: "Real improvement would mean shrinking the RTE's responsibilities until the role disappears. That's not a technical problem, it's a political one. You're asking people to dismantle the coordination system that justifies their position." The coordination role is not the person's fault. The structure created a job that depends on the problem persisting.

"We've gotten better at managing dependencies" is the tell. Success is measured by process maturity, not by the dependency count approaching zero.

Scale up to scale down

Instead of building coordination infrastructure around narrow product definitions, broaden the product definition until the dependencies dissolve. What was cross-product becomes intra-product. The coordination infrastructure becomes unnecessary because the problem it managed no longer exists.

One product. One backlog. One Product Owner. Cross-functional teams pull from a shared backlog. No dependency board needed, because there are no product boundaries to create dependencies across.

The pattern shows up wherever someone asks the broadening questions. Consider government. How many products does a citizen see? Citizens do not care which ministry provides a service. They care whether the service works. From the customer's perspective, government digital services might be one product.

Banks are another reliable example. Ask a bank how many products they have and the answer is hundreds: savings, lending, foreign exchange, each with its own backlog and its own teams. Ask the customer and the answer is different. The customer wants to move money, borrow money, or save money. The hundreds of "products" are internal technology divisions, not things customers buy. Inside technology organizations, the same pattern runs at a smaller scale. A database team calls its database "our product." A middleware team calls the middleware "our product." No customer buys a middleware layer. These are organizational boundaries masquerading as product boundaries. Every one of them generates coordination demand that flows into ceremonies, boards, and roles.

The practical test: if multiple Product Owners must coordinate at all, through a Chief Product Owner, a Portfolio Manager, a weekly sync, or a shared spreadsheet, you have a product definition problem, not a coordination problem. A wider product definition eliminates the coordination layer.

The most widely adopted scaling framework was designed around this trade-off explicitly. Its creator, Dean Leffingwell, said it plainly in a VersionOne webinar: "We don't typically mess with your organizational structure because that is a pretty big deal." Every PI Planning ceremony, every dependency board, every RTE follows from that one decision: leave the structure alone, manage the coordination instead. That is not a design flaw. It is a trade-off. The question is whether you want to keep paying for it.

The Pentagon agrees

The U.S. Department of Defense is the world's largest technology buyer. In 2020, it issued DoDI 5000.87, a distinct software acquisition pathway built around small cross-functional teams, iterative delivery, and DevSecOps. Not scaled coordination frameworks. The Department's first Chief Software Officer publicly discouraged SAFe adoption. His critique was structural: coordination frameworks add process layers that slow down the delivery they are supposed to accelerate.

The convergence matters. Commercial organizations that broadened their product definitions and the world's largest military bureaucracy reached the same conclusion independently, from opposite directions. When the world's largest technology buyer builds its software pathway around small teams rather than scaled coordination, the question is no longer which framework to adopt. It is whether the coordination problem is inherent to the work, or whether the organizational structure created it.

Three questions for Monday

All that coordination infrastructure exists to manage demand that the organizational structure creates. So the question is not how to manage it better, but whether to keep creating it.

Try three questions at your next planning event:

Would these dependencies exist if one team owned the feature end-to-end? If the answer is no, the dependencies are structural artifacts of how product boundaries were drawn. They are not inherent properties of the work.

Would this coordination role exist if the product definition were broader? If the answer is no, the role manages a boundary that was drawn in the wrong place. The role is not the problem. The boundary is.

When work does not finish in the time box, does the system treat it as a learning opportunity or as a missed commitment? Broadening a product definition is messy. Teams slow down before they speed up. If the system punishes every dip in velocity, nobody will propose the structural change that causes the dip.

The first two reveal whether the problem is structural. The third reveals whether anyone can act on the answer.

Next quarter, 125 people will be in a room for two days, mapping the same dependencies on the same board. The board will be full. The ceremony will work. And the product boundaries that created every dependency on that board will still be exactly where they were.