why did the spotify model fail?

(corollary: what is the #1 factor in high performing teams?)

Spotify is a popular music streaming app founded in 2006. The company designed a unique approach in which they enhance team agility through organizing around work called the Spotify Model. Introduced in 2012, the model focuses on the way of working of an organization to enable agility by stressing the importance of culture and network. At that time, Spotify was growing fast that sought to bring in a new way of working. They introduced autonomous, cross-functional teams called squads, comprised of designers and engineers with a range of skillsets. Squads were required to work on one (and only one) feature area at a time: the purpose was that any team would not have to depend on other teams to succeed. Product managers and designers reported to department heads. Effectively, software engineers were driven out of the team structure. 
 
Why was The Spotify Squad Model a failure?
 
Spotify confessed post-IPO that there were many issues with the model, which Spotify never truly adopted and labelled it as aspirational: 

• Re-labeling teams and departments as ‘squads’ and ‘tribes’ created confusion and failed mythology: At its core, the model amounted to a re-labeling of a matrix structure. Each ‘chapter’ was really just a functional area (e.g. Testing, Programming, Design) with its own people manager. A ‘squad’ is simply a cross-functional team. Why not just call it a team? Each ‘Tribe’ was really just an old-fashioned 'Department’.  Nothing changed about these structures, so new names just created confusion and led to the myth of meaningful change.

• Matrix management was ineffective: Each ‘Squad’ (which should have been called a Team) had multiple functional managers, one for each ‘Chapter’, which were just functional areas re-labeled: Testing, back-end, mobile, etc. Any disagreement within the team often had to be resolved between multiple managers, and without consensus, then had to be escalated to the Director of the ‘Tribe’ (Department).

• As a scale-up company, teams optimized for autonomy were sub-optimal: Squads were optimized for maximum autonomy. This is great for a fast-adapting start-up but created problems for a mature scale-up company. Spotify needed more consistency between teams to better manage the company’s fast growth and, avoid duplication and avoid downstream complexity & technical entropy.

• Teams lacked basic Agile competency: In alignment with the autonomy, Spotify gave each team control over its own process and practices. But they didn’t have enough coaches to help every team, and many teams did not have enough knowledge of Agile principles and practices to implement them effectively. It was not really agile. It was just every-two-weeks-waterfall.

• Collaboration between teams was an assumed competency: Spotify allowed teams to control their way of working although many people did not understand the basis of Agile methodologies. As the size of the team increased, they recognized that it was really necessary to give support to guide and structure collaboration between teams …

 
What is the Number One Factor in High-Performing Teams? Ask Google
Google set out to answer the question “What makes a team effective at Google?”. How did they go about it? As you might guess for a data-oriented company like google, they tasked an entire team of researchers on their People Analytics department (don’t you wish YOU had a People Analytics department?) to find the answer in an initiative dubbed Project Aristotle.  
 
The short version is that they studied 180 teams, ran double-blind interviews, combined subjective and objectives measures, and ran all kinds of sophisticated statistical analysis. And the winner is (drumroll please…)
 
Psychological Safety
And what is ‘psychological safety’? The condition where team members feel safe to take risks and be vulnerable in front of each other.
 
How can leaders (and team members) cultivate psychological safety? Amy Edmondson’s book Teaming, and her TED talk, give some concrete advice.

• Frame the work as a learning problem, not an execution problem
• Acknowledge your own fallibility. (be vulnerable)
• Model curiosity and ask lots of questions

​

Framing work as a learning problem acknowledges the inherent uncertainty in conducting complex work. It acknowledges that we don’t have all the answers in the beginning and expect that iteration and experimentation will be required. 
​
Sounds kinda Agile, doesn’t it?

---

Let me know what you think! 
DM me @philippemora on IG and Twitter
​My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. 
​
Head of Digital Product
thinker, doer, designer, coder, leader