Spotify Model: Theory vs Modern Practice

In 2016, I was engaged by Boston Consulting Group to contribute to the Agile transformation of BNP Paribas Group. At the time of my arrival, the program lead had already selected the “Spotify model” as the target organizational design.

While I was familiar with the concept through Henrik Kniberg’s presentation, I expressed early concerns regarding its applicability. My initial assessment was that it largely represented a rebranding of existing structures — communities of practice and traditional Methods and Tools functions — rather than a fundamentally new organizational paradigm.

Several years later, in 2020, I encountered the same model again at Swiss Re, also introduced by BCG, where I contributed as an external consultant. Over this six-year period I researched the rationale behind adopting it. Its primary value, I concluded, lies in addressing functional silos — specifically the unbundling of entrenched “baronies,” a term I first encountered during a workshop at GDF Suez Europe on scaling agility.

By 2020, my work on the Adaptive Organization (AO) Method was well advanced. With my client we explored how to redefine the role of the line manager, introducing three distinct orientations — product, people, and knowledge — to shift from an output- and cost-driven model toward an outcome- and profit-driven one.

This led to a further reflection: are these three domains truly of equal weight? The fundamental purpose of any business — including research-driven ones — is to generate value, financial or intellectual. In practice, product remains the primary vehicle. I began to prioritize product as the leading orientation, with people and knowledge as critical enabling conditions. People and learning are not secondary in importance; they are necessary foundations for the creation of valuable products, which remain the primary organizational intent.

Report

A Research Comparison Report for Leaders Evaluating Agile Organizational Design

Executive Summary

The so-called “Spotify model” has become one of the most referenced — and most misunderstood — organizational frameworks in modern software engineering. Born from a 2012 whitepaper by two agile consultants describing how one fast-growing startup organized its teams, it was never intended as a replicable blueprint. Yet thousands of companies have tried to copy it wholesale, renaming their teams “squads” and their departments “tribes” while leaving underlying power structures, incentives, and culture entirely unchanged.

This report examines the original 2012 theory against its documented performance in large-scale engineering organizations, maps where specific elements genuinely add value versus where they predictably collapse, and provides a structured scorecard leaders can use to evaluate whether to selectively adopt components such as squads, guilds, or chapters within their own departmental structure.

The Whitepaper in Context

In October 2012, Henrik Kniberg (agile coach) and Anders Ivarsson (organizational developer) published “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” through Crisp’s blog. The document described how Spotify, then operating approximately 30 squads across 250 technology employees, had evolved its development organization.

“This is not a recipe. It is a snapshot of what we are doing right now.”

Henrik Kniberg — Scaling Agile @ Spotify, 2012

The whitepaper’s closing line reinforced this: “By the time you read this, things have already changed.” Kniberg has consistently reiterated since 2015 that the document was never intended as a generic framework. The “Spotify model” label was attached by the wider agile community, not by Spotify.

At the time of publication, Spotify had three critical contextual advantages:

1. Homogeneous engineering culture — the entire company had grown organically from a single product with shared technical values.
2. Service-oriented architecture — Spotify had already decomposed its monolith into over 100 independently deployable services, giving squads genuine technical independence.
3. Small scale relative to ambition — at 250 engineering employees, social coordination was still feasible through informal channels; Dunbar-number constraints had not yet been tested.

The Four Structural Elements

The architecture was described as a “matrix weighted towards delivery” — the squad (what gets built) is the primary axis; the chapter (how it gets built well) is secondary. This deliberate weighting was the key design choice, and it is also the one most commonly inverted when other organizations implement the model.

The whitepaper also described two often-overlooked roles: the System Owner (responsible for the integrity of a specific technical component across all squads touching it) and the Chief Architect (providing advisory coordination on cross-system issues). Neither appears in the famous diagram, which is one reason most implementations omit them entirely.

What the Authors Acknowledged as Incomplete

Even at the time of publication, the authors flagged:

• Uneven chapter distribution across squads.
• Ongoing struggles with release processes.
• Insufficient agile coach coverage for all squads.
• Organizational growing pains from tripling headcount in 18 months.
• A reactive (survey-based) dependency management framework, not proactive.

Where the Model Succeeds

Where the Model Breaks Down

Dependency management

The whitepaper treated cross-squad dependencies primarily as a measurement problem — survey quarterly, reduce blocking dependencies. This assumption held at 30 teams. It breaks catastrophically at 200+ teams.

“Allowing every team to have a unique way of working meant each team needed a unique way of engagement when collaborating. Overall organization productivity suffered.”

Jeremiah Lee, former Spotify engineer — Failed #SquadGoals, 2020

ING’s post-Spotify evolution — toward LeSS with shared product backlogs — was driven precisely by this: squad-level autonomy had created 24 parallel product backlogs, many working on lower-priority items simply because that was “their piece” of the system.

Matrix management and ownership ambiguity

The chapter lead structure creates a dual reporting line: engineers report to a chapter lead for career development, but work within a squad led by a product owner. In practice, this creates three well-documented failure modes:

