The Power of Spotify Squads
.svg)
- The Spotify model comes from an October 2012 article, “Scaling Agile @ Spotify” by Henrik Kniberg and Anders Ivarsson, not from an official framework.
- It rests on four units: the squad (the team), the tribe (a group of squads), the chapter (the craft) and the guild (the community of interest).
- No squad size appears in the original text; only the tribe is bounded, under the 100-people mark, following the Dunbar number.
- The document itself warns that it is only a snapshot; in 2016 a Spotify chapter lead publicly asked companies not to copy it.
- Jeremiah Lee, a former Spotify product manager, documents three weaknesses: blurred accountability, autonomy without coordination, and missing basic agile skills.
- The structure can still be rebuilt in Talkspirit with circles and sub-circles, provided you adapt it rather than trace over it.
Among the other many reasons it's known around the world, Spotify became hugely popular in the Teal community after releasing a two-part video series on their unique way of structuring their engineering team.
It focused on autonomy, trust, and speed.
The Corporate Rebels also wrote an article detailing each key piece of the structure.
The videos came after a founding text: “Scaling Agile @ Spotify”, published in October 2012 by Henrik Kniberg and Anders Ivarsson. It describes a company that had grown from 30 to 250 people in tech in three years, and was trying to keep its way of working while doing so.
While it's always best for organizations to think about their own needs and preferences when deciding how to organize, seeing how other companies do things can inspire us and give a good starting point.
So here is what the model actually contains, what Spotify itself says about it, and how to set the structure up in Talkspirit if it works as a starting point for you.
Spotify's Structure
To get started, we first need to understand the basic components of their structure. Rather than roles and circles, which you would see in Holacracy, Spotify's engineering department was structured around the following pieces:
- Squad: A small group of people who have all the skills needed to completely fulfill one specific aspect of the work. Akin to a team.
- Tribe: A group of a few squads who all work on a single piece of the organization. Akin to a department.
- Chapters: Every member of a tribe, each on different squads, who does the same task. For example, the product tester of each squad in Tribe A would share a chapter. Each chapter is led by a line manager.
- Guild: Any number of people across any number of tribes who are interested in a specific topic, such as shared interests and hobbies. Anyone who is interested can join any guild.
One detail is worth pinning down, because it circulates everywhere in a distorted form: the 2012 document gives no squad size. The headcounts repeated from guide to guide, six to twelve people in most versions, are not in the source. The only size the text fixes is the tribe: it is sized on the Dunbar number, smaller than 100 people or so, on the grounds that larger groups bring restrictive rules, bureaucracy, politics and extra layers of management.
The text also asks the question everyone ends up asking: isn’t this just a matrix org? Its authors answer yes, sort of, with one nuance. The vertical dimension, squads and tribes, carries the “what” and comes first, because that is how people are physically grouped day to day. The horizontal dimension, chapters and guilds, carries the “how”: sharing knowledge, tools and code. A squad has no formally appointed leader either, only a product owner who prioritizes the work without deciding how it gets done.
| Unit | What the 2012 document says | Who leads it | Matrix dimension |
|---|---|---|---|
| UnitSquad | What the 2012 document saysThe basic unit, similar to a Scrum team, co-located, with all the skills needed to design, develop, test and release, on a long-term mission | Who leads itNo formally appointed leader, a product owner prioritizes the work without deciding how it is done | Matrix dimensionVertical, the “what” |
| UnitTribe | What the 2012 document saysA group of squads working on one segment of the product, kept under the 100-people mark (Dunbar number) | Who leads itA tribe lead, responsible for giving the squads the best possible habitat | Matrix dimensionVertical, the “what” |
| UnitChapter | What the 2012 document saysThe members of one tribe who share the same craft, meeting regularly on their own technical topics | Who leads itA chapter lead, line manager, who also remains a member of a squad | Matrix dimensionHorizontal, the “how” |
| UnitGuild | What the 2012 document saysAn open community of interest that cuts across the whole organization, which anyone can join | Who leads itA guild coordinator | Matrix dimensionHorizontal, the “how” |
What Spotify says about the Spotify model
The founding document opens with a warning that most people quoting it skip: “We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working, a journey in progress, not a journey completed. By the time you read this, things have already changed.”
In 2015, Henrik Kniberg wrote on his blog that he did not invent the model and that “it wasn’t actually intended to be a generic framework or model at all, it’s just an example of how one company works”.
A year later, Marcin Floryan, chapter lead at Spotify, went further, as reported by InfoQ: the model “can help you to understand how things are done at Spotify, but it is not something that you should copy in your own organization”. His reason is short: the model keeps changing along with the teams that practice it.
The best documented critique comes from Jeremiah Lee, a former product manager at Spotify, in a piece called “Failed #SquadGoals”. He describes three sticking points seen from the inside: engineers managed by a chapter lead outside their own team, which created accountability gaps and convoluted escalation paths; autonomy granted without any defined cross-team coordination process, each team inventing its own way of working; and missing basic agile skills, for lack of enough coaching. He describes an incremental move towards more traditional management structures, without giving a date.
None of this invalidates the original intent. It moves what there is to take from it: the vocabulary, squad, tribe, chapter, guild, can be copied in an afternoon, while the clarity of accountability and the decision-making rules that make that autonomy workable take considerably more effort.
How to build it in Talkspirit
Complex as the structure looks, it is relatively easy to replicate in Talkspirit, as long as you adapt it to your own needs rather than trace over it. Just follow these steps:
- Create 2 circles: Tribes and Guilds
- Under Tribes, create a separate sub-circle for each tribe
- In each tribe sub-circle, create two additional sub-circles: Squads and Chapters
- In each squads sub-circle, create an additional sub-circle for each squad. Add all relevant squad members to each of these circles.
- In each chapters sub-circle, create an additional sub-circle for each chapter
- In each chapter, name the role that carries line management, the line manager, then add every member of that chapter to the circle.
- Under Guilds, create a separate role or sub-circle (as desired) for each guild
That's all there is to it. The initial restructuring takes time, and it goes faster when the core roles of each circle are settled first, before the specific ones such as the line manager of each chapter are added.
Want to see what it looks like on your own org chart? Book a demo with our team.
Other models you may be interested in
If you're interested in the Spotify structure, you may also want to explore innovative organizational models such as Holacracy, Sociocracy, Agile and Lean. All those models have something in common: they aim to improve teams' autonomy, trust and agility. To start with a concrete case, read the benefits of switching to holacracy and how to ease into it. Interested to know more? Download our latest white paper on organizational models 👇
Access White Paper
In our white paper "The Ultimate Guide to Organizational Models", you'll get: a comprehensive overview of innovative organizational models (like Agile, Teal, Holacracy, Constitutional Management, and more), testimonials from pioneer organizations that have successfully adopted it, best practices for choosing, implementing and measuring the effectiveness of our model, as well as digital tools to facilitate the transition.
FAQ
A squad is a small group of people who have all the skills needed to completely fulfil one specific aspect of the work, akin to a team. The 2012 document describes it as similar to a Scrum team, co-located, able to design, develop, test and release, on a long-term mission, with no formally appointed leader and a product owner who prioritises the work without deciding how it gets done.
The squad is the team. The tribe groups several squads working on one segment of the product, kept under 100 people. The chapter gathers, inside a tribe, the people who share the same craft, and its chapter lead is their line manager. The guild is an open community of interest that cuts across the whole organization and that anyone can join.
The original document gives no figure. The sizes in circulation, six to twelve people in most retellings, come from later accounts rather than from the source. The only size the text fixes is the tribe, kept under the 100-people mark following the Dunbar number.
Not in the form published in 2012, and its authors said so at the time: the article presents itself as a snapshot, with the line “by the time you read this, things have already changed”. In 2016, Marcin Floryan, chapter lead at Spotify, publicly asked companies not to copy it. Jeremiah Lee, a former product manager there, describes an incremental move towards more traditional management structures, without giving a date.
Three of them are documented by Jeremiah Lee, who saw them from the inside: engineers managed by a chapter lead outside their own team, which blurs accountability and complicates escalation; autonomy granted without any cross-team coordination process; and missing basic agile skills, for lack of coaching. The vocabulary copies quickly, the decision rules that make it workable do not.
With two root circles, Tribes and Guilds. Under Tribes, one sub-circle per tribe, each holding two more sub-circles, Squads and Chapters, then one sub-circle per squad and per chapter. In each chapter, one role carries line management, the line manager. Under Guilds, one role or sub-circle per guild. Settling the core roles of each circle first saves a lot of time.
