The Spotify Model, Mapped

The Promise of the Spotify Model

The “Tribes and Squads” model, also known as the Spotify model, offers a fresh view of old problems. Henrik Kniberg coached at Spotify around 2012, where he described their unique scaling model, initially proposed by Joakim Sundén and his colleagues. His cartoon series sparked worldwide interest, and the model reached the large market thanks to large consulting firms. The promise: your organization will become agile by defining value areas and creating autonomous, fast-to-deliver teams working in them.

First, let’s clear the fog from the names. Essentially, a squad is a team, a team on a mission. A tribe is a group of teams sharing some high-level common goal, for instance, the needs of a specific customer segment or the success of some customer journeys. A more generic name for this is a value area. The teams in a value area should share and work off a single tribe-level product backlog ordered by a tribe lead.

Where the Spotify Model Sits on the Map

From the book 10X ORG: the Scaled Agile Framework (SAFe) and the McKinsey-popularized Spotify Model (“Squads, Tribes, and Guilds”) can drive the creation of a Delivery Topology when skills mandates expand and real teams form. But in our experience, in most cases, due to a lack of org design skills and other political factors, these frameworks result in Resource Topologies, driving no real change. They are widely adopted, but popularity does not equate to fitness.

On the Scope of Skills Mandate, it depends on the teams. If squads are dedicated to architectural elements, such as components, subsystems, services or platforms, they don’t deliver customer value on their own: someone external must break down requests, assign the parts, and manage the dependencies. If the teams are fluent at delivering features independently, they can span much further. It is very much contextual.

On the Scope of Work Mandate, what we see in the industry is that the vast majority of squad and tribe adoptions are at the lowest level. Customer discovery and business analysis specialists understand the customer domain, while it is considered “expensive and inefficient” to involve developers. Middlemen prepare output-level backlogs for the teams, which isolates the teams from customers and business. They stop learning.

Expectations and Reality

Well-written materials on the model describe “a team structure mostly aligned to customer and user journeys” and “dedicated teams to grow selected businesses.” In reality, when we talk to organizations after their transformation projects are “successfully accomplished” and the consultants are gone, we often see something else:

• Non-autonomous teams owning internal concerns like components and services, bogged down with interdependencies.
• Value areas with an Area Lead almost like a real Product Owner for the area, but each team with its own team-level backlog and output owner. This kills the idea of managing at the value-area level: with work defined at the team level, each team has its own focus and agenda.
• Teams named after product parts, a “search service team,” a “mobile team,” a “reports team,” fixed long-term to those parts, so they work only on what they already know.
• In some cases, SAFe applied on top to deal with the blocking dependencies between teams.

Worse, such an organization might truly believe it has transformed, while it only uses new terminology. Each team’s focus is very narrow, but the organizational focus is spread too broad. Every change of strategy is a tragedy, not an opportunity.

Squads and Tribes as Divide and Conquer

The book puts “Squads and Tribes” first on its list of the industry’s best practices for slicing organizations into parts, a pattern it calls divide and conquer. Each unit owns a clearly bounded area, and locally this works. But how long does that fit last? What happens when a “tribe” can no longer help another one because it is busy delivering its own roadmap, and, as tribes do, begins protecting its turf when resources feel scarce?

Aligned Autonomy at Scale

Kniberg’s matrix of alignment and autonomy makes a key point: they are not two ends of one continuum, and we need both. To have teams with full autonomy (not isolation) that remain aligned (through collaboration), we need an organizational design with wide mandates on both the scope of work and the skills to perform that work. That means abandoning the idea of independent, autonomous teams and creating cohesive multi-team units: a team of teams. At Spotify itself, they created a space for collaboration with many cross-team structures and meetings.

Autonomy at scale requires a broad scope of work and skills to facilitate alignment through collaboration.

Read more in Aligned Autonomy at Scale.

Towards Better Organizations with Tribes and Squads

Are we against squads and tribes? Of course not. If you can envision your target state, any intermediate state can be a good next step. To avoid getting stalled:

1. Manage the product backlog at the tribe level, by a knowledgeable and respected domain expert with power and budget.
2. Make that leader the tribe’s only product owner who gives work to teams. Bring analysts and other specialists back into the squads as team members.
3. Create an environment where all squads of a tribe work together and feel the work is shared.
4. Let the squads meet regularly to agree on how to pull items from the single outcome-oriented backlog, respecting the product owner’s priorities.
5. This way, the squads share work and learn together, enriching the organization’s capability to innovate and adapt.
6. Squads, their product owner and general management work together to remove systemic impediments to the points above.

Read Tribes and Squads: How Adaptive Is That?, see the three topologies, or map your own tribes in the C-OTC class. The whole argument is in the book 10X ORG at 10xorg.com.