The Architecture of Complexity
The companion paper to Simon's books already in the library.
Here Simon argues that complex systems evolve faster when they are hierarchically modular — "nearly decomposable" — because subsystems can evolve independently without destroying the whole.
This is the theoretical foundation for microservices, team topologies, and every modern argument about loose coupling, written three decades before any of those terms existed.
Forty pages that explain more about organisational design than most contemporary books on the subject.
For product people the paper settles a recurring debate: modularity is not an architectural preference but an evolutionary necessity — systems that lack it do not survive long enough to matter.
Central argument
Simon argues that complexity in nature and human organizations is not random but hierarchical: complex systems are composed of stable intermediate sub-assemblies arranged in nested levels, a structure he calls 'near decomposability.' His central finding is that this architecture is not coincidental — it is the result of evolutionary selection, because hierarchically modular systems can recover from disturbances and evolve much faster than non-hierarchical ones, since subsystems fail and adapt locally without cascading collapse across the whole. The corollary is that understanding any complex system — biological, social, or organizational — requires identifying its hierarchical modules before attempting to analyze or redesign it.
Critique
Simon's model implicitly assumes that the boundaries between subsystems can be drawn with reasonable clarity, but in practice — and especially in digital organizations — the hardest problems arise precisely where decomposition is ambiguous or contested. The framework offers limited guidance on how to find the right modularity, not just why modularity matters; it describes the winning structure after evolution has done its work, but is largely silent on the cost and politics of decomposing a system that was never modular to begin with. There is also a risk that the theory naturalizes hierarchy as an evolutionary inevitability, which can obscure cases where flat or network-like structures outperform hierarchical ones in sufficiently stable environments.
Why it matters for product
For a CPO, Simon's paper reframes team topology decisions as a systems-survival question rather than a preference: a product organization without clear module boundaries — where every team change or API contract breaks something elsewhere — is not just inefficient but evolutionarily fragile, unlikely to adapt fast enough to survive competitive pressure. The insight about near-decomposability has direct implications for platform strategy: a platform is not infrastructure for its own sake but the substrate that makes independent subsystem evolution possible, which means platform investment should be justified by the rate of change it enables in product teams, not by cost consolidation alone.