The Spotify model - Does copy paste implementation work
summary
Argues that copying Spotify wholesale fails for established companies and works only with startup foundations; prescribes concrete practices used or changed: squad <10 engineers, chapters + guilds + tribes, quarterly Spotify health checks with red/amber/green, monthly product showcases and a 1–5 confidence vote; engineering practices include small frequent releases, feature toggles and release trains, decoupled deployments and limited blast radius; warns about chapter lead role friction, heavy cross-team dependencies, and the need for periodic large-scale alignment events (≈150 people).
AI-written summary · about
chapters (18)
- 0:00Scaling agile frameworks
- 1:05Spotify approach
- 3:12Squads chapters guilds
- 5:21Chapters communities of practice
- 7:30Tribes scaling structures
- 9:33Roles Chief Architect system owner
- 11:39Engineering practices
- 13:43Limited blast radius releases
- 15:26Scaling events alignment
- 17:14Vision alignment in scale
- 19:28Breakout rooms dependency mapping
- 20:52Confidence voting risk ownership
- 21:54Showcases product cohesion
- 23:00Cultural framework
- 24:45Key principles autonomy
- 26:08Health check team metrics
- 27:31Implement Spotify model
- 28:13Q&A
related talks
43mThe #Spotify model - Does copy/past implementation work?
01h 04mYou are not Spotify, and you don’t want to be
27mIs Spotify a good example?
48mAgile at scale at Spotify
46mScaling Agile in your Organization with the Spotify Model
39mOwn your speed
52mHow do we do product at Spotify
50mSpotify, from the Inside
