Why Spotify Squads Are a Popular Failure for Product Teams

Spotify famously developed an engineering culture that garnered a lot of attention; many product teams tried to emulate it, but few succeeded in adopting it. It was all around creating “squads”, and we’re going to take a brief look at what worked and what failed. For the full article head on over to the Chameleon Blog.

Despite Spotify no longer using product squads, the method can bring benefits to other agile product teams. By the end of this summarised article, you’ll have an understanding of the Spotify Squad framework and which pieces may help your product team culture thrive.

A quick history of the Spotify Squad framework

Spotify launched in 2008 with a scrum team framework for their development approach. However, their radical growth highlighted that traditional scrum practices weren’t always the most agile option for Spotify. The team decided to make scrum, its methods, and terminology optional.

What Are Spotify Squads?

• Spotify Squads are cross-functional, self-reliant teams of up to eight people with end-to-end responsibility for ideation, design, testing, deployment, and optimization.
• The core idea behind Spotify Squads was to enable separate teams to build, ship, and iterate often with the main goal to “make mistakes faster than anyone else”.
• Besides squads, there were also tribes (groups of squads), chapters (competency areas throughout squads, within tribes), and guilds (lightweight communities of people with common interests across squads and tribes).

Why did this framework fail? 

• One of the reasons was that Spotify strived for high autonomy, but without a collaboration and guidance process in place, this led to a lot of wasted time and unshared knowledge.
• That said, you can use the learnings from the Spotify Squads framework to implement some elements of it into your own organization. 
• For insights on how other teams did it, watch Nasko Terziev below as he describes his experience from Piktochart, Roger (now Corepay One), and N26, and continue reading for Ben Paton’s experience with a squad-like approach at Atlassian. 
• To apply a similar methodology to your own team, keep in mind that you’d be changing the management style and team structures, so make sure your whole team is on board with the new framework and offer a certain amount of guidance.

Got you thinking? Want the full guide?

Visit the Chameleon Blog to get in the in-depth walkthrough - no email sign-up or download required!