The scenarioBy 2012, Spotify had grown from a small Swedish startup to a company with hundreds of engineers distributed across multiple cities. The challenge wasn't technical — it was organisational. How do you coordinate hundreds of engineers building interdependent features without creating the bureaucratic overhead that kills the speed that made you successful? Henrik Kniberg and Anders Ivarsson, working as agile coaches inside Spotify, documented the company's approach in their widely circulated 2012 white paper on Spotify's engineering culture. What they described, though they didn't use the Cynefin label explicitly, was a system that treated different types of engineering work as belonging to different domains — and applied different coordination mechanisms accordingly.
How the tool appliedSpotify's "Squad" model gave small, autonomous teams (6–12 people) ownership of specific features or components. Squads operated in the complex domain: they were building products for users whose behaviour couldn't be predicted, so they ran rapid experiments, shipped MVPs, and iterated based on real usage data. Probe, sense, respond. But the infrastructure those squads depended on — shared platforms, data pipelines, core APIs — operated in the complicated domain. These systems needed expert architecture, careful analysis, and coordinated releases. Spotify handled this through "Chapters" and "Guilds" — cross-squad groups of specialists (backend engineers, data scientists, QA) who maintained shared standards and made expert-driven decisions about platform architecture. The clear domain showed up in operational processes: deployment pipelines, incident response protocols, on-call rotations. These followed documented best practices. No experimentation needed.
What it surfacedThe insight was that a single coordination model — whether top-down planning or bottom-up autonomy — would fail because different parts of the engineering organisation faced fundamentally different types of problems. Squads needed autonomy because product development is complex. Platform teams needed coordination because infrastructure is complicated. Operations needed standardisation because deployment is clear. Applying one approach across all three would either strangle product innovation with unnecessary process or destabilise infrastructure with unnecessary experimentation.
