The Spotify Model: What Remains of Squads and Tribes

The Spotify model is a snapshot of one company's organisation in 2012. What transfers is its principles: small autonomous teams with a clear mission, alignment through goals rather than instructions, and craft knowledge shared across teams. Companies that only introduce the names squad and tribe change job titles and org charts, while decisions and the flow of work stay as they were.

This article places the model in context, explains why many adoptions in mid-sized companies and large corporations have stalled, and gives you a checklist for deciding which elements suit your organisation.

What is the Spotify model?

The Spotify model describes how product development at the music service Spotify was organised around 2012. Henrik Kniberg and Anders Ivarsson published it in October 2012 as “Scaling Agile @ Spotify”. Two years later came the video series “Spotify Engineering Culture”, in which the company explained how it worked. Both sources present themselves as a record of a company that keeps changing, not as a method for others to implement.

The building blocks are easy to explain. A squad is a small cross-functional team that owns a clearly defined part of the product and decides for itself how it works. Several squads working on related topics form a tribe, which the description limits to roughly one hundred people so that members still know each other. A chapter brings together people of the same discipline within a tribe under a line of professional leadership, for example all back-end developers. A guild is a voluntary community across tribes that looks after a subject such as test automation or web development.

The result is a matrix, though a different one from the classic. Squads run the daily work, chapters look after professional quality and the development of people, and guilds spread knowledge. The autonomy of the squads rests on a condition stated in the description itself: squads must understand the company's goals and align with them. Autonomy without shared direction produces teams that quickly run in different directions.

Why do many adoptions of the Spotify model fail?

Many adoptions fail because they copy the structure and leave out the conditions under which the structure works. The developer Jeremiah Lee described this in 2020 in his post “Spotify's Failed #SquadGoals”. Drawing on his time at Spotify, he reported that the organisation was never set up the way the paper suggests: squads stayed dependent on one another, and coordination partly ran through the very mechanisms the model was meant to make unnecessary.

Four recurring causes show up in companies that adopt the model.

The first is confusing a description with a recipe. The paper does not explain how a company gets from a line organisation to squads, which roles disappear or how budgets are redistributed. Whoever plans the transition has to work out these answers alone.

The second is renaming existing units. The department becomes a tribe, the project team becomes a squad, the team leader becomes a chapter lead. Decision rights stay where they were, and teams soon notice that nothing has changed except the vocabulary.

The third is the way teams are cut. Spotify cut squads along product areas that can change largely independently of one another. An organisation with strong dependencies, such as a shared core platform or regulated processes, cannot apply the same pattern without adjustment. Melvin Conway's observation from 1968 applies here: organisations produce systems that mirror their communication structures. Teams cut differently from the architecture create coordination effort at every interface.

The fourth is missing leadership work. Autonomous teams need goals to align their decisions with, and leaders who set priorities and leave the tasks to the team. Without that, teams end up with plenty of freedom and no direction.

Which companies adopted the model?

The best-known case is the Dutch bank ING, which from 2015 reorganised its Dutch headquarters into squads, tribes and chapters, modelled on the Swedish example. The company itself later spoke of its own adaptations and of a way of working that kept evolving. The lesson from this case is that an adoption takes years, involves senior leadership and requires adjustments that appear in no paper.

Companies of different sizes in the German-speaking region report similar experiences. The start is easy because squads can be formed quickly. The difficulty begins when budgets and career paths have to follow the same change. As long as people management thinks in departments and financial planning in cost centres, the squad remains a project group with a new name.

What remains useful in the Spotify model?

Four principles remain useful, whatever the terminology.

The first is a clear mission. A team that is responsible for a defined part of the product or the customer experience, and has the means for its work, delivers faster than a team working through requests from five departments. The second is separating the steering of daily work from professional development: the person who sets priorities does not also have to own people's careers and skills. The third is voluntary exchange across team boundaries, which spreads knowledge without building a new hierarchy. The fourth is alignment through goals and bets, which gives teams a shared picture of why they work on what they work on.

Anyone wanting to apply these principles to their own organisation will find worked-out recipes in other models. Team Topologies by Matthew Skelton and Manuel Pais describes four team types and three interaction modes, and so supplies what the Spotify paper lacks: rules for how to cut teams and how teams collaborate. The article on Team Topologies shows what this looks like. Where dependencies affect many teams, Flight Levels offer a view of coordination across three levels, and the unFIX model provides organisational building blocks that can be combined.

When does a Spotify-style approach pay off?

A Spotify-style approach pays off when three conditions coincide: the company develops a product or platform with several areas that can change largely separately, leadership is willing to give up decision rights, and there is a critical mass of roughly five to ten teams that really do suffer coordination problems. With fewer teams, a well-run Scrum or Kanban system with one shared list to settle the order is enough.

How do you introduce elements of the model step by step?

You introduce elements step by step by starting with one area where the team cut is clear, and by measuring the change in decisions rather than in names. In a manageable organisation this works in five steps.

1. One pilot area: choose a product area with manageable dependencies and a leader who genuinely wants to hand over decision rights.
2. Mission and goals: write down for each team which part of the product it owns, which metric it should move and which decisions it takes without asking.
3. Clarify professional leadership: decide who is responsible for people's development once the line no longer steers daily work, and how appraisals come about.
4. Count dependencies: record for four weeks how often one team waits for another. The number shows whether the cut is right.
5. Assess after three months: compare lead time and waiting time against the baseline and decide whether to extend the approach.

The Spotify model and delivery: what decision makers should check

From a delivery perspective, what counts in the end is whether results reach the customer faster and more reliably. An organisation model is a means to that end. A few metrics make the check possible: lead time from idea to release, the number of handovers and the time work spends in queues. If these values do not improve after the reorganisation, the reorganisation was cosmetic. More on these measures is in the article on flow metrics.

Organisation design with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the service area of delivery management and organisation design he works as delivery manager or product owner and designs team cuts and decision paths.

The approach follows the Niehues Delivery Model with its three phases: understand, build and introduce. Three of its test questions matter most for a reorganisation: Who decides, who delivers, who uses? Which roles, decision paths and interfaces does operations need? Who is responsible for operations from day one? You start with a free initial consultation of 30 minutes, which you can book via the contact form. The scope and terms of an engagement are discussed in the free initial consultation.