← Back to blog

Squads, Tribes, Chapters, and Guilds: The Spotify Model

spotify-model agile-at-scale organization

The “Spotify model” has become synonymous with agile at scale. But few understand that it is not a framework — it is a culture. Trying to copy the structure without the culture is a recipe for frustration.

The four structures

Squad

Autonomous cross-functional team (6-12 people). Equivalent to a Scrum team.

  • Has its own backlog and sprint
  • Delivers end to end
  • Autonomy to decide how to work

Tribe

Collection of squads working on related areas (e.g., “User Experience Tribe”).

  • 40-150 people
  • Shares business objectives
  • Each squad has autonomy within the tribe

Chapter

Group of people with the same skill set within a tribe (e.g., “Backend Chapter”).

  • Maintains technical standards
  • Does mentorship and 1:1s
  • Does not manage the squad’s work

Guild

Community of interest that spans the entire organization (e.g., “Machine Learning Guild”).

  • Voluntary
  • Shares knowledge
  • Can include anyone in the company

What Spotify doesn’t tell you

The model evolved organically over years. It was not born ready. Every company that tries to copy the structure without its 10 years of cultural evolution runs into problems.

The autonomy is real

At Spotify, squads really decide what and how to build. In most companies, “autonomy” is an illusion — decisions come from above.

Trust culture is fundamental

Without trust, autonomy becomes chaos. Spotify invested heavily in “aligned autonomy”: autonomy with alignment.

The structure changed

Spotify itself abandoned parts of the model over time. It is not static.

Estimates in the Spotify model

Each squad has its own velocity and point scale:

  • No cross-squad comparisons — each squad calibrates its own scale
  • Dependencies between squads resolved by “alignment” not by “command”
  • Chapter can help calibrate estimates between squads of the same skill set

When the model makes sense

  • Digital product company — the core business is software
  • 100+ engineering people — below that, a simple structure is better
  • Autonomy culture — leadership that truly delegates
  • Mature product with multiple development fronts

When it does NOT make sense

  • Startups (< 50 devs) — squads are too autonomous
  • Consulting projects — scope and client defined externally
  • Companies with hierarchical culture — autonomy will not be accepted
  • Teams in agile transition — learn Scrum first, then scale

Conclusion

The Spotify model is fascinating as inspiration, not as a recipe. Copy the principles (aligned autonomy, cross-team communication, product focus) — not the structure. Every company needs to find its own way to scale.