Failed
#SquadGoals
Spotify doesn’t use “the Spotify model”
and neither should you.
By Jeremiah Lee
Sunday, April 19, 2020 • Listen • Watch • En français • 日本語で • Português (Brasil)
Of all the allures of startup culture, few are more desireable 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.1
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.
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–20174
“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 whitepaper3
Recap
You can read and watch the original content in less than 30 minutes or skip to the next section if you are familiar. Here is a brief summary.
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 move between teams within the department to best meet business requirements without them having to change managers.
Matrix management solved the wrong problem
The “full stack” agile team worked well, but the matrix management of software engineers introduced more problems than it solved.
Teams at Spotify were rather long-lived. The benefit of not having to change manager when moving to another team was limited.
Engineering managers in this model had little responsibility beyond the career development of the people they managed. Even then, their ability to help with interpersonal people skills development was limited. An engineering manager would not manage enough of the other people on the team or be involved enough in the daily context to independently assess conflict within the team.
Without a single engineering manager responsible for the engineers on a team, the product manager lacked an equivalent peer—the mini-CTO to their mini-CEO role. There was no single person accountable for the engineering team’s delivery or who could negotiate prioritization of work at an equivalent level of responsibility.
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. A team with backend, Web app, and mobile app engineers would have at least 3 engineering managers who might need to get involved. If those engineering managers could not reach a consensus, a single team’s issue would have to escalate to the department’s engineering director.
“Chapter leads are servant-leaders who help you grow as an individual. They don’t really work with any team. They have direct reports on all the teams. They don’t have really any accountability for the delivery. They aren’t taking that responsibility. It’s easy to see the product owner as the manager for the team.”
—Joakim Sundén, agile coach at Spotify4
Learn from Spotify’s mistakes:
- A product—design—engineering team typically contains more engineers than designers or product managers. Having a single engineering manager for the engineers on the team creates an accountable escalation path for conflict within the team.
- Product managers should have an equivalent peer for engineering. Product managers should be accountable for the prioritization of work. Engineering managers should be accountable for the engineers’ execution, which includes being able to negotiate speed and quality tradeoffs with the product manager.
Spotify fixated on team autonomy
When a company is small, teams have to do a wide range of work to deliver and have to shift initiatives frequently. As a company grows from startup to scale-up, duplicated functions across teams move to new teams dedicated to increasing organization efficiency by reducing duplication. With more teams, the need for a team to shift initiative decreases in frequency. Both of these changes allow for teams to think more deeply and long term about the problems they are scoped to solve. Faster iteration, however, is not guaranteed. Every responsibility a team cedes to increase its focus becomes a new cross-team dependency.
Spotify did not define a common process for cross-team collaboration. Allowing every team to have a unique way of working meant each team needed a unique way of engagement when collaborating. Overall organization productivity suffered.
The Spotify model was documented when Spotify was a much smaller company. It was supposed to be a multiple part series, according to Anders Ivarsson. Autonomy made the first cut, but the parts on alignment and accountability were never completed.
Learn from Spotify’s mistakes:
- Autonomy requires alignment. Company priorities must be defined by leadership. Autonomy does not mean teams get to do whatever they want.
- Processes for cross-team collaboration must be defined. Autonomy does not mean leaving teams to self-organize every problem.
- How success is measured must be defined by leadership so people can effectively negotiate cross-team dependency prioritization.
- Autonomy requires accountability. Product management is accountable for value. The team is accountable for delivering ‘done’ increments. Mature teams can justify their independence with their ability to articulate business value, risk, learning, and the next optimal move.6
“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’. You start with that. You are free to opt out, but people shouldn’t have to opt-in all the time.
“At what point do you start inserting this process? Probably when it’s too late.”
—Joakim Sundén, agile coach at Spotify4
“Henrik Kniberg talked about how we're not that good at large initiatives and we’re still not that good at large initiatives.
“If you have inconsistent ways of working, it’s more difficult for people to move. If it’s more difficult for people to move, it’s more likely you have inconsistent ways of working. It will just reinforce until all of a sudden, you’re not really working for the same company anymore. You’re working for these kind of weird subcultures.”
—Jason Yip, agile coach at Spotify
2015–time of writing5
Collaboration was an assumed competency
While Spotify gave teams control over their way of working, many people did not have a basic understanding of Agile practices. This resulted in teams iterating through process tweaks in blind hope of finding the combination that would help them improve their delivery. 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.
“Agile coaches” were internal consultants Spotify provided teams to teach and suggest process improvements. While well-intentioned, there were not enough coaches to help every team. A coach’s engagement with a team was rarely long enough to span a project’s completion to help a team evaluate performance. More so, they were not accountable for anything.
“Control without competence is chaos.”
—L. David Marquet, Turn the Ship Around!
Learn from Spotify’s mistakes:
- Collaboration is a skill that requires knowledge and practice. Managers should not assume people have an existing comprehension of Agile practices.
- When a company becomes big enough, teams will need dedicated support to guide planning within the team and structure collaboration between teams. Program management can be accountable for the planning process. Dedicated program managers enable teams in a manner similar to how dedicated product managers and engineering managers do with their respective competencies.
Learn from Spotify’s mistakes:
- Most businesses can only sustain a few areas of innovation. Internal process rarely is a primary area of innovation that differentiates a company in the marketplace. Studying the past allows businesses to pick better areas for innovation.
- Optimize for understanding. Every new thing someone must learn in order to be productive in your organization should be evaluated on its value.
- Business units, departments, teams, and managers more effectively communicate organization structure roles and responsibilities than Spotify’s synonyms and are not attached to a way of working that failed their creator.
Do this instead
(Just kidding. There are no quick fixes.)
You might have discovered the Spotify model because you were trying to figure out how to structure your teams. Don’t stop here. Keep researching. Leaders of companies that have withstood longer tests of time have written far more than Spotify blogged. Humans have been trying to figure out how to work together for as long as there have been humans. The industrial age and the information age changed some of the constraints, but academics studying organization theories have found timeless truths about what humans need to be successful in a collective.
Turns out, Spotify in 2012 had not figured out how to maintain the speed and nimbleness of a small team in a large organization. The company evolved beyond its eponymous model and looked outside of itself to find better answers. You should too.
A few of my recommendations related to the topics covered by the Spotify way of working:
- Team Topologies by Matthew Skelton and Manuel Pais
- Essential Scrum by Kenneth S. Rubin
- Shape Up by Basecamp seems like some good ideas for organizations under 150 people.
- I witnessed firsthand how the Scaled Agile Framework helped Fitbit coordinate thousands of people for complex hardware launches. Like any way of working, not every organization has had a successful experience with it.
Notes & Citations
1: Scaling Agile @ Spotify whitepaper, Spotify Engineering Culture video
2: Anders Ivarsson and Henrik Kniberg authored the Scaling Agile @ Spotify whitepaper. Henrik clarified his creator status in 2015: “people sometimes seem to make the assumption that I invented the Spotify model. Well, I most certainly didn’t! I’m just the messenger. … The Spotify model is the result of a lot of people collaborating and experimenting over time, and many aspects of the model were invented without my involvement at all. I certainly wouldn’t want to take credit from the people involved.”
3: Episode 112: Inside Spotify with Anders Ivarsson, The Agile Revolution, 2016
4: You can do better than the Spotify model by Joakim Sundén, 2017 video, slides
5: How things still don’t quite work at Spotify and how we’re trying to solve it by Jason Yip, 2017 video, slides
Additional resources
If 2,200+ words of first-hand experiences from 4 Spotify employees were not enough, read how the Spotify model didn’t work for these people outside of Spotify.
- How to Structure an Engineering Team for Scale by Yotam Hadass
- You want to adopt the “Spotify Model”? I don’t think it means what you think it means! by Willem-Jan Ageling
- Spotify sucks! by Erwin Verweij
- Don’t do the Spotify Model! by Udhesh Vivekanandan
- There Is No Spotify Model for Scaling Agile by Anthony Mersino
❖
Cover illustration inspired by Bad Blood by Taylor Swift, who knows much about squad goals, but not copyright. If you forgot 2015, here is an examination of the term squad goals.
Thank you to Roland Siebelink and Jason Harmon for reviewing drafts of this article.
❖
❖
Support my work by subscribing to Coil. $5/month gets split between the creators you enjoy based on how much time you spend enjoying their works. Privacy built in.
❖
© 2020 Jeremiah Lee. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.
