Spotify Model

The familiar way to handle a growing number of teams was to add a management layer on top. A director above the team leads, a vice president above them, and the reporting lines look orderly on paper. The cost is that decisions travel up and then back down, taking a week each way, and teams stop deciding their own work at all.

Giving every team autonomy instead produces a different problem. Two teams build notifications in two different ways; one writes tests carefully and the other writes almost none at all. Each choice was reasonable inside its own team, and across the company the same work happened twice while engineering standards drifted apart. Moving between teams then means learning everything again from scratch, and hiring gets harder because there is no one way the company works.

The Spotify model is an attempt to hold both at once, on two axes. What to build is decided by the team that owns the goal, and the standards for how to build it are set by people of the same discipline meeting across teams. Neither axis is allowed to answer both questions. The name comes from a 2012 document in which one company described how it was working at the time.

Cut teams by goal, then lay discipline groups across them.

1. One goal, one team. A small autonomous team owning one goal is a squad, sized between about 6 and 12 people. Product, design and engineering all sit inside it, so it can ship without waiting on another team for anything routine.
2. Group related squads. Squads working on adjacent goals, like payments and subscriptions, form a tribe, which gets kept under roughly 100 people. Above that nobody knows who is doing what any more, so the tribe gets split rather than allowed to keep growing.
3. Create discipline groups. A chapter is where people of the same discipline share expertise. If squads run horizontally, chapters run vertically. How engineers write tests, which components designers share, gets decided here — and people management and career growth usually sit with the chapter lead rather than with the squad.
4. Keep interest groups voluntary. A guild, where anyone interested in a subject gathers regardless of discipline, isn't something to make mandatory. Made mandatory, it turns into a standing meeting with nothing in it.
5. Write down the scope of the autonomy. What gets aligned above and what the team decides for itself belongs in a sentence. Without it, autonomy gets read as everyone doing as they please, and the standards from step three go unobserved within a quarter.

Holding both axes gives one person two reporting lines. This model carries the character of a matrix organization, with reporting lines along both function and initiative, so the question of who decides when a squad's goal collides with a chapter's standard has to be settled before it happens.

It fits where a product has several branches that can ship independently. If payments, search and notifications aren't heavily entangled, each team can release on its own cadence, and that independence is what this shape is built to protect. By headcount the conversation starts somewhere above forty people; below that there is no reason for either tribes or chapters to exist.

The bad fits are clear. First, with three teams or fewer this shape only adds nouns — one recurring meeting between team representatives covers the same need. Second, where teams inside one product depend heavily on each other, autonomy doesn't hold no matter how the chart is drawn. Third, in regulated or safety-critical work, documented procedure and sign-off come first, which leaves the scope for autonomy narrow before anyone starts drawing squads.

The limits come from where the model originated. What was published is a photograph of one company at one moment in 2012, and that company changed its structure repeatedly afterwards. Copy it as a rulebook and you import that company's circumstances of the time along with the structure, including the ones nobody wrote down. Taking the idea of two axes, rather than the org chart itself, is what travels between companies.

The most common failure in practice is renaming. Call existing teams squads and departments tribes and the chart looks new, while decision authority stays where it was and nothing changes. What has to change is who decides what, and no amount of renaming accomplishes that.

"Renaming the teams to squads doesn't change anything by itself."

Authority didn't move, so the work will not move either.

"That's a decision for the chapter."

Standards for how things get built belong to the discipline group rather than to any one team.

"We have three teams. There's no reason for a tribe."

The layer doesn't match the size of the organization.

Pagedeck doesn't run this model as written. At 45 people it isn't the size for tribes, and with a single product there is little to cut into branches in the first place. Two pieces got borrowed instead.

The first is cutting teams by goal: document editing, sharing and permissions, and search, each with product, design and engineering attached. The second is the discipline groups themselves. Mia, Noa and Theo each hold a fortnightly session to align standards within their own discipline across the three teams. The problem of notifications being built differently on each team got resolved in one of those sessions. Neither the word squad nor the word chapter is used.

The most common mistake is reading autonomy as everyone deciding for themselves. The phrase autonomous team invites it. But the autonomy this model describes means the goal is aligned and only the method is the team's to choose. Leave that boundary unwritten and the goals diverge too, and six months later three teams are walking in three directions. The document that introduced the model puts alignment and autonomy side by side on purpose, for exactly this reason.

Believing the company still works this way is the other one. A company's name is in the label, which makes the whole thing read as present tense. What was published is a record of one moment in time, and people from that company later cautioned publicly against its use as a rulebook. That no organization can adopt another's structure unchanged is close to the last lesson worth taking from it.