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 dissect what worked and what failed, with help from Nasko Terziev, Founder of Nasko's Growth Design Studio, and Ben Paton, Senior Product Manager at Atlassian.

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

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.

Spotify Squads are cross-functional, self-reliant teams of eight or fewer people. They have end-to-end responsibility for any product built.

This includes: 

• Ideation

• Design

• Testing

• Deployment

• Optimization

Each squad has a unique mission, short-term goals, and a few long-term goals—which all contribute to the greater company mission. In Spotify’s case, the company's mission is: to unlock the potential of human creativity.

Engineering squads make local decisions, which means they have the autonomy to move projects forward or get them started without needing to rely on approvals from up top. 

Spotify built squads out of trust—relying on hiring smart people to make smart decisions and with a goal of building an autonomous workforce.  

Here's Nasko Terziev, Founder of Nasko's Growth Design Studio, with his experience on how he's worked in a Spotify Squad lineup:

Spotify took engineering culture to new heights—and new names. There are a few terms you need to understand to process the whole product team structure. 

Spotify squads

Squads: Mission-driven groups of eight or fewer product people. A product ecosystem can have any number of squads, as long as they align on the greater product mission. 

The Spotify model squads collaborate to find solutions. Specific squads will own specific systems or processes—they aim to enable each other to use those systems or processes so other squads can achieve their mission. 

Squads tend to focus on product delivery and quality.

Spotify tribes

Tribes: Groups of squads. Tribes can include any number of squads and usually combines them for a purpose. This can be a location, an area of the product, a holistic overview of a problem, or more.  

Spotify chapters

Chapters: Competency areas throughout squads, within tribes. 

For example, four squads may have one person within each that specializes in app development. These four people will make up one chapter across the four squads. 

Each chapter has a leader who acts as a formal line manager. This structure enables people to jump from one squad to the next and work on different initiatives without losing their manager and leader. 

Spotify guilds

Guilds: A lightweight community of people with common interests across squads and tribes. 

Guilds can have multiple people from the same squad. They are essential for building culture and employee engagement beyond their roles. 

People can come and go as they please and guilds can be around professional development areas like Python or Google Analytics. Or, they can focus on personal interests, like a book club, yoga, or Game of Thrones. 

Spotify stressed community over hierarchy and believed that a strong enough community can make the right decisions without needing approval from high alignment-focussed leaders. 

Spotify also believed that by building an autonomous community via squads, tribes, chapters, and guilds, they were building a product team that simply had the potential to “create better stuff”. 

The autonomous Spotify product squads enabled smooth product releases. The product team wanted to ship easily and often, so they encouraged ‘manageable’ and frequent releases. 

“We aim to make mistakes faster than anyone else.”

Daniel Ek, Founder of Spotify

Spotify also changed its product’s architecture to enable de-coupled releases. This meant that certain squads were responsible for certain features or specific areas of the app, rather than all squads being responsible for the entire app. 

Squads were broken down into three core areas: 

• Client feature squads 

• Infrastructure squads

• Client app squads 

De-coupled releases make for a ‘limited blast radius’, meaning if a product deployment fails, it is limited to its immediate radius and doesn’t fail the entire product. 

Source

Think it. Built it. Ship it. Tweak it. 

Spotify Squads’ approach to product development was based on Lean startup principles. They identify a problem using research, define a narrative to summarize the solution, and build a hypothesis (or multiple) on the effects of this new product update or feature. 

Once all of the above is in place, squads build prototypes to run user testing with.

One of the ways to incorporate this method into your development team is to run fake door tests and gather relevant, contextual feedback from your users. You can do this with a tool like Chameleon, and here's how to do it.  

How to run a Chameleon fake door test for user feedback

1. Upload a mockup image within your product—it can be a prototype for testing 

2. When that mockup is triggered via a click or a hover, launch an in-app Microsurvey

3. Explain to the user this is a work-in-progress, and ask them if they’d be interested in trialing the new feature to provide feedback  

4. You can also ask users what they would like, want, or expect to see from the new feature after seeing the mockup

5. Gather your feedback and make data-driven decisions on the next product/feature update

Next, Spotify would build a minimum viable product (MVP), and you can do it too. Spotify also called this the minimum lovable product (MLP)—very cute. 

This initial product is enough to fulfill the narrative we mentioned above but is far from perfect. Once again, don't forget to validate your MVP with your users and put it into your product roadmap for further iteration.   

Next up, the MVP is released to a small percentage of users. The squad then runs A/B tests and other user testing methods to help with decision-making for optimization tweaks. 

For this purpose, you can also use Chameleon to check the pulse on user sentiment.

How to use Chameleon to analyze UX and UI

It’s the perfect moment to try out customer feedback surveys to gain some qualitative data on your new product. If you use Chameleon analytics for in-app quantitative assessments, you also have a wealth of integrations at your fingertips, including integrations with Mixpanel, Amplitude, FullStory, Heap, and other tools. This will enable your data to flow in both directions for deeper insights.

👉 Check out how to build a multi-button Microsurvey with Chameleon.

With the right data and insights at hand, the responsible release squad would then continue to tweak and re-release the product to the same user testing group until they're sure that it solves all of the relevant users' problems and pain points.

When everything is tested and backed by data and user feedback, the squad would begin rolling it out to Spotify’s entire user base. 

Of course, it doesn’t stop there. There’s a constant feedback loop and continued testing for new features or products the team is working on. 

The above seems like a collection of agile product development rainbows and daisies. However, that wasn’t always the case.

