Spotify model

Origin

Henrik Kniberg and Anders Ivarsson (description); Spotify engineers (practice), 2012

Level

301 · Advanced

Fits

Scale-up, Enterprise

Time to apply

two to four weeks to map dependencies and pilot one cross-functional team

What you need

a list of the products or services your teams build, and which teams depend on which · a leader who can give one team a long-term mission and the authority to ship · managers willing to give up some control over how the work is done

The Spotify model is a description of how Spotify organised its engineering teams around 2012. Henrik Kniberg and Anders Ivarsson, two Spotify staff at the time, set it out in an October 2012 paper, Scaling Agile @ Spotify. Their opening disclaimer says they did not invent the model and that the paper is a snapshot of a way of working still changing. Spotify did not coin the label “Spotify model”, Sundén said later. Kniberg wrote in 2015 that it was never meant as a generic framework, only an example of how one company worked.

What are squads, tribes, chapters and guilds?

Squads are the delivery teams, tribes group related squads, chapters connect people with the same skill inside a tribe, and guilds are open communities across the company. All four terms come from the 2012 paper, which described a company of over 30 teams in three cities that had grown from 30 to 250 people in tech in three years.

A squad has a product owner who sets priorities but no formal leader, and it can choose its own method. The paper gives no squad size; the Scrum Guide says a Scrum Team is typically 10 or fewer people. The paper says some squads used Scrum sprints, some used Kanban and some mixed the two. The authors called the result a matrix, with squads as the vertical dimension for what to build and chapters as the horizontal dimension for how to build it well. They wrote that the matrix was weighted towards delivery.

Why did so many companies copy it?

Companies copied it because it offered a concrete picture of autonomy at scale at a time when few were available, and because Spotify published more of it. Two animated videos on engineering culture followed in March and September 2014. Kniberg described them as a journey in progress, mostly true for most squads most of the time.

A well-documented case is ING Netherlands. A McKinsey interview published in January 2017 reports that ING began in June 2015 and ended up with about 350 nine-person squads in 13 tribes, with Spotify as one inspiration. The ING executives say they gained speed and engagement. We found no independent measurement in that source. ING also adapted the idea, and Kniberg wrote in 2015 that companies which copied it adapted it to their context.

What did people who worked at Spotify say about it?

Several people who were there said it described an aim. Joakim Sundén, an agile coach at Spotify from 2011 to 2017, gave a talk titled You can do better than the Spotify model at Agile2017, and said in a 2017 InfoQ interview that Spotify never coined the term and was far from an agile nirvana. He listed gaps: engineering practices such as test-driven development were uncommon, some squads skipped reviews of their plans, and Kanban teams rarely used WIP limits. Anders Ivarsson, the paper’s co-author, said in a 2016 podcast that it should not be treated as a template, according to the show notes, which add that alignment gets harder as the organisation grows. Jason Yip, a coach at Spotify, listed his own problems, including large cross-tribe initiatives that were not done well.

The sharpest account is Jeremiah Lee’s 2020 essay, written after he had worked at Spotify. He argues that the model was aspirational and never fully implemented, that autonomy without company priorities and accountability created friction, and that chapter leads had little responsibility for delivery. It is one person’s account, and he cites public statements by Spotify staff for most of it. Bain’s Michael Mankins and Eric Garton made a related general point in Harvard Business Review: autonomy can spur involvement, but unchecked it can produce ambiguity and inefficiency.

What does peer-reviewed research say?

The research that exists is mostly by Darja Smite, Nils Brede Moe and colleagues, and a Spotify employee, Marcin Floryan, is a co-author of several of the papers. Read it with that in mind. It supports parts of the model and shows that others changed.

On guilds, a study of four Spotify guilds used 11 interviews and a survey of 125 members. It found guilds gave people more perspectives on problems, coordination across units and a sense of belonging. It also found that the number of engineers had grown from a few hundred in one location to several thousand across six, which strained the guilds, and that the share of members at regular guild meetings averaged about 20%. Smite and Moe had presented preliminary results to Spotify’s guild leaders in February 2018. The same work appeared first in IEEE Software in 2019.