1. The product manager had no technical peer — there was no “mini-CTO” to match the “mini-CEO” model.
2. When engineering teams couldn’t reach consensus, escalation required coordination across multiple chapter leads with limited daily context.
3. Chapter leads had formal authority (salary, career) but no delivery accountability — neither line managers nor team members in any meaningful sense.

Scalability beyond startup phase

“Organizing the entire company around Scrum principles worked well for Spotify in the phase when the entire company was built around one product, in its growth phase. But as parts of it matured, and as maintenance effort became significant, the famous Spotify Model wasn’t working that well anymore.”

Matthias Patzak, 2025

Missing technical prerequisites

The most overlooked sentence in the original whitepaper:

“Spotify technology is highly service-oriented. There are over 100 distinct systems. Each system can be maintained and deployed separately.”

Kniberg & Ivarsson, 2012

The model was built on — and depends on — a decomposed architecture. Organizations that try to implement squad autonomy while retaining monolithic or tightly coupled systems end up with structures that promise independence but cannot deliver it.

The following anti-patterns have been identified consistently across agile coaches, former Spotify employees, and organizations that have publicly documented their transformation attempts (ING, Deutsche Telekom, various consulting-sector case studies).

LeSS’s response to the Spotify model’s dependency problem is instructive: ING’s evolution from squads to a shared product backlog with 7–9 feature teams achieved better value delivery precisely because teams could be reallocated sprint-to-sprint against the highest organizational priority, rather than being locked to their squad’s fixed mission.

Team Topologies (2019) provides the most practical modern synthesis: it retains the squad concept (stream-aligned teams) while adding explicit cognitive load constraints, platform teams that reduce coordination overhead, and formalized interaction modes that address the cross-team dependency problem the Spotify model left unresolved.

How to Read the Scorecard

Each cell reflects the fit between an organizational criterion and a specific component, based on documented outcomes across multiple implementations. “High” means the component adds clear value when this criterion is present. “Low” means the component will likely create problems or deliver limited benefit under this condition.

Scoring Your Organization

Score each question 0 (No), 1 (Partially), or 2 (Yes). Maximum score: 20.

1. Squad readiness

   Do teams own end-to-end delivery of a stable product or feature area (not project-based)?

2. Autonomy culture

   Can teams make technology and process decisions without management approval?

3. Alignment prerequisite

   Has leadership defined measurable company priorities that teams can use to negotiate cross-team tradeoffs?

4. Technical prerequisite

   Is your architecture decomposed sufficiently for teams to deploy independently?

5. Support capacity

   Do you have agile coaches (or equivalent) for every 3–4 teams?

6. Chapter viability

   Can chapter leads spend at least 20% of their time on coaching and standards (not just delivery)?

7. Guild viability

   Do people have enough slack to participate in guilds without it counting against team capacity?

8. Culture fit

   Is senior leadership willing to operate on quarterly (or faster) strategic cycles, not annual?

9. Implementation discipline

   Are you prepared to run a 6-month pilot in one area before scaling?

10. Change management

    Has leadership explicitly separated the structural change (new org chart) from the cultural change (new behaviours)?

Score Interpretation

Component-Specific Adoption Guidance

Closing

Conclusions

The Spotify model’s enduring value lies not in its org chart but in three underlying principles that hold regardless of vocabulary:

1. Stable, cross-functional teams with genuine delivery ownership consistently outperform functional silos organized around specializations.
2. Autonomy and alignment are co-requisites — neither works without the other; the model’s failure to fully document alignment mechanisms is its most consequential omission.
3. Structure follows architecture — no organizational model can deliver independent team autonomy on top of a tightly coupled technical system.

Organizations that have successfully adapted elements of the Spotify model (ING in its early phase, Deutsche Telekom, select engineering organizations at SAP-adjacent digital units) have done so by treating it as a source of mental models, not a deployment playbook. They adapted the principles to context, ran pilots before scaling, and were willing to evolve the model — including away from it — when evidence demanded.

“Quick trivia: how many organizations working according to the so-called ‘Spotify Model’ do you know? Because I know none. Including Spotify itself.”

Scrum.org — 10 Lessons in Transplantology

The question is not whether to adopt the Spotify model. It is which of its principles address your actual organizational constraints — and whether you have the conditions to make those principles work.

References

Sources

1. Kniberg & Ivarsson — Scaling Agile @ Spotify, Crisp, 2012.
2. Jeremiah Lee — Failed #SquadGoals, 2020.
3. Atlassian — Spotify Model Guide.
4. ING Bank — Agile Transformation Case Study.
5. ING — LeSS Improvement Analysis.
6. SI Labs — Spotify Model Analysis.
7. Echometer — Anti-Patterns Guide.
8. Agile Pain Relief — Spotify Model Critique.
9. Medium — Overcoming Pitfalls.
10. Scrum.org — 10 Lessons in Transplantology.
11. ING — Death of the Spotify Model (video).