The Spotify Model: What to Copy, What to Leave — An HBS-Style Case
The most-copied and most-misunderstood org model of the last 15 years. A case-study walkthrough of squads, tribes, chapters, and guilds: what worked at…
On this page▾
- The 'Spotify model' is a 2012 description by Henrik Kniberg of one snapshot of Spotify's then-current org. Spotify itself has moved on multiple times.
- Squads (small autonomous teams) and Guilds (cross-org communities of practice) generally travel well.
- Tribes (groupings of 40–150 squads) and Chapters (people-management lines across squads) often fail in copy-paste form.
- What broke: cross-squad dependencies, inconsistent quality, lonely chapter leads, and a measured loss of strategic alignment Spotify itself wrote about (the 'Failed #SquadGoals' essay).
- Use the vocabulary, but design for your own constraints. Treat the model as a case study, not a blueprint.
In 2012 Henrik Kniberg, then a coach at Spotify, published a short paper titled 'Scaling Agile @ Spotify' with cheerful cartoons of squads, tribes, chapters, and guilds. It became, by some distance, the most-copied org-design artefact in the history of software. ING restructured 3,500 people around it. Hundreds of companies followed. There was only one problem: Spotify itself had already moved on and never claimed the model was finished, generalisable, or even fully working. This article is the case study: what the model was, what worked, what broke, what Spotify itself wrote when the cracks appeared, and what an engineering org should actually take from the experience.
Why this case is in the playbook
Every engineering HRBP and CTO will, sooner or later, hear 'let's do the Spotify model'. The right response is neither 'great' nor 'no' — it is to know the case well enough to ask the right follow-up. This is also one of the cleanest examples in software of the cargo-cult adoption pattern: a snapshot of one company's evolving practice gets treated as a permanent template, with predictable failure modes.
What the model actually is
| Unit | Description | Size | Purpose |
|---|---|---|---|
| Squad | Small autonomous team responsible for a feature area | 6–12 people | Ship product. Own the pager. Pick their own way of working. |
| Tribe | Group of squads working in a related area | 40–150 people | Co-located in one office area. Share planning rhythm. |
| Chapter | People-management line across squads within a tribe | 5–15 reports per chapter lead | Career, hiring, performance for one discipline (e.g. backend engineers in the Music Tribe). |
| Guild | Voluntary cross-org community of practice | Any size | Share knowledge across tribes (e.g. iOS guild, frontend guild). |
An engineer belongs to a Squad (their team) and a Chapter (their discipline). Their manager is their Chapter Lead, not their Squad's lead. This is the structural feature most copies get wrong — they keep squads but accidentally re-create traditional reporting lines, losing the model's central innovation.
What worked
- Squads gave teams real autonomy over technical decisions and ways of working. This produced measurable engagement gains in early years (Spotify reported high developer NPS during 2012–2015).
- Guilds were a low-cost knowledge-sharing mechanism. The iOS Guild, Backend Guild, and equivalents at copying companies generally outlast every other element of the model.
- The 'aligned autonomy' philosophy — strategic alignment from leadership, tactical autonomy in squads — articulated something real and useful.
- Naming the units (squad, tribe, chapter, guild) gave the org a shared vocabulary that survived staff turnover.
What broke
By 2016–2017, evidence of trouble was public. Jeremiah Lee, a former Spotify product manager, published 'Failed #SquadGoals' (2020) — one of the most-read critiques. Spotify's own engineering blog acknowledged successive restructurings. The recurring failures:
| Failure | What it looked like | Root cause |
|---|---|---|
| Cross-squad dependencies | Single features required 4+ squads' work; coordination overhead consumed quarters | Squads optimised for local autonomy, not end-to-end customer journeys |
| Inconsistent quality | Each squad chose its own tooling, framework, deployment pipeline; new hires re-learnt everything per squad | Autonomy without a 'paved road' default |
| Lonely chapter leads | Chapter leads managed 8–12 engineers spread across squads they had little day-to-day visibility into | People management requires daily context; the matrix structure starved them of it |
| Strategic drift | Strategic alignment was assumed; in practice it relied on a small number of senior leaders maintaining the connective tissue manually | No formal mechanism for cross-tribe strategy beyond exec-staff meetings |
| Tribes hit Dunbar limits | At 150+ people the tribe stopped functioning as a community; informal trust networks fragmented | 150 is roughly Dunbar's number; the model put the unit at the breaking point by design |
Companies that copied the model in 2014–2018 usually adopted the structure but not the underlying culture (Spotify's hiring bar, its leadership coaching investment, its existing high-trust environment). The skeleton without the muscles often produced worse outcomes than the previous structure.
What Spotify did next
Spotify has restructured several times since 2016, including significant reorganisations in 2018, 2020 (during pandemic remote shift), and around the 2023 layoffs. The exact current shape is not public, but engineering bloggers from Spotify have written about: stronger platform groupings, clearer end-to-end ownership of customer journeys, retained guilds, and a less rigid tribe structure. The most honest summary: Spotify treats its org as a continuous experiment, not a finished model — and that itself is the part most worth copying.
What to copy, what to leave
- Small autonomous teams with end-to-end ownership of a slice of the product
- Guilds / communities of practice
- 'Aligned autonomy' as a strategic principle
- Quarterly health-check survey (the 'Squad Health Check Model' is a published, useful artefact)
- Rigid tribe structure at exactly 40–150 — design tribes to your domain instead
- Chapter leads as the only people manager — often better to keep the team lead as manager and use chapters as discipline communities
- 'Each squad picks its own stack' — usually too costly past ~50 engineers; provide a paved road default
- Copy-pasting the org chart without copying the hiring bar and leadership investment
Implementation playbook
- Read the original Kniberg paper and the Jeremiah Lee critique together. Make both required reading for your leadership team.
- Map your current org against the four units. Which exist informally already?
- Decide explicitly: are people managers your team leads, or your chapter leads? Both are valid; the worst choice is leaving it ambiguous.
- If adopting guilds, fund them: 10% time, an internal organiser, a budget for events. Unfunded guilds die.
- Adopt the Squad Health Check survey (or equivalent) and run it quarterly. Report results to engineering leadership.
- Plan to revisit the structure every 12 months. Spotify itself didn't keep it static; neither should you.
Implications for HR
- Chapter leads need explicit training in remote/matrix people management. They will see their reports less than a traditional EM and must compensate.
- Performance reviews must aggregate input from squad leads and chapter leads. Build a clear 360 process or quality drifts.
- Career paths must be defined at the chapter level (discipline) and the squad level (impact). Both feed into promotion packets.
- Hiring loops should include both a squad partner and a chapter partner; otherwise the matrix breaks at onboarding.
Monday-morning checklist
- Read Kniberg (2012) and Lee (2020). Share both internally.
- Identify any 'tribe-shaped' unit in your org. Is it functioning, or just labelled?
- Fund one guild this quarter as an experiment. Measure attendance and outputs at 6 months.
- Make the people-manager line explicit and consistent across the org.
- Schedule a quarterly health-check survey.
FAQ
Frequently asked questions
Should we use the words squad/tribe/chapter/guild?
Only if they map to real, distinct things in your org. Otherwise use plain words ('team', 'group', 'community') — labels without distinct meaning create cynicism.
Is the Spotify model dead?
The 2012 snapshot, yes. The underlying ideas (small autonomous teams, communities of practice, aligned autonomy) are alive and well — usually under the Team Topologies vocabulary now.
What about chapters vs Team Topologies?
They are compatible. Team Topologies focuses on team shape; chapters focus on discipline-based people development. Many orgs run both.
Does this work for non-product engineering (infra, ML, data)?
Less well, because those teams are often platform or complicated-subsystem types rather than stream-aligned squads. Team Topologies vocabulary fits better there.
References
- Kniberg & Ivarsson — Scaling Agile @ Spotify (2012) — Crisp
- Jeremiah Lee — Failed #SquadGoals (2020) — jeremiahlee.com
- Spotify Engineering — Squad Health Check Model — Spotify
- Skelton & Pais — Team Topologies (book) — Team Topologies
Read next
All playbooksMatthew Skelton and Manuel Pais's Team Topologies — stream-aligned, platform, enabling, complicated-subsystem — is the most-cited org design model in modern…
Engineering organisations break in predictable ways at predictable sizes. A field-tested maturity model for HR and engineering leaders, with the symptoms…
Tech debt has a sibling no one names: org topology debt — the compounding coordination cost of teams whose boundaries no longer match the system they own.