But you don’t have to take my word for it.
The co-author of the Spotify model2 and multiple agile coaches who worked at Spotify have been telling people to not copy it for years. Unfortunately, truth doesn’t spread as quickly or as widely as an idea people want to believe in.
“Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.” Joakim Sundén, agile coach at Spotify 2011–2017
“It worries me when people look at what we do and think it’s a framework they can just copy and implement. … We are really trying hard now to emphasize we have problems as well. It’s not all ‘shiny and everything works well and all our squads are super amazing’.” Anders Ivarsson, co-author of the 'Spotify Whitepaper'
Of all the allures of startup culture, few are more desirable than the speed and nimbleness of a small team. Maintaining that feeling as a company grows is a challenge. In 2012, Spotify shared its way of working and suggested it had figured it out.
I was excited to see the Spotify model in action when I interviewed for a product management role at its Stockholm headquarters in 2017. However, the recruiter surprised me before the first interview. She cautioned me to not expect Spotify to be an Agile utopia.
I joined the company after it had tripled in size to 3,000 people over 18 months. I learned the famed squad model was only ever aspirational and never fully implemented. I witnessed organizational chaos as the company’s leaders incrementally transitioned to more traditional management structures.
When I asked my coworkers why the content was not removed or updated to reflect reality, I never got a good answer. Many people ironically thought the posts were great for recruiting. I no longer work at Spotify, so I am sharing my experience to set the record straight. The Spotify squad model failed Spotify and it will fail your company too.
Spotify had teams it called squads because it sounded cooler (not joking). A group of teams were organized into a department called a tribe. Each team was intended to be an autonomous mini-startup, with a product manager acting as mini-CEO for a feature area. The teams had designers and software engineers with a range of specializations. The intent was that a team should have every skill necessary without needing to rely on another team for success.
Product managers had a traditional management structure. A product manager for a team reported to their department’s product director (“tribe lead”). Same for designers. Software engineers, however, were managed outside of the team structure.
“Chapter leads” managed software engineers specializing in a specific type of software development across the department. For example, all of the software engineers working on backend APIs across all the teams within the department would have one manager and all of the Android mobile engineers in the department would have a different manager. The intent was to allow engineers to be moved between teams within the department to best meet business requirements without them having to change managers.