The Spotify Squads framework has received quite a bit of criticism over the years, a lot of which was from ex-employees.

It’s been criticized for: 

• Never truly existing

• Solving the wrong problems

• Being too autonomous 

• Assuming emotional intelligence competencies of people

• Displacing output accountability

Source

Today, Spotify no longer uses—or aspires to use—this seemingly glorious framework. Which begs the question: Why? 

“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

A big learning from the Spotify Squads framework is that some level of hierarchy is needed—managers exist for a reason. The framework saw product owners manage design and engineering teams without engineering managers—or at least in short supply. 

“When disagreements within the engineering team arose, the product manager needed to negotiate with all of the engineers on the team. If the engineers could not reach a consensus, the product manager needed to escalate to as many engineering managers as there were engineering specializations within the team.”

Jeremiah Lee, former Product Manager at Spotify 

Sure, they had chapter leads; however, these roles held little to no responsibility for work deliverables; instead, they were accountable for someone’s career growth and professional skill development. 

This left product managers communicating with hoards of engineers rather than one leader for the engineers or a DevOps engineer, resulting in wasted time, a lot of back and forth, and perhaps a little too much autonomy.

Spotify strived for high autonomy and high alignment. 

For example, business leaders present problems, explain why they are problems, and ask squads to find, build and release solutions. However, many of these problems required cross-squad collaboration. 

This was not always an option as other squads that owned much-needed processes or tools did not have the bandwidth to collaborate. 

“If I were to do one thing differently, I would say we should not be focusing so much on autonomy. “Every time you have a new team, they have to reinvent the wheel in how they should be working. Maybe, just maybe, we should have a ‘minimum viable agility’.”

Joakim Sundén, Agile Coach at Spotify 2011–2017

This led to squads figuring out tools for their solutions for themselves, and despite the peer review code process in place, there was a lot of time wasted and unshared knowledge—not so agile as they had hoped.  

Sure, Spotify hired smart people; product leaders, engineers, and data heads. They aim to be an agile company with a growth mindset, agile principles, and people to match. 

However, smart people are not necessarily skilled people. The Spotify engineering squads framework required certain skill sets that talent doesn’t always come with, collaboration being one of them. 

“People lacked a common language to effectively discuss the process problems, the education to solve them, and the experience to evaluate performance. It was not really agile. It was just not waterfall.”

Jeremiah Lee, former Product Manager at Spotify 

Lastly, as much as it pains us to say this, cool-sounding names don’t always lead to cool solutions. 

If your naming structure is not written centrically for your employees, then it can be hard for people to grasp what’s what. You’re teaching a new language, as well as a new framework; it’s a lot to ask.

Squads, guilds, chapters, tribes, it sounds more like the plot to Game of Thrones rather than a product culture set up, and the workplace economy suffered because of it.

“Had Spotify referred to these ideas by their original names, perhaps it could have evaluated them more fairly when they failed instead of having to confront changing its cultural identity simply to find internal processes that worked well.”

Jeremiah Lee, former Product Manager at Spotify 

Despite the Spotify Squads framework having as many plot twists as Game of Thrones, there’s a lot that product teams can learn and borrow from the now disowned framework. 

The entire engineering squad structure may not work exactly for your product culture; however, there may be elements of the organizational structure that can influence your work style, how you hire new people, and how you manage the team.

Perhaps on the autonomy to alignment scale, you need to steer a little closer to alignment than Spotify did. Perhaps, chapter leaders may not be what you’re looking for, but squad leaders are? 

Find areas that resonate and your team can benefit from; it doesn’t need to be the whole thing, as Nasko Terziev told us:

At the heart of squads, Spotify was striving for innovation above anything else in their product strategy, which isn’t a bad thing to do. 

What we can all learn from this model is that innovation needs a certain amount of guidance and cultivation in order to be successful. Sure we are innovative by nature, but if we are not innovative together and within a reasonable timeframe, then innovation is nothing but a distraction. 

We can also learn from Spotify’s decoupled releasing method. Don’t be afraid to experiment and try new management styles to build great projects. You could try new frameworks with small teams, gathering feedback before releasing it company-wide. Think: limited blast radius. 

For example, maybe a squad focused on product-led growth could work for you. It’s a cross-functional area and can help your business think holistically about driving growth. 

Whether you decide the Spotify organizational model is a fit for your team or you only want to borrow elements from it, it’s important to remember that you’d be introducing new styles or completely changing your company culture.

Don’t overwhelm employees in the process. Find solutions that make sense for your company, make sure everyone is on the same page, and stick to a naming structure that people already recognize.

Lastly, don’t expect everyone to onboard your new culture overnight. It takes practice and persistence on all parts for a culture to fully thrive. So give it time, introduce it via a collection of internal comms like workshops, webinars, Slack chats, email flows, and in-office print reminders if you’ve got the luxury to do so. 

As we mentioned above, Spotify strived for high autonomy with the squads, but without a collaboration process in place, this led to a lot of wasted time and unshared knowledge.

Takeaway: Some level of the hierarchy is needed—managers exist for a reason. 

You can use the learnings from the Spotify Squads framework 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.

Done right, certain criteria of this framework could give your product team an edge to pit you against the competition. Done wrong, and you could be the talk of Westeros for quite a while. So pick your battles, grab a dragon or two, and build a product team to conquer the lot.

Don’t be afraid to experiment—create a culture where prototype testing and continuous user feedback are pillars of growth, and you’ll be able to innovate and succeed faster.