In 2012, Spotify released a video about their engineering culture.
It showed autonomous “squads,” aligned into “tribes,” supported by “chapters” and “guilds.”
It looked amazing. Teams working independently. No bureaucracy. Innovation everywhere.
The video went viral.
Suddenly, every company wanted squads and tribes. Management consultants sold “Spotify Model transformations.” Books were written. Certifications created.
There was just one problem:
Spotify doesn’t use the Spotify Model anymore.
The model that everyone copied was a snapshot of one moment in Spotify’s history. A work in progress. An experiment.
And Spotify moved on.
But here’s the thing: The model still has valuable ideas. You just need to understand what actually works and what doesn’t.
Let’s break it down.
The Spotify Model: What It Was Supposed to Be
The model was designed to solve one problem: How do you scale agile beyond a few teams?
The Structure
1. Squads (The Team)
- Size: 6-12 people
- Structure: Cross-functional (designers, engineers, product manager)
- Mission: Own a specific feature area end-to-end
- Autonomy: Decide how to work, what to build, how to deploy
- Metaphor: “Like a mini-startup”
Example:
- Squad: Search
- Mission: Make Spotify search amazing
- Members: 2 backend engineers, 2 frontend engineers, 1 data scientist, 1 designer, 1 PM
- Owns: Search infrastructure, UI, ranking algorithm, metrics
2. Tribes (The Organization)
- Size: 40-150 people (multiple squads)
- Structure: Collection of squads working in related areas
- Mission: Strategic area of the product
- Leadership: Tribe lead (coordinates, doesn’t command)
Example:
- Tribe: Discovery
- Squads: Search, Recommendations, Browse, Radio
- Mission: Help users find music they’ll love
3. Chapters (The Discipline)
- Cross-squad grouping of people with similar skills
- Reports to a chapter lead (line manager)
- Meet regularly to share knowledge
Example:
- Chapter: Backend Engineers
- Members: All backend engineers across squads in a tribe
- Purpose: Share best practices, grow skills, align on standards
4. Guilds (The Community)
- Company-wide interest groups
- Optional membership
- Share knowledge across tribes
Example:
- Guild: Web Technology
- Members: Anyone interested in web tech, across all tribes
- Activities: Meetups, Slack channel, tech talks
The Theory: Why This Should Work
The model addressed real problems with traditional structures:
Problem 1: Conway’s Law
“Organizations design systems that mirror their communication structure.”
Traditional org:
- Backend team, Frontend team, Design team
- Result: Backend and frontend don’t talk
- Product: Disconnected experience
Squad model:
- Backend, frontend, design in same squad
- Result: Constant communication
- Product: Cohesive experience
Problem 2: Functional Silos
In traditional structures:
- Engineers report to engineering manager
- Can’t make decisions without manager approval
- Everything requires coordination
Squad model:
- Squad has authority to make decisions
- No asking permission from other teams
- Move fast
Problem 3: Scaling Agile
Agile works for 1 team. How do you scale to 100 teams?
Squad model’s answer:
- Each squad is independently agile
- Tribes provide loose coordination
- Chapters share learnings
Problem 4: Career Growth vs. Product Focus
Engineers want to:
- Grow their technical skills (need mentorship)
- Ship products (need focus)
Traditional orgs force a choice:
- Join engineering org: Good mentorship, disconnected from product
- Join product team: Product focus, no technical growth
Squad model solves this:
- Work in squad: Product focus
- Belong to chapter: Technical mentorship
The Reality: Why It Didn’t Work (As Advertised)
In 2020, Spotify’s engineering leaders admitted: The model in the video was aspirational, not descriptive.
Here’s what broke:
Problem 1: Autonomy Without Alignment = Chaos
The promise: Squads are autonomous. They decide what to build.
The reality:
- Squad A builds feature X their way
- Squad B builds similar feature Y a different way
- Now you have 2 different solutions to the same problem
- Technical debt explodes
Example:
The “Recommendations” squad and “Radio” squad both needed a way to rank songs. Each built their own system.
Result:
- Different algorithms
- Different infrastructure
- Can’t share improvements
- Users get inconsistent experience
What went wrong:
Autonomy without strategic alignment creates silos.
Problem 2: Matrix Management Confusion
You report to:
- Squad (for product work)
- Chapter lead (for career/skills)
- Tribe lead (for strategic direction)
The promise: Dual reporting gives you best of both worlds.
The reality:
- Who do you prioritize?
- Squad lead wants feature shipped
- Chapter lead wants you to refactor tech debt
- You’re pulled in multiple directions
Classic matrix management problem: When everyone is responsible, no one is.
Problem 3: Chapters Didn’t Scale
The promise: Chapters give you technical community and mentorship.
The reality:
- Chapter meetings become status updates
- Too many people to have meaningful technical discussions
- Chapter lead can’t effectively mentor 15+ people
- Engineers feel disconnected from technical leadership
Problem 4: Guilds Were Ignored
The promise: Guilds spread knowledge across the company.
The reality:
- Voluntary = people skip them
- Too broad to be useful
- No teeth (can’t enforce standards)
- Became social clubs, not technical governance
Problem 5: Squad Boundaries Were Political
The question: How do you split work into squads?
The problem:
- Some squads own critical infrastructure (high status)
- Some squads own “boring” work (low status)
- Engineers want to join high-status squads
- Reorgs become political battles
Example:
Everyone wants to be on the “Personalization” squad (ML, cutting-edge tech).
No one wants to be on the “Billing” squad (compliance, legacy code).
Result: Some squads are oversubscribed, others understaffed.
Problem 6: Dependencies Still Existed
The promise: Squads are independent. They ship without waiting.
The reality:
- You need data from another squad’s API
- You need platform team to deploy infrastructure
- You need design system team to approve UI changes
- You’re not actually autonomous
Autonomy was a myth.
What Actually Works (The Useful Parts)
Despite the hype, some ideas from the Spotify Model ARE valuable:
1. Cross-Functional Teams
This works:
Having designers, engineers, and product managers on the same team eliminates handoffs.
How to apply:
- Build product teams, not functional teams
- Colocate everyone working on the same goal
- Measure outcomes, not output
2. Team Ownership
This works:
Teams that own their code long-term write better code.
How to apply:
- You build it, you run it
- Team owns on-call
- No “throwing over the wall” to ops
3. Small, Mission-Focused Teams
This works:
6-12 people can move fast. 50 people can’t.
How to apply:
- Keep teams small
- Give them clear mission
- Minimize dependencies
4. Lightweight Alignment Mechanisms
This works (with caveats):
You need SOME coordination without heavy bureaucracy.
How to apply:
- Regular cross-team demos
- Shared architectural principles
- Lightweight RFCs for big changes
The Lessons for Your Company
Don’t copy Spotify. Learn from their experiments.
Lesson 1: Autonomy Requires Alignment
Don’t do: “Teams can do whatever they want!”
Do: “Teams have autonomy within strategic guardrails.”
Example:
- Autonomy: Choose your database
- Guardrail: Must be on approved list (Postgres, MySQL, DynamoDB)
- Why: Security, operational expertise, cost management
Lesson 2: Matrix Management Is Hard
Don’t do: Dual reporting structures without clear decision-making authority.
Do: Clear line management + dotted line coordination.
Example:
- You report to Engineering Manager (solid line)
- You coordinate with Product Manager (dotted line)
- When there’s conflict, EM is tiebreaker
Lesson 3: Naming Doesn’t Matter
Don’t do: Rename teams to “squads” and call it transformation.
Do: Focus on autonomy, ownership, and alignment regardless of names.
Lesson 4: No Model Survives First Contact
Spotify’s model was a snapshot. It evolved.
Your model should evolve too:
- Start simple
- Experiment
- Adapt
- Don’t treat any model as gospel
Lesson 5: Dependencies Are the Real Enemy
The goal isn’t squads. The goal is reducing dependencies.
Focus on:
- Service boundaries
- Clear APIs
- Platform abstractions
- Async communication
Not:
- Org chart shapes
- Team names
- Matrix structures
What to Do Instead
Forget “Squads and Tribes.” Ask better questions:
Question 1: How do we minimize dependencies?
Not: How do we make autonomous teams?
But: How do we architect systems so teams CAN be autonomous?
Answer:
- Microservices (done right)
- Platform teams
- Clear interfaces
- Build vs. buy decisions
Question 2: How do we align without controlling?
Not: Should teams have autonomy?
But: How do we align on strategy while giving teams tactical freedom?
Answer:
- OKRs
- Architectural principles
- RFCs for big decisions
- Lightweight approval processes
Question 3: How do we enable career growth?
Not: Should we have chapters?
But: How do we ensure engineers grow while staying focused on product?
Answer:
- Strong engineering managers
- Tech lead career paths
- Brown bags and guilds (optional, not required)
- Cross-team projects
The Modern Spotify (What They Actually Do Now)
Spotify evolved beyond the model:
1. Reduced Matrix Complexity
- Clearer reporting lines
- Less emphasis on chapters
- More focus on squads + engineering management
2. Platform Teams
- Dedicated platform teams provide infrastructure
- Product teams focus on features
- Clear service boundaries
3. Stronger Architecture
- Invested in backend-for-frontend (BFF) pattern
- Clear service ownership
- Reduced dependencies
4. Product-Led, Not Model-Led
- Focus on shipping product
- Less focus on organizational structure
- Pragmatic over dogmatic
Spotify learned: It’s not about the org chart. It’s about outcomes.
Key Takeaways
- The Spotify Model was an experiment, not a prescription
- Autonomy without alignment creates chaos
- Matrix management is harder than it looks
- Cross-functional teams ARE valuable
- Focus on reducing dependencies, not org chart shapes
- No model is perfect—adapt to your context
- Spotify doesn’t use “the Spotify Model” anymore
Everyone is curious about Spotify’s model because it looks simple.
Squads! Tribes! Chapters! Guilds! It’s tidy. It’s a diagram.
But organizational design is messy.
The model that works for Spotify at 2,000 people won’t work for you at 50 people.
The model that worked for Spotify in 2012 didn’t work for Spotify in 2020.
Copying the diagram misses the point.
The point is:
- Build cross-functional teams
- Minimize dependencies
- Align on outcomes
- Give teams ownership
- Evolve as you grow
Do that, and you don’t need squads and tribes.
You just need teams that ship.