People ask me about this, so I figured I’d write something.
NOTE: Although I was at Spotify for around 8 years, I‘m not familiar with how every area worked and I have my own biases, preferences, etc. AND things change
I will define “Spotify Model” as any concept or practice mentioned in the Spotify Engineering Culture videos. I’m only covering part 1 in this post.
Agile > Scrum
Spotify was mostly Scrum in the early years (before my time, so I can’t confirm this) but shifted to a more general Agile approach. There was no requirement for standard Scrum practices nor are there any Scrum Masters anymore, as far as I’m aware.
This principle reflected a general expectation of responsibility on autonomous teams. This still holds and I agree with it.
Having said that, I sometimes found what Squads chose for themselves to be sub-optimal and slower than I would have liked if I was actually on the Squad myself.
I think originally, there was a valid assumption that Squads had enough Agile background to make pretty good calls. As Spotify, and really the overall industry, has grown, there are more and more people with a shallow or warped understanding of Agile.
Agile > Scrum? Yes, BUT don’t assume that everyone has the same understanding of what “Agile” means.
Autonomous Squads
“Squads” at Spotify are not a synonym for “team” but specifically a cross-disciplinary, autonomous, product development team. Marty Cagan calls this an Empowered Product Team.
Every Squad has a mission but is responsible for deciding what to build, how to build it, and how to work together to accomplish the mission.
Common mistakes I saw with some Squads:
- Seeing autonomy as a benefit “we get to do whatever we feel like!” rather than as a responsibility “we are both authorised and expected to do what is necessary to accomplish the mission”;
- Missing that Squad responsibility includes coordinating or collaborating with other Squads as necessary;
- Insufficient cross-pollination amongst Squads leading to unnecessary variation and relearning;
- Missing context for how the Squad’s mission fits within broader strategy — which can lead to Squads lasting longer than appropriate
When faced with these problems, newly hired leaders might suggest “there’s too much autonomy” when the actual correct answer is “aligned autonomy” (see later).
I’d also say that Squads can noticeably vary depending on the mission. Team Topologies covers some of it (stream-aligned, enabling, complicated subsystem, platform) with some additional variation depending on product life cycle stage (innovation vs differentiating vs commodity).
Autonomous Squads? Yes, but autonomy should be framed as a responsibility, not a benefit AND there should be deliberate cross-pollination AND aligned autonomy is still important.
Office optimised for autonomous Squads
Spotify now advocates for Work-From-Anywhere and Distributed-First. So, although the office is nominally still optimised for autonomous Squads, a lot of people aren’t working at the office.
Office optimised for autonomous Squads? Sure, but it may be shifting to distributed-first.
Alignment enables autonomy
The goal is “loosely coupled, but tightly aligned Squad”.
“The stronger alignment we have, the more autonomy we can afford to grant.”
This concept comes from The Art of Action, which applies “mission command” to the business context.
Henrik’s sketch from Part 1 is still one of the best illustrations of this:
Alignment on its own is insufficient to enable autonomy. In Turn the Ship Around, L. David Marquet identifies two pillars that allow “giving control” (AKA enables autonomy): competence and clarity (AKA alignment).
Alignment enables autonomy? Yes, at least since Clausewitz in the 19th century AND competence is also required.
Cross-pollination > standardization
I think cross-pollination has become more difficult as Spotify has grown.
Although I think cross-pollination is still valuable, there’s now probably more emphasis on Spotify’s version of the “paved path” pattern, called Golden Path. There is training, support, tooling, etc. for the Golden Path BUT you are able to make a different decision if it makes sense and are willing to take on the overhead yourself. Someone will probably check in if the decision doesn’t make sense.
There is also a company-wide Tech Radar to provide broader guidance.
Cross-pollination > standardization? It’s more cross-pollination AND Golden Paths AND Tech Radar > imposed standardization.
Internal Open-Source model
Although services are supposed to have clear Squad owners, if the owning Squad is too busy, a requesting Squad can make their own changes and submit it for review.
This has become more difficult as the number of systems and domains grow, Squads have different styles, etc.
The general ideas of “sharing > owning” and “doing > waiting” are still good but this again highlights the importance of cross-pollination. There may also be new teams, typically from acquisitions, that are more territorial, which needs to be addressed.
Internal Open-Source model? Yes, but more cross-pollination across domains is necessary to scale effectively.
People > *
People > * refers to a culture of mutual respect. We’re all in it together, etc. This generally held but has become harder to maintain as the company grows, new acquisitions, etc. Selection, onboarding, deliberate cultural expectations, are necessary to maintain a culture of mutual respect.
People > *? Yes, but it gets harder as the company grows and can’t just be assumed to be true without deliberate actions to maintain it.
Recent layoffs will also put this cultural assumption under threat.
Focus on motivation
The example used here was the Head of People Operations not being satisfied with 91% employee satisfaction.
“People Operations” no longer exists, it’s just “Human Resources”.
The focus on improvement is still important but I’m not sure I would call it “focus on motivation” per se.
Focus on motivation? I’d suggest “focus on improvement” instead.
Structure: Squads, Chapters, Tribes, Guilds
Lightweight matrix structure where every person is in a Squad (delivery axis) as well as a Chapter (discipline axis) reporting to a Chapter Lead (discipline-focused manager). The Chapter Lead reporting model was intended to allow people to change Squad without having to change managers. Squads are grouped together into Tribes. There are also communities of practice called Guilds. Some Guilds are discipline-oriented, some are more hobby Guilds. Reality was messier than this description.
Chapter Leads have gone away. The title has changed to “Engineering Manager” (EM) and EMs are mostly associated with a single Squad. Reality is still messier than this description.
The primary goal of a matrix structure is to produce necessary conflict between competing goals (in this case, delivery vs developing discipline competence). This necessary conflict hasn’t become unnecessary just because a particular role was renamed, and reporting lines were adjusted.
There was an effort to discontinue use of the term “Tribes” because of the American association of “tribe” with North American indigenous populations. No clear alternative was found while I was there.
Other structures have appeared as Spotify has grown larger. Missions are collections of Tribes. Business Units include Missions and Business Teams. Product Areas are sort of proto-Tribes but also sort of show up when it makes more sense to have a larger Tribe with a coherent strategy rather than split into multiple Tribes.
Squads, Chapters, Tribes, Guilds? Chapters may or may not explicitly exist anymore. Some people dislike the term “Tribes”. There are other structures beyond Tribes: Product Areas, Missions, Business Units.
Community > structure
Org charts are an illusion. Strong community can compensate for informal, volatile structures.
This is true and it is harder to maintain strong community as organisations get larger.
Community > structure? Yes, but this is harder to do as organisations grow. Well-designed (and ongoing redesign of) structures helps.
Make releasing easy
Instead of the vicious cycle of painful releases leading to less frequent, larger releases, which are even more painful, leading to even less frequent, larger releases, etc., you want the virtuous cycle of easier releases to enable more frequent, smaller releases, which get even easier with practice and tooling, leading to even more frequent, smaller releases, etc.
The Extreme Programming community used to describe this as “if it hurts, do it more often”.
There are differing levels of maturity of this, especially with newly acquired companies but otherwise, this still holds true.
Make releasing easy? Yes.
Decouple as much as possible
Design the technical architecture to enable decoupled releases.
As things scale up, “decouple as much as possible” leads to duplicate capabilities and duplicate stores of the same data. Granted, sometimes decoupling is worth the overhead of duplication but not always.
Cohesion and coupling, that is what should be dependent and what should be independent, should be driven by product strategy. If a product capability needs to be able to iterate independently, then duplication may be justified to enable that. If consistency in product processes or data is more important than iteration speed, then duplication is not justified.
Decouple as much as possible? I’d suggest instead designing cohesion and coupling in response to product strategy.
Self-service model
There are different flavours of Squads (e.g., feature, client app container, infrastructure, etc.) acting in a self-service way to avoid handoffs.
This is similar to what’s described in Team Topologies.
The drive toward a self-service model generally holds true though it is much more complicated with scale. Sometimes, I found Squads would pretend to be self-service too early without spending the initial collaborative effort necessary to design self-service interfaces that actually work (AKA conquer and divide).
Self-service model? Yes, but first, collaboration is needed to effectively design self-service.
Release trains and feature toggles
When synchronization is required, use release trains and feature toggles. It seems to me that the need for release trains is almost entirely related to App Store release constraints. Otherwise, continuous delivery is preferred.
Release trains and feature toggles? Yes, as long as App Store constraints exist otherwise continuous delivery is preferred instead.
Trust > control
“Agile at scale requires Trust at scale. That means No Politics. It also means No Fear.”
I agree that Agile at scale requires trust at scale. This is essentially the ability to both assume mutual respect (as mentioned in People > *) as well an appropriate level of competence. I disagree that this means no politics. In fact, I’ll suggest pretending that there are no politics generally leads to less trust.
Trust-at-scale requires acknowledging the humanity of politics and fear.
“No to pretending politics and fear don’t happen; yes to encouraging dialogue and safety in response to politics and fear.”
So, I think a more useful framing is “feedback generates trust”. If a situation is generating fear or seems political, share the feedback and engage in dialogue. Have the Crucial Conversation. Passive trust is not as reliable as active trust based on feedback.
Trust > control? I’d suggest, that “feedback generates trust” is a more useful framing.
Next: Part 2
