Spotify Squad framework — Part I

Source: Spotify Engineering Culture — Part 1

I watched this video about the Spotify Engineering culture last year, and BOOM, my mind just exploded. I fell completely in love with Spotify and its culture. The video explains Spotify Product Development, their release methodology, and the frameworks they use. Spotify is a 100%-Agile company that started with the Scrum framework, but as their teams were growing, they noticed some things on the Scrum framework that weren’t working well for them. So, they decided to break some Scrum roles, artifacts, and events. According to the video, these things were getting in the way, so they decided to make the Scrum roles, artifacts, and events optional.

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

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

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

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!

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.

Attention:

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


👏 Clap once, 👏👏 clap twice, clap how many times you want (actually Medium will only allow you to clap 50 times)

My name is Thaisa. I’m a Product Manager, and I’m based in San Francisco, US.

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!