Spotify Model: Squads, Tribes, Chapters, and Guilds -- Guide and Critique

The Spotify model is probably the most copied organizational model of the last decade — and simultaneously the most misunderstood. Companies worldwide have introduced squads, tribes, chapters, and guilds, rebuilt their org charts, and adjusted their meeting structures. The results were often sobering.

The reason is as simple as it is uncomfortable: The Spotify model is not a model. Spotify itself has emphasized this repeatedly. Henrik Kniberg and Anders Ivarsson, the authors of the famous 2012 whitepaper, described a snapshot — how Spotify worked at a specific point in time. Not a blueprint for other organizations to copy. Not a framework with defined rules and roles. But a snapshot of an organizational culture that was constantly evolving.¹

This article explains what the Spotify model actually describes, why so many copy attempts fail, when the elements can still be useful — and which alternatives are better suited for DACH companies.

What Is the Spotify Model?

The Origin: Kniberg & Ivarsson 2012

In March 2012, Henrik Kniberg (agile coach) and Anders Ivarsson (organizational developer) published the whitepaper “Scaling Agile @ Spotify” — accompanied by two YouTube videos that together reached over 1.5 million views.¹ The document described how Spotify, with then approximately 30 teams and 250 employees, organized its software development.

Critical context: The whitepaper was neither an academic publication nor an official Spotify document. It was an informal report by two consultants about their observations. Kniberg himself wrote in the introduction: “This is not a recipe. It is a snapshot of what we are doing right now.”¹ At that point, Spotify was a relatively young company with a homogeneous engineering culture — conditions that differ fundamentally from a DACH corporation with 10,000 employees.

The Four Elements

1. Squads — The Autonomous Team

A squad is the basic unit: a small, cross-functional team of 6-12 people responsible for a feature, service, or part of the product. Squads have:

• A clear mission (e.g., “improve the search experience”)
• Full autonomy over how they fulfill their mission
• All competencies they need (developers, designers, testers, product owner)
• No traditional manager — instead a product owner (what gets built) and optionally a chapter lead (how it gets built)

What Kniberg emphasized: Squads are “mini-startups.” They decide for themselves about technologies, methods, and ways of working. Autonomy is not a concession — it is the core principle.¹

2. Tribes — The Collection of Related Squads

A tribe is a collection of squads working on related topics (e.g., all squads working on the music player experience). Typical size: 40-150 people (drawing on Dunbar’s number — the cognitive upper limit for stable social relationships).²

A tribe has a tribe lead responsible for coordination between squads and creating a productive work environment. Tribes have their own physical spaces, which promotes informal communication.

3. Chapters — The Specialist Community Within the Tribe

A chapter is a group of people with the same specialization within a tribe (e.g., all backend developers in the music player tribe). The chapter lead is responsible for:

• Professional development of members
• Salary and career planning
• Ensuring technical standards and best practices

The matrix structure: A developer belongs simultaneously to a squad (what they build) and a chapter (how they build it). This creates a matrix where delivery and expertise are managed separately.

4. Guilds — The Organization-Wide Interest Community

A guild is a voluntary, cross-tribe community of practice for people with shared interests (e.g., “Web Technology Guild,” “Agile Coaches Guild”). Unlike chapters:

• Guilds are cross-tribe
• Membership is voluntary
• There is no formal authority

Guilds serve knowledge exchange and coordination of standards across tribe boundaries.

Alignment and Autonomy: The Central Tension

The whitepaper contains a graphic that became the iconic symbol of the Spotify model: the alignment-vs.-autonomy matrix. Teams are positioned on two axes:

	Low Alignment	High Alignment
High Autonomy	Chaos	Alignment + Autonomy (Goal)
Low Autonomy	Micromanagement culture	Conformism

Kniberg’s message: the goal is not autonomy alone — that leads to chaos. And not alignment alone — that leads to conformism. The goal is both simultaneously: teams that know where the organization wants to go (alignment) and freely decide how to get there (autonomy).¹

Why Copying the Spotify Model Almost Always Fails

Jeremiah Lee’s Analysis: “Failed #SpotifyModel”

In 2020, Jeremiah Lee, a former Spotify employee, published a detailed analysis titled “Failed #SpotifyModel.” His central thesis: the Spotify model was already not what the whitepaper described even at Spotify itself — and by the time it was communicated externally, it was no longer working internally as described.³

Lee’s core critiques:

1. Matrix Management Without Decision Clarity The split between product owner (what) and chapter lead (how) created conflicts in practice: who decides on priorities when the “what” and the “how” are in tension? At Spotify, this led to informal power struggles that were nowhere addressed in the model.

2. Autonomy Without Accountability Squads had the freedom to choose their own technologies. The result: a proliferation of technologies that made maintenance and cross-cutting improvements difficult. “Autonomy allowed teams to be effective, but the collective of autonomous teams was often not effective.”³

