Spotify's Famous Org Model Was a Snapshot, Not a Blueprint. The Industry Copied It Anyway.

In October 2012, two agile coaches published a thirteen-page PDF describing how one fast-growing music company organized its engineers. It introduced a vocabulary that would conquer the corporate world: squads, tribes, chapters, guilds. It described roughly 30 teams — about 250 people across three cities — and it was hosted not on Spotify's website but on the blog of a Swedish consultancy called Crisp.¹ Within a few years, banks, insurers, telecoms, and retailers across the planet would reorganize tens of thousands of employees around its diagram. They were copying a system that, by the candid admission of the people who wrote it down, was not actually running.

The official story is that Spotify invented a brilliant new way to scale software teams, proved it worked, and shared the recipe with the world. Almost every part of that is wrong. Spotify did not invent it, did not claim to, did not have it fully working, and would spend the next several years quietly walking away from it — all while the rest of the industry rushed to install it.

A description got mistaken for a prescription

Read the whitepaper as what it actually is — a snapshot, not a spec — and the whole legend wobbles. The document itself says the squad-and-tribe structure 'was introduced gradually over the past year, so people are still getting used to it,' and it closes with the line that every consultant who later sold a 'Spotify transformation' chose to forget: 'today's solutions give birth to tomorrow's problems. So stay tuned, the story isn't over.'⁸ That is not the voice of a finished framework. It is the voice of a company narrating its own growing pains in real time. The authors weren't selling certainty; they were documenting a work in progress and saying so.

Here is the part almost everyone gets backwards. Kniberg did not invent the model and never claimed to. He was employed by Crisp, an outside agile consultancy; his co-author, Anders Ivarsson, was an organizational coach embedded at Spotify.¹² They were observers writing down what they saw, not architects designing a new machine. The diagram the world treated as a master plan was really field notes — and the field was still being plowed.

The system the industry copied was never fully switched on

The most damning evidence comes from inside the building. A former Spotify employee who joined in 2017 wrote a first-hand account flatly stating the squad model 'was only ever aspirational and never fully implemented,' and that what he actually found was 'organizational chaos' as leadership incrementally transitioned to more traditional management structures.³ He quotes one of the agile coaches who helped produce the whitepaper, Joakim Sundén, with a sentence that should end the debate: 'Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation.'³ The famous document was always part wish. The industry mistook the wish for an inventory.

And the structure had a real, mechanical flaw that explains why it strained as the company grew. Strip away the friendly vocabulary and the chapter system did something specific: it made engineers report to a manager outside their own squad — a chapter lead organized by specialization across a whole tribe. So a single squad with backend, web, and mobile engineers could answer to three different engineering managers, none of whom owned delivery of the squad's actual product.⁷ A simple technical call could climb three separate escalation ladders before anyone with authority caught it. The org chart that looked liberating on a slide produced, in practice, accountability that pointed everywhere and therefore nowhere.

Even Spotify's own people kept saying: don't copy this

The strangest thing about the Spotify model's spread is how loudly the source warned against it. A Spotify director of engineering is on record saying, 'We didn't invent this model… This article is only a snapshot of our current way of working — a journey in progress, not a journey complete. By the time you read this, things have already changed.'⁶ Co-author Ivarsson grew openly alarmed at his own creation's afterlife: 'It worries me when people look at what we do and think it's a framework they can just copy and implement… We are really trying hard now to emphasize we have problems as well.'⁴ The people closest to the model spent years shouting the disclaimer. The industry read past it to the diagram, because a diagram is buyable and a disclaimer is not.

But it must have worked — look at the products

The fair objection runs like this: Spotify shipped beloved products and grew into a global giant, so the structure must have been doing something right. Maybe the model was messy, but messy and effective. It is a reasonable instinct, and it is exactly the trap. Nobody has produced a primary source — no financial filing, no official company release — drawing a causal line from the squad structure to any specific launch. The connection is asserted by secondary commentators reasoning backward from success, which is the oldest error in management folklore: a company wins, so whatever it was doing at the time gets crowned the cause. Plenty of fast-growing companies with conventional org charts shipped great products too. And there's a deeper irony — strip the Spotify model of its invented words and you are left with a matrix structure of cross-functional teams, a well-understood form that predates the whitepaper by decades. The genuinely novel thing here was the marketing, not the management.

The squad model is the most successful product management consulting never meant to sell. Two coaches wrote down one company's hopeful, half-built way of working, labeled it a journey in progress, and watched a credulous industry laminate it into law. The lesson isn't that the model was bad — parts of it were genuinely thoughtful. The lesson is what happens when a description gets read as a prescription: a candid document about one company's growing pains became a universal doctrine, and stayed doctrine long after its authors begged people to stop. The most valuable sentence in the whole whitepaper was the one nobody quoted: the story isn't over. It never is. That's precisely why you can't copy the ending.