Spotify Squad framework — Part I

Thaisa Fernandes⚡
Mar 6, 2017 · 7 min read
Source: Spotify Engineering Culture — Part 1

“Rules are a good start, then break them”

Spotify engineers figured out that Agile matters more than Scrum, and principles matter more than any specific practices. Spotify renamed the Scrum Master to Agile Coach because they wanted “servant leaders” more than “process masters.” They also renamed Scrum team to Squads.

What’s Squad?

It’s a small cross-functional, self-organized team usually with less than eight members. The team members have end-to-end responsibilities, and they work together towards their long-term mission. On Squads the key driver is autonomy.

“Be autonomous, but don’t sub-optimize!”.

Why autonomy?

Autonomy provides employees with a sense of collective ownership. They are part of a greater whole, active (rather than passive) members of the team, “making a positive overall contribution to the organization” — Griffin and Moorhead, 2008 (Organizational Behavior Managing People and Organizations, 2009 Ed).

Trust > control

People work with autonomy, mastery, and purpose. Autonomy is motivating, and motivated people build better stuff, faster. Autonomy makes us faster by allowing decisions to be made locally instead of by managers and committees.

Squad roles

  • Leader’s job: Communicate what problem needs to be solved. And, why.
  • Squad’s job: Collaborate with team members to find the best solution.

“Loosely coupled, tightly aligned squads”

Why alignment?

Alignment enables autonomy. It’s important that everybody understands the company/startup culture. The stronger our alignment, the more autonomy we can afford to grant. Autonomy with alignment increases motivation, quality, and faster releases.

“Autonomy with alignment increases motivation, quality, and faster releases”.

Source: Spotify Engineering Culture — Part 1

Spotify process

Spotify has little standardization, it doesn’t have a formal standard. They believe that cross-pollination is better than standardization. For example, when enough Squads use a specific tool, that tool becomes a path of less resistance and other Squads tend to choose the same tool. After other Squads use the same tool, test it, and collaborate together, then the tool becomes a default standard.

Consistency x Flexibility

Spotify employs an internal open-source model, their culture is more sharing than owning. Based on mutual respect and little ego, Spotify has a peer code review, where anyone can add any code at anytime. Then a peer can review the code and make adjustments. Everybody collaborates together and spreads the knowledge! They also have a culture that focuses on motivation, which has helped them build a very good reputation as a workplace.

How the Squad works

As long Spotify has a lot of different Squads, they needed to create some structure. Each Squad is grouped into a Tribe, which has a Chapter. In this environment, you can switch your Squad without changing your manager. They also have a Guild, which is a community of interest that uses a mailing list or another informal type of communication method inside Spotify.

Source: Spotify Engineering Culture — Part 1
  • Chapter: Group formed based on competency areas such as quality assistance, Agile coaching, or web development.
  • Guild: A lightweight community of interest where people across the whole company gather and share knowledge of a specific area. Anyone can join or leave a Guild at anytime.

“Most organizational charts are an illusion”

Most organizational charts are an illusion. Spotify’s main focus is community over the structure, rather than hierarchical structures. They found that a strong enough community can get away without volume structure. If you need to know exactly who is making decisions, you’re in the wrong place.

“If you need to know exactly who is making decisions, you’re in the wrong place at Spotify.”

Source: Spotify Engineering Culture — Part 1

How easy can they get their stuff into production?

The main goal is to have a small and frequent releases and invest in automation and infrastructure for continuous releases. When the release process is difficult, even simple releases are difficult to release. In the other hand, when the process for releases is easy, releases can be issued more frequently!

Source: Spotify Engineering Culture — Part 1
  • Client App Squad: Focused on making the release easy in one specific area of the platform.
  • Infrastructure Squad: Focused on making other Squads more effective by providing tools and routines for Squads.
Source: Spotify Engineering Culture — Part 1

Release trains — feature + toggles

Each client app has a release train that departs on its regular schedule, typically every week or every three weeks depending on the client. The trains depart frequently, and reliability doesn’t need much upfront planning.

Principles > Practices

Interesting ideas:

  • Almost all walls at Spotify are whiteboard.
  • Each Squad has their own space with a lounge and meeting room.
  • Hidden features are released to expose integration problems early.


After you read Part I, don’t forget to read Part II here.

No fear, no politics! Keep experimenting Spotify!

Source: Spotify Engineering Culture — Part 1

If you’re looking for PM goodies, don’t forget to check out my online store:

Check my online store here:

👏 Clap once, 👏👏 clap twice, clap however many times you want.

Find out more about me @ my Portfolio, LinkedIn, Instagram, and Twitter. I’m building an app dedicated to women’s health. If you want to get early access, subscribe to the waiting list here. If you’re looking for PM goodies, check my online store too!

📩 Hey you. ⚡Join the PM 101 email list!

I send emails twice a month and I promise is really cool content :)

Click here to subscribe it

Disclosure: This post contains affiliate links and first-party promotion. If you click them and buy a product, I may get a small commission at no extra cost to you.

Product Management 101

PM learnings in my journey at Silicon Valley

Thaisa Fernandes⚡

Written by

Product Manager and a perfectionist in recovery, willing to make more mistakes to validate my learnings.

Product Management 101

PM learnings in my journey at Silicon Valley