Spotify's #SquadGoals Model Failed

2020 May 18

Article by Jeremiah Lee, with translation and adaptation by Flávio Clésio.

…

Cover

If Spotify doesn’t use “the Spotify model,” you shouldn’t either.

…

Of all the fascinations of startup culture, few are more desired than the speed and agility 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 discovered a way to maintain that speed and agility. 1

I was excited to see the Spotify model in action when I interviewed for a Product Manager role in 2017 at its headquarters in Stockholm. However, the recruiter surprised me before the first interview. She warned me not to expect Spotify to be an agile utopia.

I joined the company shortly after it tripled in size, growing to 3,000 people in 18 months. I learned that the famous squad model was only aspirational and was never fully implemented. I witnessed organizational chaos as the company’s leaders gradually transitioned to more traditional management structures.

When I asked my colleagues why the content hadn’t been removed or updated to reflect reality, I never got a good answer. Many people ironically thought the posts were great for recruitment.

I no longer work at Spotify, so I’m sharing my experience to set the record straight. The Spotify squad model failed at Spotify itself, and it will fail at your company too.

You don’t have to believe me…

The co-author of the Spotify Model 2 and several agile coaches who worked at Spotify have been telling people for years not to copy this model. Unfortunately, the truth doesn’t spread as fast or as widely as an idea people want to believe in.

“Even at the time we wrote it, we weren’t doing it [using the squad model]. It was part ambition, part approximation. People have really struggled to copy something that didn’t actually exist.”

— Joakim Sundén, Agile Coach at Spotify 2011-2017 4

“It worries me when people look at what we do and think it’s a structure they can just copy and implement. … We are really trying to emphasize that we have problems too. It’s not like everything is ‘shiny, everything works well and all our squads are super amazing’.”

— Anders Ivarsson, co-author of the Spotify whitepaper 3

**Recapping what the squad model is**

You can read and watch the original content in less than 30 minutes, or skip to the next section if you’re already familiar with this squad model. Here is a brief summary.

Spotify had teams called squads because it sounded cooler (no joke).

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 a mini-CEO for each feature (these features within Spotify are, for example, Discover Weekly, Daily Mix, algorithmically created lists, etc.).

Teams had designers and software engineers with a wide range of specializations. The intention was for a team to have all the skills necessary for feature development without having to rely on another team for the success of that implementation.

The Product Managers had a traditional management structure. A Product Manager of a team reported to the product director of their department (the “tribe leader”). The same for designers. Software engineers, however, were managed outside the team structure.

“Chapter Leads” managed software engineers specialized in a specific type of software development within the department.

For example, all software engineers working with backend APIs across all teams would have one manager, and all engineers working with Android mobile within the same department would have a different manager.

The intention was to allow engineers to be moved between teams within a department to better meet business needs without them having to change managers.

Spotify tried a matrix organization with unusual word choices. 1 It didn’t work well.

Why didn’t it work?

The matrix organization solved the wrong problem
Spotify became fixated on team autonomy
Collaboration was an assumed competency
It became difficult to change the mythology of the squad model

The matrix organization solved the wrong problem

The full-stack agile team worked well, but the matrix organization of software engineers introduced more problems than it solved.
Spotify teams were quite long-lived. The benefit of not having to change managers 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 develop people’s interpersonal skills was limited. An engineering manager would not manage the other people on the team enough or be involved enough in the daily context to evaluate and manage conflicts within the team.
Without a single engineering manager responsible for a team’s engineers, the Product Manager didn’t have an equivalent peer — the mini-CTO to their mini-CEO role. There was no single person responsible for the engineering team’s delivery or who could negotiate work prioritization at an equivalent level of responsibility.
When disagreements arose within the engineering team, the Product Manager needed to negotiate with all the software engineers on the team.

If the developers couldn’t reach a consensus, the Product Manager needed to escalate to as many engineering managers as necessary within the engineering specializations on the team to resolve the conflict.

For a team with backend, web app, and mobile engineers, the Product Manager would have to try to resolve disagreements with at least 3 engineering managers. If those engineering managers didn’t reach a consensus, the team’s issue would have to be escalated to the department’s engineering director.

“Chapter Leads are servant-leaders who help you grow as an individual. They don’t work with any team. They have direct reports across all teams. They have no responsibility for delivery. They aren’t taking that responsibility. It’s easy to see the Product Owner as the team manager.”

— Joakim Sundén, Agile Coach at Spotify 4

Learn from Spotify’s mistakes:

A “product-design-engineering” team typically has more engineers than designers or product managers. Having a single engineering manager for the team’s engineers creates a responsible path for escalation and conflict resolution within the team.
Product managers should have an equivalent peer in the engineering team. Product managers should be responsible for work prioritization. Engineering managers should be responsible for the engineers’ execution, which includes being able to negotiate tradeoffs between speed and quality with the Product Manager.

Spotify became fixated on team autonomy

When a company is small, teams have to do a wide range of work to deliver, and they have to change initiatives frequently. As a company grows from a startup to a scale-up, duplicate functions between teams move to new dedicated teams to increase organizational efficiency and reduce duplication.

With more teams, the need for a team to change initiatives decreases in frequency. Both changes allow teams to think more deeply and long-term about the problems they are scoped to solve. However, this is not a guarantee of faster iteration. Every responsibility a team gives up to increase its focus becomes a new dependency on other teams (cross-team dependency).

Spotify did not define a common process for collaboration between teams. Allowing each team to have a unique way of working meant that each team needed a unique way of engagement regarding collaboration. The overall productivity of the organization suffered.

