Learn More About the Spotify Squad Framework — Part I
By: Thaisa Fernandes
Tags: Spotify, Agile, Leadership, Scrum, Project Management

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.

Each Squad has autonomy to decide what to build, how to build it, and how to work together while building it. However, the Squad needs to be remain aligned with the Squad mission, product strategy, and short-term goals.

“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.

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

Tribe: Lightweight matrix, a primary dimension focused on product delivery and quality.

Lightweight matrix, a primary dimension focused on product delivery and quality. Chapter: Group formed based on competency areas such as quality assistance, Agile coaching, or web development.

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

Instead of creating cumbersome rules and processes to manage their releases, Spotify simplified the process to encourage small and frequent releases. They changed the architecture to enable decoupled releases using the encoded embedded framework. Each section of the web browser is like a frame of a website where each Squad can release their own stuff directly. They have three different Squads based on the self-service model.

Feature Squad: Focused on one feature area.

Focused on one feature area. Client App Squad: Focused on making the release easy in one specific area of the platform.

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.

The interesting part is that Spotify releases hidden features. For example, if the next train leaves with a feature that isn’t 100% done, they release it with this feature hidden. Why do they do it? The answer is simple! Releasing unfinished features and hiding them exposes integration problems early and minimizes the need for code branching. Brilliant!