Spotify 2012: squads, tribes, chapters and guilds scale agility without losing autonomy

In late 2012 Spotify was six years old, had roughly 15 million active users, and its engineering organization had grown from about 30 people to hundreds of developers in 30 teams across four cities and three time zones. The question every fast-growing product company hits: how do you keep the speed of a small team when you have dozens of them?

Kniberg and Ivarsson's answer was a paper, 'Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds,' written as a snapshot of how Spotify actually worked. The smallest unit, the squad, is a cross-functional team that sits together and owns a slice of the product — it chooses its own way of working, from Scrum to Kanban, and is encouraged to spend about 10% of its time on hack days. Squads have no appointed leader, only a product owner who prioritizes, and an optional agile coach.

Squads are grouped into tribes of fewer than 100 people — sized by the Dunbar number — each with a tribe lead who cultivates the habitat rather than commands the work. Two horizontal layers reconnect people across squads: chapters group people with the same skill inside a tribe (a chapter lead handles development and salary), while guilds are company-wide communities of interest such as web tech or testing. The authors called it a matrix — but one weighted toward delivery: vertical for 'what', horizontal for 'how'.

Spotify never claimed the model was finished; the paper said it was a snapshot of a journey in progress. In March 2014 Kniberg published the first of two short animated videos, 'Spotify Engineering Culture,' on Spotify's engineering blog, noting again that what the video showed was 'mostly true for most squads most of the time.' The idea spread far beyond the company — the blog post alone lists translations into French, Spanish, Russian, Japanese, Chinese and Portuguese.