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 @ 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.
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 is the Spotify Squad framework? #
Spotify Squads are cross-functional, self-reliant teams of eight or fewer people. They have end-to-end responsibility for any product build. This includes:
Each squad has a unique mission, short-term goals, and a few long-term goals—which all contribute towards the greater company mission.
In Spotify’s case, the company 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.
What are Spotify Squads, tribes, and guilds? #
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.
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.
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.
Chapters: Competency areas throughout squads, within Spotify Squad 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 lead 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.
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 are open to 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 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.”
Spotify product development methods #
The autonomous Spotify product squads enabled smooth product release. The product team wanted to release easily and often rather than difficult and seldom. They encouraged ‘manageable’ and frequent releases.
“We aim to make mistakes faster than anyone else.”
Daniel Ek, founder of Spotify
Spotify changed its product’s architecture to enable de-coupled releases. Which meant, 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
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.
Build a prototype or MVP first #
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 goals and effects of this new product update or feature.
Once all of the above is in place, Spotify Squads build prototypes to run user testing with. A fantastic way to incorporate this method into your remote development team is to run fake door tests with Chameleon.
How to run a Chameleon fake door test for user feedback
Upload a mockup image within your product—a low-fidelity prototype.
When that mockup is triggered via a click or hovered over, launch an in-app Microsurvey.
Explain to the user this is a WIP. Ask them if they’d be interested in trialing the new feature and provide feedback.
You can also ask users what they would like, want, or expect to see from the new feature after seeing the mockup.
Gather your feedback and make data-driven decisions on the product build.
Next, Spotify (and you can) build a minimum viable product (MVP.) 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.
🎬 On-demand webinar: Validating Product Roadmaps With Your UsersLearn how to validate new product ideas and solutions with user feedback in this webinar with Maze
Test impact and analyze the data #
Next up, the MVP is released to a small percentage of users. The squad runs A/B tests and other user testing methods to help with decision-making for optimization tweaks.
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:
Solve the issues and scale #
The responsible release squad will then continue to tweak and release the product to the same user testing group until they’re happy with their work and can begin rolling out to Spotify’s entire user base.
Impact > Velocity
It’s ready. Release it to the masses! #
Of course, it doesn’t stop there. There’s a constant feedback loop and continued testing for the new feature or product.
Learning from the Spotify Squads failure #
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
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
The lack of engineering managers hindered communication with PMs #
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 @ 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.
Cross-team collaboration and autonomy are hard to balance #
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 to 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.
Collaboration requires skill and practice #
Sure, Spotify hired smart people; product leaders, engineers, 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 @ Spotify
Cool-sounding names can create additional obstacles #
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 @ Spotify
How to implement Spotify Squads that work for you #
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.
This isn't a magic bullet and won’t work in every team. It won’t fix toxicity (it might make it worse). You must also consider how “everyday work” is going to get done too.
Choose organizational elements that work for your team #
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.
I implemented a squads-like approach, where we divided teams into functional areas that comprised engineers across all 3 codebases. We allocated PMs to these squads and tasked them with devising their own roadmaps. The goal was to empower teams to be self-sufficient and avoid the dependence that existed previously.
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:
Experiment with a limited blast radius #
Don’t be afraid to experiment and try new management styles and team structures to build great projects. 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.
You can also learn from Spotify’s decoupled releasing method here and trial 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.
What we can learn from the squad framework business 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 reasonable time frames—then innovation is nothing but a distraction.
Think about the culture you’re building or changing #
Whether you decide the Spotify organizational model is a fit for your team, borrow elements from it, or disregard it altogether, at least now you know what it is and the potential for product-led growth.
It’s important to remember that you’re introducing or completely changing your company culture. Don’t overwhelm employees in the process. Find solutions that make sense for you, and if you’re not reinventing the wheel, then stick to a naming structure that people already recognize.
Team buy-in is important. Everyone should have a say in which squad they are in. A happy squad is a productive squad. Squads must have solid strategic goals to direct them. Although the Spotify model suggests allowing teams to choose their own tooling and method, consistency across squads is important.
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 onboarding flows, and in-office print reminders if you’ve got the luxury to do so.
Done right, certain criteria of the squad framework and Spotify methods could give your product scrum team an edge to pit you against the competition. Done wrong, and you could be the talk of Westeros for quite a while.
Pick your battles, grab a dragon or two, and build a product team to conquer the lot.