CompanyGraph
Why organizational complexity creates work that may not appear in a unit cost, and how modularity and decision rights can keep that work manageable.
Complexity is not the same as headcount
A company with more products, sites, suppliers, regulators, and software systems has more dependencies to manage. But it does not need a meeting between every pair of employees. Teams use standards, interfaces, hierarchy, planning systems, and local authority to avoid direct coordination where possible.
Coordination cost is the work required to make interdependent actions fit: discovering who has the relevant information, deciding which version is authoritative, resolving conflicts, checking that a change propagated, and correcting errors. It can appear as meetings and managers, but also as duplicated inventory, delayed approvals, rework, integration testing, and time spent waiting for another unit.
What the concept measures - and what it does not
“Coordination cost” is an organizational-economics concept rather than a single accounting line. A manager can observe elapsed time, handoffs, defect rates, duplicated effort, approval layers, or the cost of integration work. Those observations are proxies for the underlying effort; they do not isolate its cause automatically.
| Observation | Possible signal | Alternative explanation |
|---|---|---|
| Longer approval or release time | More dependencies or unclear authority | Regulatory review, deliberate quality control, or a temporary bottleneck |
| Rework and defects at interfaces | Information not crossing a boundary reliably | Bad design, supplier capability, or changing requirements |
| More managers or meetings | Greater integration effort | Growth in customer service, safety, or specialist work |
| Productivity decline after expansion | Complexity or rigidity costs | Demand, labor, technology, or incentive changes |
Dessein and Santos model a trade-off between specialized tasks and the need for communication. Their work helps explain why firms may shift between rigid specialization and broader roles with more horizontal communication. It does not imply that one structure is optimal for every task.
Interfaces are where the bill arrives
Coordination becomes expensive when one activity cannot be completed without a precise condition in another. A software release depends on an API version; a factory schedule depends on a supplier's approved part; a hospital procedure depends on a patient record and a sterile instrument; a construction pour depends on design, material, weather, and inspection.
Modularity reduces the amount of information that must cross an interface by standardizing what each module promises. It does not remove the need for integration. A change that crosses modules can still require testing, version control, training, and a decision about who pays for the work.
Boeing 787: distributed design under integration pressure
Boeing's 787 program is a documented case of a complex product whose design and production depended on a global supplier network. Boeing's 2010 filing describes extensive coordination and integration with supplier partners, exotic materials, flight-testing delays, supplier challenges, and a first-delivery delay to the third quarter of 2011. That filing reports several contributors; it does not establish that coordination cost alone caused the delay.
The mechanism is visible in the dependency: a supplier could complete its assigned structure while Boeing still had to verify interfaces, assemble a conforming aircraft, complete testing, and resolve information that did not match across organizations. A more integrated design might have reduced some handoffs but increased internal capital and management requirements. A more modular design can lower local coordination while making late system changes harder.
When complexity becomes rigidity
Extra coordination can slow a change until the business misses a customer window or continues using a known-bad process. Employees may avoid escalation because responsibility is divided, while local optimization worsens the system. Complexity can also create resilience: specialized teams, redundancy, and formal checks may be essential where failure is costly.
- Make interfaces explicit. Define inputs, outputs, versions, tolerances, and owners.
- Push decisions to the boundary. Local authority can reduce delay when the decision does not threaten the whole system.
- Integrate where dependencies are dense. Cross-functional teams and frequent testing matter when changes interact.
- Measure correction, not meetings. Look at rework, escaped defects, cycle time, and time to resolve a dependency.
- Revisit the architecture. If a module repeatedly requires exceptions, either redesign the interface or recognize that the system is integrated in practice.
Coordination cost is not an inevitable tax on growth and not a reason to prefer small firms automatically. It is the work required to preserve compatibility across boundaries. A company remains scalable when its architecture makes that work visible, affordable, and correctable before a local problem becomes a system failure.