On autonomy, a 2023 paper in the Journal of Systems and Software studied six squads in 2019. It reports about 500 squads in six missions and about 50 tribes in spring 2020. It says some structures were abandoned, naming chapters, some lost popularity, naming guilds, and some were new, such as missions. It also found that squads decide how to build, but are held back by shared technology choices and by dependencies on other squads: in 2019 each squad interacted on average with 26 others in pull requests. Its conclusion is that autonomy at scale does not mean anarchy and needs a few enabling constraints. The manager share in engineering stayed low as the company grew, which is relevant to span of control.

Researchers outside Spotify found a similar tension. A study of two telecom companies found that team autonomy was limited by the need for alignment, and that alignment came both top-down and through communities. By 2018 other researchers were asking how to keep squads aligned in organisations that copied the method.

What should you take from it?

Treat it as a case study of one company’s answers to a real problem: how to keep teams fast without dropping coordination. The parts that hold up in the sources are small. Give teams missions with end-to-end ability to ship. Measure dependencies and team health, as Spotify did in its squad surveys and its health check. Make communities voluntary but resourced. Expect the structure to change, as the 2023 paper shows it did. The 2012 paper itself said the model gave Spotify something to grow into, and a 2022 session summary quotes Kniberg saying it was created before it was needed. For other ways to design teams around work, see growth team structure and operating model design. A Growth Lab plan starts from the work and its dependencies before any team names, as described under Growth Lab.

How to apply Spotify model, step by step

1. Map the dependencies first. List every team and mark which other teams block or slow it. Spotify asked its squads this question on a regular basis. Result: a dependency map that shows where autonomy is already impossible.
2. Give each team a long-term mission. Write one mission per team, such as payments or the mobile app, that lasts for years and not for one project. Result: each team knows what it owns and what it does not.
3. Separate priorities from craft. Decide who sets the team's priorities, as the squad's product owner did, and who looks after skills and careers, as the chapter lead did. Result: two named roles with different questions, so people know whom to ask about what to build and how to build it well.
4. Cap the size of a group. Keep teams that share a mission within one group small enough for people to know each other. Kniberg and Ivarsson aimed for tribes under about 100 people. Result: a group boundary based on how many relationships people can keep up.
5. Add communities with protected time. Start voluntary groups for people who do similar work and give them hours in the week. Research on Spotify's guilds found lack of dedicated time to be a main barrier. Result: communities that meet, not communities that exist on a chart.
6. Check, then drop what does not work. Run a short team survey every quarter on dependencies and release friction, as Spotify did, and remove any structure the results do not support. Result: a short list of changes to keep or drop.

Examples

ING Netherlands, 2015 to 2017

ING began its shift in June 2015. A McKinsey interview published in January 2017 reports about 350 nine-person squads in 13 tribes. An ING executive said Spotify was an inspiration. The executives report faster time to market and higher engagement and customer-satisfaction scores. These are their own claims, in an interview, and no independent measure is given.

A payments company with 60 engineers

Illustrative, no real company implied. Sixty engineers in teams of six make ten teams. That fits in one group of under 100 people, so the company needs one tribe and no layers between teams and the head of engineering. Each team gets a mission such as payouts, card issuing or fraud checks. The numbers are arithmetic, not a measured result.

A clinic group's digital team

Illustrative, no real clinic implied. A team of 25 builds a booking app, a patient portal and a billing integration. Three cross-functional teams each own one of the three, with their own tester. A shared testing group meets monthly so the testers do not solve the same problem three times. The first review shows that the portal and billing teams block each other, so they merge.

When to use it

Use it as a source of ideas when several teams ship the same product, handoffs between functions slow you down, and teams lose time waiting for one another. It suits growing engineering and product organisations of about 30 to a few hundred people, where leaders can give teams real decision rights.

When not to use it

Do not copy the structure and vocabulary as a package. The authors said it was one company's snapshot, and a 2023 study of Spotify reports that chapters were dropped and guilds lost popularity. Skip it when teams have few shared dependencies, when leaders will not delegate decisions, or when few people know agile practice.

