Does the "Spotify model" exist?

What the famous videos and papers really said

In 2012, Henrik Kniberg and Anders Ivarsson published a document that would become legendary, titled Scaling Agile @ Spotify. Shortly after, two animated videos about the company's engineering culture appeared and gathered millions of views. The terms we repeat today without thinking came from there.

It's worth rereading that document carefully, because it says things that most people who cite it seem to have forgotten. Its authors explicitly warned that they were describing a snapshot of a specific moment, not a finished formula. They acknowledged that Spotify itself was constantly evolving, that many of those practices still didn't work very well, and that by the time anyone read the text, the way they worked would probably have changed. In other words, they never presented it as a replicable model. They presented it as an honest, provisional snapshot of an organization that was experimenting.

The distinction is not a minor nuance. A model is something designed to be reproduced. A snapshot is a record of an instant that has already passed. For more than a decade we have treated as an instruction manual what its own authors described as a postcard.

From snapshot to dogma

How does a provisional description become organizational dogma? The mechanism is well known and is not unique to Spotify. Organizations seek certainty, and a model with a proper name, catchy vocabulary, and the endorsement of an admired company offers exactly that. Copying the structure of someone who has succeeded seems like a shortcut to that same success.

The problem is that this reasoning confuses correlation with cause. Spotify grew and succeeded, and at the same time it was organized into squads and tribes. From there to concluding that it was organized that way and therefore succeeded is a huge logical leap. The structure may have helped, it may have been irrelevant, or the company may even have succeeded despite certain aspects of it. What we do know, because the company itself later acknowledged it, is that this design generated serious coordination and accountability problems that had to be corrected over time.

Jeremiah Lee, who worked inside Spotify, wrote in 2020 a widely cited analysis in English and almost absent in Spanish, in which he explained that the model as it became popular never fully worked, even inside the company itself. He described real difficulties in collaboration between squads, a confusing tension between autonomy and alignment, and a gap between the widely disseminated theory and daily practice. The uncomfortable conclusion is that many companies enthusiastically adopted an idealized version of something its own creator was already dismantling.

The mistake of copying structures instead of solving problems

Behind the fascination with the Spotify model lies a deeper and more general mistake, one that affects almost every attempt to imitate successful organizations. We copy another's visible solution without understanding the problem that solution was meant to solve in its context.

An organizational structure is not a neutral template that can be transplanted. It is a response to a specific set of circumstances: a particular product, a market, a history, available talent, a prior culture, a moment of growth. Spotify's squads made sense within a digital product company, with engineers of a particular profile, in a specific expansion phase, and with a culture that already valued autonomy. Moving that shell into a bank, an insurance company, or a public administration, with a different history, different incentives, and a different culture, and expecting the same result, is like putting on an athlete's jersey expecting to run just as fast.

Melvin Conway formulated in 1968 an observation that illuminates this point well. Organizations tend to design systems that reproduce their own communication structure. Changing the org chart without changing how people communicate and collaborate produces, at best, a cosmetic change. New names are layered over old dynamics, and the tribe is nothing more than the old department with a more modern label.

What copying leaves out

When an organization adopts Spotify's jargon, it usually imports what is visible and leaves out what is essential, which happens to be the hardest thing to copy.

What is visible are the boxes on the org chart: squads, tribes, chapters, guilds. They are what can be drawn on a slide on Monday morning. What is essential, by contrast, is everything that made those boxes work in their original context. We are talking about a high level of trust, real tolerance for error, genuine autonomy backed by whoever had the power to grant it, a professional profile used to making decisions, and a culture built over years. None of that fits on a slide or can be implemented by decree.

The usual result is what some have called agile theater. The company has squads that decide nothing, chapters that share no real knowledge, and guilds that are forgotten mailing lists. The structure is there; the substance is not. And since the structure was what was promised, it is hard to admit that what was missing was precisely what could not be copied.

What this says about our relationship with frameworks

The critique of the Spotify model would be incomplete if it stopped at Spotify, because the phenomenon is broader. The agile community has a recurring tendency to look for the definitive framework, the formula that will finally solve organizational complexity. First it was Scrum applied literally, then SAFe with its promise of scaling, then the Spotify model, and the list goes on. Every so often a new packaged answer appears, promising to spare us the uncomfortable work of thinking for ourselves.

Dave Snowden, with his Cynefin framework, has spent years reminding us of something we should keep in mind more often. Organizational problems usually belong to the complex domain, where there are no universal good practices because the relationship between cause and effect is only understood in hindsight. In that terrain, copying another's solution is especially risky, because what worked there emerged from conditions that do not repeat. What is needed is not to replicate, but to experiment, observe, and adapt.

This connects with an idea that, at Scrum Manager, sits at the foundation of how we understand organizational agility. Tools like AgiLevel do not propose a single model to imitate; instead, they help an organization evaluate its own practices and cultural values without prescribing a specific framework. The difference is fundamental. Rather than asking "How is the admired company organized?", the useful question is "What real problem do we have, and what design would solve it in our context?"

The AI context: the new model to copy without understanding

It is worth noting that this pattern is not a thing of the past; it is repeating right now with artificial intelligence. Stories are starting to circulate about companies that have "transformed the way they work with AI," and with them comes the temptation to copy their recipes: this team structure, this way of integrating agents, this new role.

The risk is identical to that of the Spotify model. We will take the provisional snapshot of an organization that is experimenting, turn it into a model, and transplant it into contexts that have nothing to do with it, expecting the same result. And since AI evolves even faster than agility did in 2012, the snapshot will become obsolete even sooner. The lesson the Spotify model should have taught us becomes more urgent, not less: don't copy anyone's structure; understand your problem and design for it.

Perhaps the greatest tribute we can pay to what Spotify shared in 2012 is not to imitate it, but to imitate its attitude. Those people were experimenting, they made mistakes, they adjusted, and they had the honesty to tell it as work in progress. What we did with their story, freezing it into a model and selling it as a formula, runs directly against what they were doing.

Agility was never about copying someone else's answer. It was about developing the capacity to find your own. And that capacity is not imported with a new org chart or a fashionable vocabulary. It is built slowly, in the context of each organization, by solving the problems you have, not the ones someone else had.

And in your organization? Have you ever adopted an outside model out of admiration rather than diagnosis? What happened to the substance when the structure arrived?

References

• Cagan, M. (2024). Transformed: Moving to the Product Operating Model. Wiley.
• Conway, M. E. (1968). How Do Committees Invent?. Datamation, 14(4), 28-31.
• Denning, S. (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.
• Lee, J. (2020). Failed #SquadGoals: Spotify doesn't use "the Spotify model" and neither should you.
• Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
• Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing Agile. Harvard Business Review, 94(5), 40-50.
• Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
• Snowden, D. J., & Boone, M. E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, 85(11), 68-76.

If you want to assess your organization's real agility without starting from an imported model, AgiLevel (agilevel.com) is Scrum Manager's diagnostic tool designed for exactly that.