In October 2012 Spotify engineers Henrik Kniberg and Anders Ivarsson published a paper describing how over 30 teams across 3 cities were organised into squads, tribes, chapters and guilds. What problem were those structures aimed at, what did the design give up, and where would copying it be a mistake?

The situation

By 2012 Spotify described itself, in the Kniberg and Ivarsson paper "Scaling Agile @ Spotify", as having grown beyond 30 teams over three cities. At that size a single shared backlog stops working: if most features need three teams to agree, the number of coordination paths grows with the square of the team count. Thirty teams have up to 435 pairs (30 x 29 / 2). A structure that cuts the common case down to one team removes most of those pairs from the critical path.

What they chose

The paper describes the squad as the smallest unit, a small cross-functional team that owns a part of the product end to end. Squads working in a related area form a tribe. Chapters and guilds are the cross-cutting layer: people with the same craft, such as backend or testing, meet to share practice, so that autonomy does not mean every squad invents its own way of doing everything.

This is Conway's Law used on purpose. The system's boundaries follow the team boundaries, so if the team owns the feature, most changes stay inside one codebase and one release.

Why it fit their constraints

A consumer product with many independent features (search, playlists, payments, player) has natural seams. Squads could own one seam each. The business also valued shipping many small changes more than strict uniformity.

What it cost

• Duplication: two squads solve the same small problem twice because sharing needs a conversation.
• Hidden dependencies: shared infrastructure and cross-cutting features (a new payment method touching player, accounts and billing) still need several squads, and the model gives no free answer for them.
• Coordination moved, not removed: chapters and guilds are meetings and reading time that someone has to spend.

Where copying it would be a mistake

Copying the names without the seams. A 12-person company that creates two squads and a guild has added meetings without removing a single dependency, because the product is not yet large enough to have independent parts. A company whose features all share one core system (a bank ledger, a regulated trading engine) cannot give each squad real end-to-end ownership, because the shared core makes every change cross-team anyway. Draw the boundaries from how work actually flows, using a count of how many teams the last 20 features touched, and form teams around that.

Common weak answers

• "They invented a framework other companies should adopt." The paper is a snapshot of one company at one time; the transferable idea is ownership aligned to deliverables.

What a strong answer adds

Say how you would measure whether it worked: the share of features shipped by one team, and the lead time of features that needed three or more.