Common mistakes

• Copying the names and the org chart without the dependency mapping, product ownership and quarterly checks that sat underneath them.
• Giving teams autonomy without shared priorities and success measures. Former Spotify employee Jeremiah Lee argued this caused friction between teams.
• Treating chapter leads as managers of people who have no say in delivery, which leaves nobody accountable for outcomes across teams.
• Assuming every squad follows good agile practice. Joakim Sundén, a former Spotify coach, said many squads did not follow common practices.
• Starting guilds and chapters without time or sponsorship, so they depend on volunteers and attendance falls.

FAQ

What is the Spotify model?

It is the way Spotify described its engineering organisation in 2012: small cross-functional squads, grouped into tribes, linked by chapters of people with similar skills and by open guilds. Henrik Kniberg and Anders Ivarsson wrote it up in October 2012 and said it was a snapshot of a company still changing.

Does Spotify still use the Spotify model?

Partly. A 2023 paper by researchers with a Spotify co-author says that in spring 2020 Spotify had about 500 squads and about 50 tribes. It also says chapters were abandoned, guilds lost popularity and a new layer called missions was added.

Is a squad the same as a Scrum team?

Close, but not the same. The 2012 paper says a squad is similar to a Scrum team, and that squads chose their own way of working, including Scrum sprints, Kanban or a mix. Scrum itself prescribes roles and events that a squad could take or leave.

Who invented the Spotify model?

No single person. Kniberg wrote in 2015 that he did not invent it and was the messenger, and that it grew from many Spotify people experimenting. The 2012 paper opens by saying its authors did not invent it. Joakim Sundén, a Spotify coach, said Spotify never coined the term.

How big is a tribe?

The 2012 paper says tribes were designed to be under about 100 people, citing the Dunbar number. That was a design aim at the time. In spring 2020, a 2023 study reports about 500 squads across about 50 tribes, so a tribe then averaged about ten squads.

Sources

1. Henrik Kniberg and Anders Ivarsson, Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, October 2012
2. Spotify Engineering, Spotify engineering culture, part 1, 2014
3. Spotify Engineering, Spotify engineering culture, part 2, 2014
4. Henrik Kniberg, Spotify engineering culture (part 1), Crisp blog, 2014
5. Henrik Kniberg, Squad health check model, Spotify Engineering, 2014
6. Henrik Kniberg, No, I didn't invent the Spotify model, Crisp blog, 2015
7. Leading Complexity, Summary of Henrik Kniberg's session on the Spotify model, Crisp blog, 2023
8. The Agile Revolution, Episode 112: Inside Spotify with Anders Ivarsson, 2016
9. InfoQ, Spotify: The Agile Nirvana? Interview with Joakim Sundén, 2017
10. Agile2017, You can do better than the Spotify Model, Joakim Sundén and Catherine Peck-Phillips, 2017
11. Jason Yip, How things still don't quite work at Spotify, and how we're trying to solve it, slides
12. Jeremiah Lee, Spotify's Failed #SquadGoals, 2020
13. Mankins and Garton, How Spotify balances employee autonomy and accountability, Harvard Business Review, 2017
14. Smite, Moe, Levinta and Floryan, Spotify guilds: how to succeed with knowledge sharing in large-scale agile organizations, IEEE Software, 2019
15. Smite, Moe, Floryan, Levinta and Chatzipetrou, Spotify guilds, Communications of the ACM, 2020
16. SINTEF, Smite and Moe, Results from guild study in Spotify, preliminary results, lecture, 2018
17. Smite, Moe, Floryan, Gonzalez-Huerta, Dorner and Sablis, Decentralized decision-making and scaled autonomy at Spotify, Journal of Systems and Software, 2023
18. Moe, Smite, Paasivaara and Lassenius, Finding the sweet spot for organizational control and team autonomy in large-scale agile software development, Empirical Software Engineering, 2021
19. Salameh and Bass, Influential factors of aligning Spotify squads in mission-critical and offshore projects, PROFES 2018
20. McKinsey, ING's agile transformation, interview with Peter Jacobs and Bart Schlatmann, 2017
21. Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn