The Spotify Model Was Never A Model
Squads, tribes, chapters and guilds were a description of one company at one moment, published by people who later said it was not a template. Here is what gets lost when the org chart travels without the engineering culture.
Somewhere in your organisation there is a slide with four boxes on it. Squads are small autonomous teams. Tribes are collections of squads working in a related area. Chapters are people with the same skill across squads, with a line manager who is also a practitioner. Guilds are voluntary communities of interest that cut across everything. The slide is usually accompanied by an assurance that this is how Spotify does it, and therefore how a modern technology organisation ought to be arranged.
The vocabulary is now so widespread that it has detached from its source entirely. People use it who have never read the original material and could not say where it came from. That is worth pausing on, because the original material — a short whitepaper and a pair of animated videos put out by people working at Spotify in the early 2010s — was explicit that it was describing a snapshot of a company in motion, not prescribing a method. The authors said at the time that things were already changing as they wrote. Several of the people involved have spent the years since publicly discouraging its adoption as a template, pointing out that parts of it never worked as well internally as the diagrams suggest and that the company itself moved on.
None of which has slowed its spread. The reason is not that people are credulous. It is that the Spotify material offered something no framework offers: a picture of an organisation that was obviously succeeding, described in terms of boxes and reporting lines. Boxes and reporting lines are the native language of organisational change. They can be drawn on a Monday, announced on a Tuesday and implemented in a payroll system by the end of the quarter. The practices that actually produced the outcome cannot.
What the original material actually was
It was ethnography, not architecture. Two practitioners described how a fast-growing company had arranged itself to keep teams small and autonomous while still sharing craft standards, and they were candid that the arrangement was provisional. The framing was closer to "here is what we are trying, and here is the reasoning" than "here is what you should do".
Several things in it were genuinely valuable as ideas rather than as structures. The matrix of squad and chapter separated what you work on from who develops your craft, which is a real and useful distinction that most functional organisations conflate. The emphasis on alignment enabling autonomy — leaders being responsible for framing the problem clearly enough that teams can solve it without further instruction — is a sound principle and predates Spotify by decades in other guises. The treatment of failure as a normal operating condition, with architecture designed so that a squad's mistake has limited blast radius, is sound engineering thinking expressed organisationally.
What it was not was a validated method with defined roles, entry criteria, or any claim of transferability. There was no certification, no assessment, no implementation roadmap, and no assertion that this would work anywhere else. It acquired all of those afterwards, from other people.
Why org charts travel and practices do not
A structure can be copied by decree. An engineering culture cannot.
The squads in the original account were autonomous in a specific, expensive sense. They could release to production themselves, without asking anyone. They owned their services in production, including being woken up by them. The architecture was decoupled enough that a squad could make a meaningful change without negotiating with three other squads first. There was substantial investment in the tooling and internal platform that made this self-sufficiency real, and a tolerance for local variation in how squads worked that most organisations would experience as governance failure.
Take those conditions away and keep the vocabulary, and you get something quite specific: a set of teams with new names, still unable to deploy without a change advisory board, still dependent on a shared platform team's queue, still allocated to work by someone outside the squad, and now also carrying the overhead of chapter meetings and guild sessions. The cost has gone up. The autonomy has not arrived. This is the most common outcome of a Spotify-model rollout, and it is entirely predictable from the mechanism.
The asymmetry is worth stating plainly, because it explains a great deal about why organisational change programmes fail in the way they do.
| Travels easily | Does not travel |
|---|---|
| Team names and groupings | Deployment autonomy |
| Reporting lines and the squad–chapter matrix | Ownership of services in production |
| Meeting cadences and guild calendars | Architecture that permits independent change |
| Job titles | Trust to make decisions without approval |
| The slide | The tooling investment behind the slide |
Everything in the left column can be implemented by an HR system change. Everything in the right column requires years of engineering investment, sustained leadership restraint, and a willingness to accept local inconsistency. The left column is what gets adopted, because it is what can be adopted, and then the failure is attributed to the model.
What gets lost in transit
Autonomy becomes a label rather than a permission. In the source material, squad autonomy meant genuine decision rights over what to build within a framed mission, and over how to build and release it. In most adoptions, squads are told they are autonomous and then given a roadmap, a delivery date and an architecture review gate. The word is retained; the substance is reversed. Teams notice this quickly and it is corrosive, because being told you are empowered while being managed as though you are not is worse than being managed openly.
Chapters become ordinary line management. The chapter lead in the original was a practitioner who still did the work and whose job was craft development. In practice, chapter leads are frequently recruited or promoted as pure people managers, at which point a chapter is a functional department with a new name, and the matrix has recreated exactly the structure it was supposed to replace.
Guilds become mandatory meetings. Voluntary communities of interest work because attendance signals genuine engagement. Guilds with mandated membership, a charter, a budget line and a reporting obligation are committees. The value evaporated the moment attendance stopped being optional.
Tribes become departments with a headcount ceiling. The tribe was meant to be a bounded grouping small enough that people knew each other. Adopted as a layer, it becomes a middle-management tier with a tribe lead who has all the accountability of a director and, typically, none of the budget authority — which produces the escalation behaviour the structure was supposed to remove.
The architecture is left alone. This is the decisive one. Squad autonomy is a property of the system, not of the org chart. If two squads must both change the same module to ship anything, they are not two autonomous squads; they are one team with a communication problem and two standups. Renaming them does not decouple them. See the-dependency-mathematics-of-scaling for why this dominates everything else.
What is worth taking, honestly
Dismissing the whole thing is as unserious as copying it. There are real ideas in there, and they are portable if you take them as principles and design your own structures around them.
Separate the work axis from the craft axis. Whatever you call them, having one structure that decides what a person works on and another that develops how well they do it is a genuine improvement on pure functional or pure cross-functional organisation. You do not need chapters. You need someone accountable for engineering standards who is not the same person accountable for this quarter's delivery.
Make autonomy conditional and explicit. The useful formulation is that a team earns decision rights by demonstrating the capability to exercise them — a working definition of done, automated tests, the ability to roll back. Autonomy granted without capability is negligence; autonomy withheld from a capable team is waste. Write down which decisions each team can make alone, which require consultation, and which require approval, and shorten that last list deliberately over time.
Invest in alignment so that autonomy is affordable. The hard part of decentralisation is not letting go; it is framing problems precisely enough that decentralised decisions converge. That is a leadership craft, and it is the part organisations skip. If your teams keep making decisions you would not have made, the usual cause is that the constraints and the intent were never articulated, not that the teams need more oversight.
Take the failure-tolerance posture seriously. Limited blast radius, quick rollback, and treating incidents as learning rather than as grounds for punishment is a Westrum-generative stance, and it is a precondition for the rest. An organisation that punishes failure will centralise decisions no matter what its org chart says, because individuals will rationally escalate anything risky.
Copy the reasoning, not the artefact. The most useful thing in the original material is that its authors explained why they had arranged things as they had. That reasoning applies to your constraints, which differ. Your answer should therefore differ. An organisation arriving at exactly squads, tribes, chapters and guilds from first principles would be a coincidence worth investigating.
The deeper lesson about copying
The Spotify case is the most visible instance of a pattern that repeats: an admired organisation's structure is copied while its practices, constraints and history are not. It happened with Toyota's production system, where the visible artefacts — andon cords, kanban cards, standardised work — travelled widely while the underlying management system and the decades of capability-building travelled hardly at all. It will happen again with whichever company is currently admired.
The mechanism is always the same. Structure is cheap to observe and cheap to implement. Practice is expensive to observe and expensive to implement. So the observable, cheap part gets copied, the causal part does not, and when the results fail to appear, the conclusion drawn is that the original account was overstated rather than that the copy was partial.
The defence is to ask, of any admired practice, what conditions had to hold for it to work — and then to check honestly whether those conditions hold for you. If they do not, you have two options: build the conditions, which is slow and unglamorous and is the real work, or design something different that fits the conditions you actually have. What is not available is adopting the structure and hoping the conditions follow.
What to do on Monday
If you are mid-adoption, stop the structural rollout and answer one question per team: can this team get a small change into production, on its own, in a day? Not in principle. Last Tuesday, with a real change. Count the approvals, handoffs and other teams involved.
If the answer is no for most teams, the squad naming is cosmetic and the useful work is elsewhere — deployment pipeline, test automation, service ownership, decision rights. Redirect the reorganisation budget into that, and keep whatever team names you already had; nobody has ever shipped faster because of a noun.
If you are pre-adoption, write down the three problems you expect the structure to solve, and for each one identify the mechanism by which a new org chart would solve it. Where you cannot name a mechanism, you have found a problem that the reorganisation will not fix and that will still be there afterwards, now with less credibility available to address it.