Case in point: When Amazon moved from a functional engineering structure to a distributed service-oriented architecture in the early 2000s, the driver was not philosophical preference — it was information cost. A single engineering organization building a monolithic e-commerce platform had become a coordination bottleneck: every significant technical decision required navigating the same queue of competing priorities. The split into autonomous services, each with its own P&L accountability, was a transaction cost solution. Each team became a bounded optimization unit. The cost was duplicated capability and integration risk. The benefit was dramatically reduced decision latency and internal coordination overhead. This is organizational economics in practice.

The structure that works at 30 people usually breaks at 300. Not because everyone got worse, and not because the culture mysteriously decayed. The information dynamics changed.

At small scale, founders can hold context in their heads, decisions can happen in the room, and informal coordination can cover structural gaps. At larger scale, that model turns into founder bottlenecks, manager translation layers, duplicated functions, platform queues, strategy fragmentation, and local optimization.

Scale does not make organization design more important. It makes bad design more expensive.

Why Reorganizations Fail

Most reorganizations change the boxes without changing the mechanics.

The announcement creates a temporary pulse. New leaders enter the room. Priorities get renamed. People wait to see who has power. For a few months, behavior changes because attention has changed.

Then the old patterns reassert themselves if decision rights, information flows, incentives, operating cadence, and team interfaces remain the same. The labels changed. The system didn't.

Reorgs also carry real costs:

  • temporary productivity drops while people relearn paths
  • political uncertainty about winners and losers
  • talent loss from people who see reduced scope or status
  • shadow structures that preserve old workflows underneath new reporting lines
  • delayed decisions while everyone waits for the new model to settle
  • priority churn as leaders re-justify their portfolios

These costs may be worth paying. But they are costs, not footnotes.

What Good Scale Management Looks Like

Explicit operating model design. How does work start, get funded, get staffed, get reviewed, get escalated, and get stopped? At scale, this cannot live in founder memory.

Deliberate team topology. Some teams should own customer-facing outcomes. Some should be platforms or shared services. Some should be embedded. The interfaces between them need design, not hope.

A strong manager layer. Promote and evaluate managers on prioritization, talent density, cross-functional judgment, and their ability to reduce ambiguity without hoarding decisions.

Instrumentation. Track decision latency, handoff count, escalation frequency, meeting load, priority churn, and rework rate. Scale problems should show up in operating data before they become all-hands complaints.