In 2012, Henrik Kniberg and Anders Ivarsson published “Scaling Agile @ Spotify,” a whitepaper describing how Spotify organized its engineering teams. Within two years, animated videos explaining the model had gone viral in product and engineering circles. Hundreds of companies reorganized around squads, tribes, chapters, and guilds. Most of them failed.
The uncomfortable truth, confirmed by former Spotify employees: Spotify itself was never fully running the model the whitepaper described.
The Four Building Blocks
The original structure had four components, each solving a different coordination problem.
Squads were cross-functional teams of six to twelve people: a product owner, developers, a designer, sometimes a data analyst or QA engineer. Each squad owned a specific feature area end to end and operated with significant autonomy over what to build and how to build it.
Tribes grouped related squads together, capped at roughly 150 people (following Dunbar’s number) to keep communication manageable. A tribe might own an entire product surface like “Search” or “Payments.”
Chapters provided functional alignment within a tribe. All backend engineers across squads in a tribe formed a backend chapter, led by a chapter lead who served as their line manager and handled career development.
Guilds were voluntary, company-wide communities organized around shared interests: a testing guild, a web technology guild, an agile coaching guild. Participation was optional and cross-cutting.
On paper, the structure balanced autonomy (squads choose how to work) with alignment (tribes share a mission) and professional growth (chapters connect specialists). The 2014 animated videos made the whole thing look elegant.
The Gap Between the Whitepaper and Reality
Anders Ivarsson, co-author of the original whitepaper, later acknowledged the disconnect: “Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation.” The whitepaper was supposed to be the first in a multi-part series. Sections on alignment and accountability were planned but never published.
Jeremiah Lee, a product manager at Spotify from 2017 to 2019, arrived at the company after it had tripled to 3,000 employees in 18 months. What he found was not the smooth, autonomous structure from the videos. He described “organizational chaos” as leaders were already transitioning toward more traditional management structures. When Lee asked why the public documentation had not been updated, colleagues told him the original content was “great for recruiting.”
Joakim Sunden, a Spotify agile coach from 2011 to 2017, put it bluntly in a later interview: chapter leads were “servant-leaders who help you grow. They don’t have accountability for delivery.”
That single sentence captures the core structural problem. The model separated authority over people (chapter leads) from responsibility for outcomes (product owners), and nobody had both.
Three Specific Failure Modes
The Chapter Lead Collision
Product managers at Spotify operated without an engineering management counterpart on their squad. When a PM needed to resolve a technical disagreement, there was no single engineering manager to partner with. Instead, the PM had to escalate to as many chapter leads as there were engineering specializations on the team. A squad with backend, web, and mobile engineers meant negotiating with three separate managers, none of whom were accountable for that squad’s delivery timeline.
Autonomy Without Shared Process
Each squad could adopt whatever working practices it preferred. Sunden noted the consequence: “Every time you have a new team, they have to reinvent the wheel in how they should be working.” Jason Yip, another Spotify agile coach (2015 onward), identified the compounding problem: “If you have inconsistent ways of working, it’s more difficult for people to move… reinforcing until you’re not really working for the same company anymore.”
This played out in codebases too. Squads made independent technology choices, which fragmented the architecture. The individual teams were often effective, but the collective of autonomous teams was frequently not.
Assumed Competence in Collaboration
The model assumed that talented engineers would naturally collaborate well across squad boundaries. They often did not. Teams lacked a common language to discuss process problems. The company did not have enough agile coaches to support every squad, and the coaches who existed operated as internal consultants with limited engagement windows.
Companies That Copied the Structure Without the Culture
ING Bank reorganized 3,500 employees into squads and tribes, becoming the most visible financial services adopter. The move got significant press coverage. What received less attention: ING paired the Spotify terminology with Scaled Agile Framework (SAFe) governance, microservices architecture, and years of culture change work. The structure alone was not the intervention. The multi-year transformation effort underneath it was.
A financial services company in the DACH region (Germany, Austria, Switzerland) attempted to implement the model across an 800-person IT department. Leadership expected the transition to take three months. It took three years. The gap between a 250-person homogeneous software startup in Stockholm and a 15,000-employee insurer with 200 years of institutional history was far wider than the org chart suggested.
This pattern repeated across industries. Companies renamed existing teams to “squads” and departments to “tribes” without changing decision-making authority, career paths, or accountability structures. The result was old hierarchy in new packaging.
What Spotify Actually Uses Now
By 2026, Spotify’s organizational structure has evolved well past the original whitepaper. The company employs roughly 7,300 people and serves over 600 million users. The engineering organization uses a structure closer to a conventional product-and-platform shape with autonomous teams rather than the formal squad/tribe/chapter/guild hierarchy.
Key changes from the original model:
System owners replaced the ambiguous chapter lead accountability structure. These individuals or pairs take responsibility for the long-term health of critical technical systems, cutting across team boundaries.
The DIBBs framework (Data, Insights, Beliefs, Bets) became Spotify’s decision-making tool, providing transparency and alignment that the original model lacked.
Engineering managers with direct accountability for delivery now partner with product managers, replacing the chapter lead structure that separated people management from outcomes.
Culture interviewers during Spotify’s hiring process in 2026 test for the underlying values (autonomy, alignment, cross-functional collaboration) rather than knowledge of the original squad model terminology.
What Replaced the Spotify Model in the Broader Market
The most significant alternative to emerge is Team Topologies, published by Matthew Skelton and Manuel Pais in 2019. Where the Spotify model described a specific company’s aspirational structure, Team Topologies offers a framework for designing team structures based on cognitive load and communication patterns.
The framework defines four team types:
- Stream-aligned teams work toward direct business outcomes (similar to squads, but with clearer scope boundaries)
- Platform teams provide shared capabilities as self-service internal products
- Enabling teams temporarily embed with other teams to transfer skills, then disengage
- Complicated subsystem teams handle specialized technical domains requiring deep expertise
Team Topologies also defines three interaction modes (collaboration, X-as-a-Service, facilitating) that make the relationships between teams explicit rather than assumed.
The practical advantage: Team Topologies requires fewer cultural prerequisites. A company does not need Spotify’s specific culture of psychological safety and experimentation to implement it. The framework works through evolutionary change rather than a revolutionary restructuring.
AWS now references Team Topologies in its Well-Architected DevOps guidance. Atlassian, Martin Fowler, and the IT Revolution community all recommend it as a starting point for team design. Many organizations run hybrid approaches, combining squad-like autonomous teams with Team Topologies’ platform and enabling team patterns.
The Principles Worth Keeping
Strip away the terminology and the organizational chart, and the Spotify model contained four ideas that remain sound:
Cross-functional ownership. A team that contains every skill needed to deliver its mission (product, engineering, design) moves faster than a team that depends on handoffs to other departments.
Small team size. Six to twelve people remains the optimal range for a delivery team. Research on team effectiveness from J. Richard Hackman at Harvard consistently supports this range.
Loose coupling between teams. Teams that can ship independently, without waiting for coordinated releases across the organization, deliver more frequently and with fewer defects.
Mission clarity. A team with a clear, bounded mission makes better prioritization decisions than a team that serves as a shared resource for the broader organization.
These principles predate the Spotify model and will outlast it. They show up in Team Topologies, in Amazon’s two-pizza teams, in Basecamp’s Shape Up methodology. The problem was never the principles. The problem was packaging them as a specific org chart and implying that copying the chart would produce the same results.
In twenty years of IT operations, I watched multiple organizations attempt the same pattern: take a successful company’s structure, rename the boxes, and expect the culture to follow. The culture never follows the org chart. The org chart follows the culture, or the restructuring fails.