Overcoming the Pitfalls of the Spotify Model
How Spotify’s Aspirational Framework Failed in Practice and the Targeted Fixes That Could Have Saved It
The Spotify model’s documented form represented aspiration rather than reality. Anders Ivarsson, co-author of the original white-paper, admitted the framework was “part ambition, part approximation” that Spotify wasn’t actually implementing even at the time of publication. The company tripled to 3,000 people between 2012 and 2017 whilst the documented model remained frozen, creating a widening gap between mythology and operational reality. Recruiters began warning candidates not to expect an Agile utopia. Leadership incrementally transitioned to traditional management structures, effectively abandoning the model whilst leaving the aspirational documentation in place. This trajectory suggests structural flaws rather than scaling challenges.
The model didn’t fail because it was radical. It failed because it combined legitimate organisational insights with design choices that created predictable coordination failures. Spotify’s mistake wasn’t attempting the model but abandoning it rather than fixing identifiable problems. The framework’s core concepts remain sound if properly implemented.
Matrix Management Created Accountability Voids
Engineering managers operated outside squad boundaries, managing all engineers of a specific specialisation across an entire tribe. Backend engineers across multiple squads reported to one chapter lead, Android engineers to another. This structure meant product managers had no technical counterpart at the team level. When squad-level technical decisions required management input, product managers faced negotiation with multiple chapter leads simultaneously.
Disagreements within a squad’s engineering team forced product managers to negotiate with all engineers directly. Without consensus, escalation required engaging every chapter lead represented on the squad. A squad with backend, web, and mobile engineers necessitated coordinating at least three engineering managers. If chapter leads couldn’t align, issues escalated to the tribe’s engineering director. This created cascading escalation paths where simple technical decisions became multi-manager negotiations.
Chapter leads functioned as servant leaders focused on career development. They lacked delivery accountability or involvement in daily squad context. This limited their ability to resolve interpersonal conflicts or assess team dynamics. Product managers effectively became the only manager figure within squads, creating role confusion and accountability gaps.
The fix doesn’t require abandoning matrix management entirely. Assign a technical lead within each squad who reports to the relevant chapter lead but holds delivery accountability for that squad’s engineering outcomes. This lead serves as the product manager’s technical counterpart, possessing authority to make squad-level decisions and negotiate prioritisation trade-offs. The chapter lead retains responsibility for career development, technical standards across squads, and cross-squad coordination within their specialisation. This preserves the benefits of specialist community building whilst establishing clear squad-level accountability.
Engineering managers must own both technical leadership and delivery execution, not merely career development. The technical lead role should include authority matching the product manager’s scope, creating a balanced leadership pair. Escalation paths become simpler: squad-level issues resolve between product manager and technical lead, with chapter leads involved only for cross-squad technical coordination or personnel matters.
Autonomy Without Boundaries Produced Fragmentation
Spotify prioritised team autonomy as documented in its 2012 model but failed to complete planned sections on alignment and accountability. Ivarsson acknowledged the series remained unfinished. This created teams with freedom to choose working methods but insufficient guidance on collaboration patterns. Each squad developed unique processes, making cross-team collaboration require custom coordination approaches. No common process existed for managing dependencies between squads.
As Spotify grew, functions duplicated across squads consolidated into dedicated teams for efficiency. This increased squad focus but created new cross-team dependencies. Teams that previously handled something internally now relied on another squad. Without standardised engagement patterns, each dependency became a negotiation about how to work together rather than simply executing the work.
Agile coach Joakim Sundén reflected that over-focusing on autonomy meant “every time you have a new team, they have to reinvent the wheel in how they should be working”. He suggested Spotify needed “minimum viable agility” as a starting baseline, with teams free to opt out rather than requiring constant opt-in decisions.
Jason Yip, another Spotify agile coach, noted that inconsistent working methods made moving between squads difficult, which reinforced further inconsistency. This created organisational fragmentation where “you’re not really working for the same company anymore. You’re working for these kind of weird subcultures”.
The fix requires defining minimum viable process standards that enable coordination without constraining squad-level optimisation. Establish baseline practices for dependency management, cross-squad collaboration interfaces, and escalation patterns. Squads can customise internal processes but must conform to external interfaces that make inter-squad work predictable.
Leadership must articulate strategic priorities that bound autonomous decision-making. Autonomy means choosing how to achieve defined outcomes within established constraints, not selecting which outcomes to pursue. Implement alignment frameworks like OKRs to provide top-down coherence whilst preserving squad execution freedom. Define how success gets measured so squads can effectively negotiate dependency prioritisation with evidence rather than politics.
Create standardised templates for common collaboration patterns: how squads request work from platform teams, how dependencies get tracked and communicated, how conflicts over prioritisation escalate. These standards reduce coordination overhead from bespoke to routine. Squads spend energy solving problems rather than negotiating working arrangements.
Balance emerges from clarity about what remains fixed versus what stays flexible. The interfaces between squads must be stable and predictable. Internal squad processes can vary. This preserves autonomy where it creates value whilst eliminating fragmentation where it destroys productivity.
Collaboration Competency Was Assumed, Not Built
Spotify granted squads control over their working methods without ensuring baseline Agile knowledge existed. Many people lacked understanding of fundamental Agile practices. Squads iterated through process changes hoping to discover combinations that improved delivery, but without common language to discuss problems, education to solve them, or experience to evaluate outcomes.
Agile coaches existed as internal consultants available to squads. Their numbers proved insufficient to serve every team. Engagements rarely lasted long enough to span project completion, preventing coaches from helping squads evaluate performance over full cycles. Coaches held no accountability for outcomes, limiting their effectiveness as consultants rather than embedded capability builders.
The autonomy granted to squads exceeded their competency to exercise it effectively. L. David Marquet’s principle applies: “Control without competence is chaos”. Spotify provided control without ensuring competence, creating chaotic experimentation rather than informed adaptation.
The fix requires comprehensive Agile training as organisational infrastructure, not optional enrichment. Establish shared vocabulary and baseline practices company-wide before granting process autonomy. Squads should start from common foundations and adapt based on informed understanding, not reinvent practices from scratch.
Coaching must be sustained and embedded rather than sporadic and consultative. Assign coaches to squads for extended periods spanning multiple delivery cycles. Coaches should participate in retrospectives, planning, and execution to provide continuous feedback and skill development. Make coaching accountable for capability development outcomes, not just advisory engagement.
As squad count grows, introduce programme management as a dedicated function. Programme managers coordinate cross-squad initiatives, facilitate dependency management, and structure collaboration at scale. This role bridges the gap between autonomous squads and organisation-wide coordination needs, similar to how product managers and engineering managers serve their respective domains.
Programme managers establish planning processes that work across squads with varying maturity levels, reducing friction from inconsistent practice. They translate strategic priorities into coordinated squad activities, ensuring autonomy aligns with business objectives. This function becomes essential when squad proliferation exceeds informal coordination capacity.
Building collaboration competency takes time and investment. Spotify attempted to shortcut this by granting autonomy immediately and hoping competency would emerge. The sequence must reverse: build competency first through training and mentorship, then grant autonomy as capability develops. Teams earn greater independence by demonstrating capacity to deliver results and coordinate effectively with dependencies.
Accountability Lagged Behind Autonomy
Spotify’s documentation emphasised squad autonomy but the promised sections on accountability never materialised. Squads received freedom to operate without corresponding pressure to deliver outcomes aligned with business objectives. Chapter leads managed career development but held no delivery accountability. Product managers lacked equivalent engineering peers to share ownership of results. This created autonomy without consequence.
Sundén admitted that had he approached things differently, the focus wouldn’t have been “so much on autonomy”. The model granted control without establishing clear ownership of results. Squads optimised for local preferences and interesting work rather than business value. Without defined success metrics or accountability mechanisms, autonomy became disengagement from organisational priorities.
The absence of completed guidance on accountability meant squads operated in a vacuum regarding performance expectations. How should squads justify their independence? What evidence demonstrates effective use of autonomy? These questions remained unanswered, creating uncertainty about what success looked like beyond shipping features.
The fix requires explicit outcome metrics tied to business results at both squad and individual levels. Product management becomes accountable for value delivery, measured through defined business metrics. Engineering becomes accountable for shipping done increments that meet quality standards and timelines. These accountabilities must be specific and measurable, not aspirational.
Get Shubham Sharma’s stories in your inbox
Join Medium for free to get updates from this writer.
Establish regular cadence reviews where squads report progress against objectives that matter to the organisation. Make these reviews substantive discussions about business impact, technical decisions, and trade-offs rather than status updates. Squads should articulate the business value delivered, risks managed, learning achieved, and next optimal moves. This forces explicit connection between squad activity and organisational outcomes.
Edwin Dando’s framework for balancing autonomy with accountability provides structure: mature squads justify independence through their ability to articulate business value, risk, learning, and direction. Squads that cannot make these connections convincingly require less autonomy until they develop the capability. Autonomy becomes earned rather than granted, tied to demonstrated capacity for effective independent operation.
Leadership must define how success gets measured and make these definitions visible across the organisation. Squads need clear understanding of strategic priorities to make good autonomous decisions. Without this context, autonomy devolves into teams working on what interests them rather than what matters. Measurement provides the feedback mechanism that makes autonomy productive rather than chaotic.
Accountability paired with autonomy creates healthy tension. Squads have freedom to determine how they work but face clear expectations about what they deliver. This balance prevents both micromanagement and drift, allowing innovation in execution whilst maintaining focus on results.
Terminology Obscured Reality
Spotify introduced vocabulary including squads, tribes, guilds, and chapter leads to describe its organisational structure. These terms created the impression of novel concepts requiring new language. Henrik Kniberg, who documented the model, clarified in 2015 that he didn’t invent it but served as “just the messenger”. The model resulted from collaborative experimentation, but the distinctive terminology suggested more innovation than actually existed.
Removing the unusual naming reveals the Spotify model as cross-functional teams with matrix management for engineers. Squads were simply teams. Tribes were departments. Guilds were communities of practice. Chapter leads were functional managers. The terminology didn’t describe fundamentally new concepts but rebranded existing organisational patterns with cooler-sounding names (Spotify explicitly chose “squad” because it sounded cooler than “team”).
This naming created problems beyond mere confusion. It gave the illusion the model represented breakthrough thinking that required learning new vocabulary to understand. When elements failed, addressing problems required confronting cultural identity rather than simply evaluating processes. The mythology became difficult to change because terminology had become embedded in how Spotify defined itself.
The fix requires using standard organisational language that communicates structure without cultural decoding. Cross-functional teams, departments, functional managers, and communities of practice convey the same concepts with immediate clarity. This eliminates the learning curve for new employees and simplifies discussions about organisational effectiveness.
Standard terminology enables better evaluation of practices against established research. When Spotify used distinctive names, it implicitly suggested existing organisational theory didn’t apply. Using conventional terms allows direct comparison with decades of research on team structures, matrix management, and cross-functional collaboration. This accelerates learning from both successes and failures.
Organisational design should adapt to operational needs rather than preserve terminology for identity reasons. If matrix management with chapter leads creates accountability problems, switching to embedded engineering managers shouldn’t require cultural reckoning. It becomes a straightforward process adjustment rather than abandoning core identity.
Most businesses can sustain only a few areas of innovation. Internal process rarely differentiates companies in the marketplace. Using proven organisational patterns with standard terminology frees innovation capacity for areas that matter to customers. Studying past organisational research allows better choices about where to experiment versus where to apply established practices.
Optimise for understanding. Every new concept requiring explanation to be productive carries cost. Evaluate custom terminology on whether it genuinely describes something novel that lacks existing language, or merely rebrands familiar concepts. Spotify’s terminology failed this test. Had the company used standard names, perhaps it could have evaluated practices more objectively when they underperformed rather than defending mythology.
Cross-Team Dependencies Lacked Infrastructure
As Spotify scaled from startup to 3,000 people, specialised functions consolidated into dedicated squads. Platform teams, infrastructure groups, and shared services emerged to reduce duplication and increase efficiency. This consolidation increased squad focus but created extensive cross-squad dependencies. Features requiring backend, web, mobile, and platform work now touched four separate squads instead of one.
The Spotify model provided no standard process for managing these dependencies. Each collaboration required negotiating engagement patterns, prioritisation processes, and communication cadences. The absence of defined protocols meant dependency management became a per-instance problem rather than a solved pattern. This multiplied coordination overhead as squad count increased.
The model’s emphasis on autonomy made dependency coordination harder. Autonomous squads controlled their own roadmaps and priorities. When Squad A needed work from Squad B, no clear mechanism existed for requesting, negotiating, or escalating that work. Product managers negotiated with other product managers, but without defined prioritisation frameworks or escalation paths, these conversations relied on relationships and politics rather than structured processes.
The fix requires formal cross-squad dependency management infrastructure. Establish standardised protocols for how squads request work from other squads, how these requests get evaluated and prioritised, and how conflicts over capacity or timing get escalated and resolved. Make dependency coordination a routine process with defined steps rather than a relationship-dependent negotiation.
Implement alignment frameworks like OKRs to provide top-down prioritisation context. When all squads understand organisational priorities and how their work contributes, dependency negotiations become objective discussions about aligned priorities rather than subjective debates about importance. Squad A can make cases based on business objectives rather than persuasive skill.
Create programme management roles responsible for coordinating multi-squad initiatives. These managers don’t own delivery but facilitate planning, track dependencies, identify conflicts early, and drive resolution. They provide visibility across squad boundaries that individual squads lack, enabling proactive coordination rather than reactive problem-solving.
Define service level agreements for common dependency patterns. If squads regularly need infrastructure changes, establish defined turnaround expectations and escalation procedures. If platform teams support multiple squads, create clear processes for requesting enhancements and understanding prioritisation decisions. These agreements set expectations and reduce friction from uncertainty.
Build dependency visualisation into planning processes. Multi-squad initiatives should explicitly map dependencies during planning, identifying required work from each squad and sequencing appropriately. This surface dependencies early when adjustments are cheap rather than discovering them during execution when delays cascade.
The infrastructure for dependency management scales better than ad hoc coordination. As organisations grow, structured processes become essential. Spotify’s mistake was assuming autonomous squads would self-organise dependency management effectively. This works for small numbers of squads but breaks down as density increases. Providing explicit infrastructure makes coordination manageable at scale whilst preserving squad autonomy for internal operations.
Synthesis: The Model’s Potential Remained Unrealised
Spotify abandoned its model rather than addressing identifiable problems. The company transitioned to traditional management structures, implicitly acknowledging failure. This trajectory suggests the model was fundamentally flawed. A closer examination reveals the opposite: the documented aspirations were reasonable, but implementation choices created predictable dysfunctions that could have been corrected.
The matrix management structure needed adjustment, not elimination. Embedded technical leads reporting to chapter leads would have preserved specialist community building whilst establishing squad-level accountability. The chapter lead system for maintaining technical communities across squads had merit. The mistake was failing to pair it with delivery-focused engineering leadership within squads.
The emphasis on autonomy needed balancing with alignment and accountability, not abandonment. Squads having control over working methods remains valuable when paired with clear strategic context, standardised coordination interfaces, and explicit outcome ownership. The problem wasn’t too much autonomy but autonomy without boundaries or consequences.
The assumption of collaboration competency needed correction through training and programme management, not reverting to command hierarchies. Building Agile capability takes investment but delivers returns through improved decision-making and execution. Spotify could have solved this through comprehensive skill development rather than abandoning the autonomous squad concept.
The custom terminology needed replacement with standard language, not wholesale restructuring. Calling squads “teams” and tribes “departments” would have enabled clearer thinking about organisational patterns without requiring cultural transformation. The naming confused things unnecessarily but the underlying structure had potential.
The absence of dependency management infrastructure needed systematic solutions, not organisational redesign. Programme management roles, standardised coordination protocols, and alignment frameworks could have made multi-squad collaboration routine. These additions enhance rather than replace the squad model.
Spotify’s experience demonstrates that novel organisational patterns require rigorous implementation. The documented model represented aspirational thinking without operational discipline. When reality diverged from aspiration, leadership chose expediency over learning. Rather than diagnosing specific dysfunctions and implementing targeted fixes, the company gradually reverted to familiar patterns.
This represents a missed opportunity. The squad model’s core insights about cross-functional teams, specialist communities, and team autonomy remain valid. The implementation problems were solvable. Had Spotify invested in fixing identifiable issues rather than abandoning the framework, the model might have delivered on its promise. Other organisations attempting similar patterns should learn from these specific failures rather than concluding that autonomous, cross-functional teams cannot work at scale.
The challenge lies in balancing competing needs: autonomy and alignment, specialist development and delivery focus, squad independence and cross-squad coordination. Traditional hierarchies resolve these tensions through control. The squad model attempted resolution through structure and culture. It failed in execution, not in conception. With embedded technical leads, clear accountability, standardised coordination, and proper skill development, the model’s benefits become achievable. The problems Spotify encountered weren’t inherent to the framework. They resulted from incomplete implementation of a partially documented aspiration.
Organisations should extract the genuine insights whilst avoiding the specific mistakes. Cross-functional squads with clear accountability, balanced autonomy with explicit alignment, and specialist communities paired with delivery leadership create effective scaling patterns. These elements require careful implementation with attention to coordination infrastructure and capability development. Spotify proved what doesn’t work. The fixes outlined here describe what should have been attempted. The model’s potential remains to be demonstrated by organisations willing to implement it properly rather than copying surface-level patterns from incomplete documentation.