3. Chapters Didn’t Work as Planned Chapter meetings were supposed to foster professional exchange. In practice, they were rarely held because squad work always took priority. The professional development that chapters were supposed to ensure didn’t happen systematically.

4. Psychological Safety Was Assumed, Not Built The model only works when teams openly discuss mistakes, ask for help, and resolve conflicts constructively. At Spotify, this was taken as given — it wasn’t. Lee observed teams working in the wrong direction for months without anyone speaking up.

Why Copying Fails Structurally

Companies that copy the Spotify model typically make three mistakes:

Mistake 1: Copy the Structure, Ignore the Culture

The Spotify model is 20 percent structure and 80 percent culture. Squads, tribes, chapters, and guilds are structural elements. But they only work on the basis of a culture that includes autonomy, psychological safety, willingness to experiment, and tolerance for failure. A DACH corporation that renames its org charts into squads without changing the decision-making culture creates old hierarchy in new packaging.

Mistake 2: Ignore Spotify’s Context

Spotify in 2012 was a young, culturally homogeneous tech company with 250 employees that exclusively developed software. Teams sat in the same building, spoke the same (technical) language, and shared a common engineering culture. These conditions don’t exist at a DACH insurer with 15,000 employees, 200 years of history, regulatory requirements, and an entrenched silo structure.

Mistake 3: Treat the Model as Static

Spotify has evolved since 2012. The organization looks different today from what the whitepaper describes. The model was always intended as a living organism, not a blueprint to freeze. Companies implementing the 2012 Spotify model in 2025 are copying a snapshot that is 13 years old.

When the Spotify Elements Can Still Be Useful

Despite the justified critique, the Spotify concepts contain principles that are valuable for DACH companies too — when used as inspiration, not as a blueprint:

Principle 1: Cross-Functional Team Structure

The idea of organizing teams not by specialist function (all developers together, all designers together) but by value contribution (everyone who jointly delivers a product or service) is a proven organizational principle. Matthew Skelton and Manuel Pais systematize this in Team Topologies (2019) with the concept of “stream-aligned teams.”⁴

Principle 2: Alignment and Autonomy Simultaneously

The alignment-autonomy matrix remains one of the most useful diagnostic tools for organizational development. The question “Do our teams know where we’re heading? And do they have the freedom to decide how they get there?” is universally relevant.

Principle 3: Community of Practice as Knowledge Bridge

Guilds — voluntary, interest-based communities that share knowledge across team boundaries — are an effective instrument against silo formation. The prerequisite: there must be time and space for participation. If guilds are “voluntary” but nobody has time for them, they exist only on paper.

Principle 4: Small, Autonomous Units

Limiting tribes to 150 people (Dunbar’s number) and squads to 6-12 people follows robust social science findings about the limits of human coordination capacity.² These size limits are applicable independent of the Spotify model.

The Spotify Model Compared

Dimension	Spotify Model	SAFe (Scaled Agile)	LeSS (Large-Scale Scrum)	Team Topologies
Focus	Culture + structure	Process + governance	Simplicity + Scrum fidelity	Cognitive load + flow
Prescriptiveness	Low (inspiration, no rules)	Very high (roles, ceremonies, artifacts)	Medium (Scrum rules + principles)	Medium (4 team types + 3 interaction modes)
Strength	Autonomy, culture, motivation	Scalability, governance, PMO compatibility	Simplicity, Scrum consistency	Evolutionary, flow-based, technically grounded
Weakness	Not a framework, not implementable	Can become bureaucratic, expensive	Requires radical reorganization	Focus on technology teams, less on business
Suited for	Tech companies with strong culture	Large enterprises with compliance needs	Companies that take Scrum seriously	Modern software organizations
DACH suitability	Limited (culture gap)	High (fits existing structures)	Medium (requires courage)	High (pragmatic, evidence-based)

Team Topologies: The Evidence-Based Alternative

Skelton and Pais’ Team Topologies (2019) addresses many weaknesses of the Spotify model:⁴

• Four clear team types: Stream-aligned, Enabling, Complicated Subsystem, Platform.
• Three interaction modes: Collaboration, X-as-a-Service, Facilitating.
• Cognitive load as design principle: Teams are shaped so that cognitive load remains manageable — not based on org chart aesthetics.
• Evolutionary rather than revolutionary: Teams evolve over time instead of the entire org chart being rebuilt at once.

For DACH companies that want to modernize their organizational structure, Team Topologies offers a more pragmatic approach than the Spotify model: fewer cultural prerequisites, clearer implementation guidance, stronger technical grounding.

Practical Example: Spotify Model Adoption at a DACH Financial Services Company

A major DACH financial services company introduced the Spotify model in its IT department (800 employees) in 2019. The experiences illustrate typical patterns:

