Before reorganizing who reports to whom, ask a prior question: what should the organization be optimized to do, and what unit of organization is the right container for that work?
This sounds basic. It is not. Most redesigns jump straight to reporting lines and skip it. The result is a new structure that optimizes the wrong unit, or optimizes the right unit for the wrong problem.
Oliver Williamson's transaction cost economics offers a useful frame: organizations exist where the cost of coordinating work through market mechanisms exceeds the cost of coordinating it through hierarchy. James March extended this with a decision-making lens: organizations must balance exploiting known capabilities against exploring new ones, and different balance points call for different structures.
The practical question is not "centralized or decentralized?" It is "what is this work, and what structure fits it?"
What Makes an Organizational Unit the Right Unit
An organizational unit is the right unit when:
The work has a coherent identity. The team or function does a type of work that has a recognizable boundary — it takes inputs, applies a capability, and produces outputs. When you ask what a team does, you get a coherent answer, not a list of things that seem related because they happened to end up in the same reporting line.
The owner has authority over the critical variables. The person accountable for the unit's outcomes has meaningful control over the inputs, decisions, and tradeoffs that determine those outcomes. If a team is accountable for quality but cannot control hiring, tooling, process, or priorities, the accountability is theatrical.
The interface with other units is explicit. Handoffs are named, owned, and measured. The seam is a coordination point, not a gap where work goes to die.
The coordination cost is worth the integration benefit. Sometimes keeping two functions together is worth the coordination overhead. Sometimes it is worth the duplication cost of separating them. This is a real tradeoff, not a rhetorical question.
A Concrete Example: Launch Readiness
A company redesigns its product launch model three times in two years.
Version 1: Functional model. Product owns the roadmap, engineering owns delivery, marketing owns messaging, sales owns enablement, support owns readiness. Coordination happens through a launch committee.
Version 2: Integrated model. One VP Product-Marketing-Sales, one launch owner with P&L, consolidated launch team. Solves the coordination problem. Creates a bottleneck because the senior integration layer cannot absorb the volume of cross-functional decisions.
Version 3: Federated model with explicit operating protocol. Segment-aligned teams own end-to-end launches for their segment. A shared platform team handles shared infrastructure, data, and design system with published SLAs. A cross-functional review forum handles segment conflicts and resource allocation with named decision rights and SLA.
The third version is not more sophisticated structure. It is better unit design: the segments are the right units for customer-facing coordination, the platform team is the right unit for shared capability, and the review forum is a coordination mechanism with teeth, not a committee.
The tell: in version 3, when a launch slips, everyone can name the owner, the decision that stalled, and the handoff that failed. In versions 1 and 2, the answer was "we need better alignment."
The Tradeoff
The right organizational unit is not the one that eliminates all coordination. Every seam creates coordination cost. The question is whether the benefit of the boundary exceeds the cost.
Separate units allow different contexts, different incentives, different cadences, and different expertise. They also create handoffs, latency, duplicated capability, and translation overhead.
Integrated units reduce seams but create monoculture, bottleneck risk, and context loss.
The answer is almost never obvious, and it changes as the organization matures. Revisit the unit design when the coordination costs visibly exceed the integration benefits — not when the current structure feels inconvenient.
