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.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.
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.
Spotify tried a long-lived matrix team structure with unusual word choices.1 It did not work well.
Why it didn’t work
- Matrix management solved the wrong problem
- It fixated on team autonomy
- Collaboration was an assumed competency
- Mythology became difficult to change.
1. 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 three 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.
2. 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
3. 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 to 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.
4. Mythology is difficult to change
When Agile Scrum introduced new meanings to a bunch of words like burn-down and sprint, it did so because it introduced new concepts that needed names. Spotify introduced the vocabulary of missions, tribes, squads, guilds, and chapter leads for describing its way of working. It gave the illusion it had created something worthy of needing to learn unusual word choices. However, if we remove the unnecessary synonyms from the ideas, the Spotify model is revealed as a collection of cross-functional teams with too much autonomy and a poor management structure. Don’t fall for 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.
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.
Notes & Citations
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.”
If 2,200+ words of first-hand experiences from four Spotify employees were not enough, read how the Spotify model didn’t work for these people outside of Spotify:
- You want to adopt the “Spotify Model”? I don’t think it means what you think it means! by Willem-Jan Ageling.
Editor’s note: See also Shayne’s world: How Shayne Elliott’s ‘agile’ ANZ got stuck.