Phase 1: Structural Conversion (Months 1-3) Departments were renamed to tribes. Teams were reorganized into squads. Chapter leads were appointed. The org charts looked modern.

Phase 2: Reality Check (Months 4-8)

• Squads nominally had autonomy, but budget decisions still ran through the old hierarchy.
• Chapter meetings didn’t happen because sprint commitments took priority.
• Regulation (BaFin requirements) demanded documentation and approval processes that didn’t fit the autonomy promise.
• Tribe leads felt like department heads with new titles.

Phase 3: Adaptation (Months 9-18)

• Instead of continuing to implement the Spotify model, the working elements were extracted: cross-functional teams (squads remained), guilds for knowledge sharing (worked well), and team autonomy in method choice (where regulation allowed).
• The non-functioning elements were abandoned: tribes as a formal structure (too artificial), chapter leads as a separate role (collided with existing leadership structure).

Lessons learned:

1. Copying the structure was easy. Changing the culture was the actual project — and took three years, not three months.
2. Regulated industries need an adaptation that reconciles autonomy and compliance — the Spotify model offers no guidance for this.
3. The most valuable elements were the simplest: cross-functional teams and communities of practice.

Frequently Asked Questions

What is the Spotify model in simple terms?

The Spotify model describes how Spotify structured its organization: autonomous teams (squads) work in larger groups (tribes), are organized professionally in chapters, and share knowledge through guilds. It is less a framework than a snapshot of a specific company culture.

Is the Spotify model an agile framework?

No — and this is a common misconception. Spotify itself emphasizes that it is not a model or framework but a description of how they worked at a specific point in time. Unlike SAFe or LeSS, there are no defined roles, ceremonies, or rules.

What is a squad?

A squad is a small (6-12 people), cross-functional, autonomous team with a clear mission. It has a product owner (what gets built) and the freedom to decide for itself how it works. Comparable to a Scrum team but with more autonomy.

What is the difference between a chapter and a guild?

Chapters are specialist groups within a tribe (e.g., all backend developers in a tribe). Guilds are cross-tribe interest communities (e.g., everyone interested in web performance). Chapters have a formal lead; guilds are voluntary.

Why do Spotify model copies fail?

Because companies copy the structure (squads, tribes) but ignore the culture (autonomy, psychological safety, tolerance for failure). Spotify itself says the model was developed for their specific situation and was never intended as a universal blueprint.

What is better: the Spotify model or SAFe?

The question is poorly framed. The Spotify model is not an implementable methodology — it is a source of inspiration. SAFe is a highly structured framework with concrete guidance. For DACH companies that need scaled agile working, SAFe offers more implementation support. For companies pursuing cultural change, the Spotify principles (alignment + autonomy) provide valuable orientation.

Methodology & Sources

This article draws on 10 academic and practitioner sources, including the original whitepaper by Kniberg and Ivarsson (2012), the critical analysis by Jeremiah Lee (2020), Team Topologies by Skelton and Pais (2019), Dunbar’s research on social group sizes, and DACH implementation experiences.

SERP finding: The German-language top-10 results for “Spotify Modell” are structural descriptions (squads + tribes + chapters + guilds) without critical assessment. None cites Jeremiah Lee’s critique, explains why copying fails, structurally compares the model with SAFe, LeSS, and Team Topologies, or offers a DACH practical example with lessons learned. This article closes these four gaps.

Limitations: The Spotify model has not been academically evaluated — it is based on an informal report. Lee’s critique is a single (albeit well-founded) perspective. DACH-specific study data on Spotify model adoption does not exist.

Disclosure: SI Labs supports companies in developing service innovation capabilities. We use elements of the Spotify model (cross-functional teams, communities of practice) as building blocks but do not recommend unmodified adoption.

References

Footnotes

1. Kniberg, Henrik and Anders Ivarsson. “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.” Whitepaper, October 2012. Accompanying videos: “Spotify Engineering Culture” Part 1 and Part 2 (YouTube, over 1.5 million views). Kniberg: “This is not a recipe. It is a snapshot of what we are doing right now.” ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Dunbar, Robin I.M. “Neocortex size as a constraint on group size in primates.” Journal of Human Evolution 22, no. 6 (1992): 469—493. Dunbar’s number (~150) as the cognitive upper limit for stable social relationships. Foundation for tribe size in the Spotify model. ↩ ↩²

3. Lee, Jeremiah. “Failed #SpotifyModel.” jeremiahlee.com, 2020. Detailed analysis of Spotify model implementation by a former Spotify employee. Core critique: matrix management problems, autonomy without accountability, chapter dysfunctions. ↩ ↩²

4. Skelton, Matthew and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019. Four team types (stream-aligned, enabling, complicated subsystem, platform), three interaction modes, cognitive load as design principle. ↩ ↩²