The Spotify model was documented when Spotify was a much smaller company. It was supposed to be a multi-part series, according to Anders Ivarsson. Autonomy was the first part, but the alignment and accountability parts were never completed.

Learn from Spotify’s mistakes:

Autonomy requires alignment. Company priorities must be defined by leadership. Autonomy does not mean teams can do whatever they want.
Collaboration processes between teams must be defined. Autonomy does not mean letting teams self-organize for all problems.
How success is measured must be defined by leadership so that people can effectively negotiate the prioritization of tasks that have dependencies between multiple teams.
Autonomy requires accountability. Product Management is responsible for delivering value. The team is responsible for delivering ‘done’ increments. Mature teams can justify their independence depending on their ability to articulate business value, risk, learning, and what the ideal next move for the team should be. 6

“If I were to do one thing differently, I would say we shouldn’t have focused so much on autonomy.”

“Every time you have a new team, they have to reinvent the wheel on how they should be working. Maybe, just maybe, we should have a ‘minimum viable agility.’ You can 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 that process? Probably when it’s too late.”

— Joakim Sundén, Agile Coach at Spotify 4

“Henrik Kniberg talked about how we’re not that good at big initiatives and we’re still not that good at big initiatives.”

“If you have inconsistent ways of working, it’s harder for people to move. If it’s harder for people to move, you’re more likely to have inconsistent ways of working. It will reinforce until suddenly you’re not working for the same company anymore. You’re working for these kinds of weird subcultures.”

— Jason Yip, Agile Coach at Spotify from 2015 to present 5

Collaboration was an assumed competency

Although 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 adjustments in the blind hope of finding a combination that would help them improve their delivery.

People lacked a common language to effectively discuss process issues, the education to solve them, and the experience to evaluate performance. It wasn’t truly agile. It was just non-waterfall.

“Agile Coaches” were internal consultants that Spotify provided to teach agile practices and suggest process improvements. Although well-intentioned, there were not enough Agile Coaches to help all teams. An Agile Coach’s engagement with a team was rarely enough to cover the completion of a project to help a team evaluate performance. Furthermore, they weren’t responsible 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 that people have an existing understanding of agile practices.
When a company becomes large enough, teams will need dedicated support to guide within-team planning and the cross-team collaboration structure. The program management team can be responsible for the planning process. Dedicated Program Managers enable teams in a similar way to how product managers and engineering managers do with their respective competencies.

It became difficult to change the mythology of the squad model

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 missions, tribes, squads, guilds, and Chapter Leads into the vocabulary to describe its way of working.

This gave the illusion that Spotify had created something worthy of needing to learn through unusual word choices. However, if we remove the unnecessary synonyms from the ideas, the Spotify model reveals itself as a collection of cross-functional teams with a lot of autonomy and a poor management structure.

Don’t fall for it.

If Spotify had referred to these ideas using their original names, perhaps it could have evaluated the failure of its model more fairly, instead of simply having to face the change of its cultural identity to find internal processes that worked well.

Learn from Spotify’s mistakes:

Most companies can only sustain a few areas of innovation. Internal processes are rarely a primary area of innovation that differentiates a company in the market. Studying the past allows companies to choose better areas for innovation.
Optimize for understanding. Every new thing someone must learn to be productive should be evaluated for its value.
Terminologies like business units, departments, teams, and managers more effectively communicate roles and responsibilities within an organizational structure than Spotify’s synonyms, synonyms which failed their creator.

Instead of following this model, do this

(Just kidding. There are no quick fixes.)

You may 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 stood longer tests of time have written much more than Spotify has blogged.

Humans have been trying to figure out how to work together since humanity has existed. The industrial age and the information age have changed some of the constraints for this, but academics who study organizational theories have found timeless truths about what humans need to be successful within a collective.

It turns out that Spotify in 2012 hadn’t discovered how to maintain the speed and agility of a small team in a large organization. The company evolved beyond its namesake model and looked outside itself to find better answers. And you should do the same.

Some of my recommendations related to the topics covered by the Spotify model’s way of working:

More than 200 people in your product-engineering-design organization? The Scaled Agile Framework worked well for Fitbit when I worked there.
Fewer than 200 people? Shape Up by Basecamp is how I intend to structure my next startup.
Essential Scrum by Kenneth S. Rubin
Team Topologies by Matthew Skelton and Manuel Pais

Notes and Citations

1: Scaling Agile @ Spotify whitepaper, Spotify Engineering Culture

2: Anders Ivarsson and Henrik Kniberg were the authors of the Scaling Agile @ Spotify whitepaper. Henrik clarified his status as creator in 2015: “people sometimes seem to make the assumption that I invented the Spotify model. Well, I certainly didn’t! I’m just the messenger. … The Spotify model is the result of many people collaborating and experimenting over time, and many aspects of the model were invented without my involvement. I certainly wouldn’t want to take the 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

6: Balancing Autonomy with Accountability by Edwin Dando

Additional Resources

If more than 2,200 words reporting my first-hand experience and the words of 4 Spotify employees weren’t enough, read how the Spotify model didn’t work for these people outside of Spotify.

Cover illustration inspired by Bad Blood by Taylor Swift, who knows something about squad goals, but not about copyright. If you forgot 2015, here is an examination of the term squad goals.

Thanks to Roland Siebelink and Jason Harmon for reviewing drafts of this article.

Translation Notes

[TN1] - English terms for some positions were intentionally kept since the text is oriented towards people who are familiar with these professions.

[TN2] - Due to differences in language and style, I adapted some parts to more common terms in Portuguese (Note: this was from the original PT-BR version).

[TN3] - For style reasons, some paragraphs were “broken up” to provide a better reading experience, especially on mobile devices.