The top 3 points you should have paid attention to in the Spotify Engineering Culture videos that aren’t Squads, Chapters, Tribes, Guilds

Most of the time when someone mentions the “Spotify Model”, they only talk about structure: Squads, Chapters, Tribes, Guilds.

When it comes to product development culture, structure is the last thing you should be worried about, not the first.

Without even looking at specific contexts, I bet that there are other points in the two videos (part 1, part 2) that are way more important for most organisations. The top three that come to mind are:

1. Aligned autonomy;
2. Creating trust-at-scale (across boundaries);
3. Decoupling (to enable autonomy)

Aligned autonomy

From part 1,

Alignment and autonomy are not two ends on a scale but two dimensions on a 2x2 matrix.

Alignment vs Autonomy (picture extracted from part 1, drawn by Henrik Kniberg)

Low alignment, low autonomy means no communication of the problem that needs to be solved AND people are just told to shut-up and follow orders.

High alignment, low autonomy means effective communication of the problem to be solved BUT people are still told exactly how to solve the problem.

Low alignment, high autonomy means no communication of the problem to be solved AND people just do whatever they feel like… which ends up creating Frankenstein, incoherent products.

What we generally want instead is high alignment, high autonomy, also known as aligned autonomy:

• Leaders communicate what problem needs to be solved and why;
• Teams collaborate to find the best solution.

NOTE: The concept of Aligned Autonomy comes from The Art of Action, which applies “mission command” to the business context.

There are two parts to aligned autonomy:

1. (alignment) A clearly expressed product strategy;
2. (autonomy) Empowered Product Teams (aka Squads)

Clearly expressed product strategy

There are many different ways to express a product strategy. The specific format depends on your specific context and organisational preferences. However, good product strategies have a structure that follows what Richard Rumelt calls the kernel:

1. A diagnosis based on data and insights;
2. A guiding policy, that is, a set of beliefs that describe the general approach to overcome the identified problems;
3. A key set of coherent actions (or more accurately, bets).

Empowered Product Teams (aka Squads)

Empowered Product Teams:

• Are multi-disciplinary (Tech, Product, Design, Insights). All skills needed to progress exist on the team;
• Have a mission;
• Are expected, and have the authority to, figure out for themselves how to achieve their mission.

Empowered Product Teams are operating effectively in aligned autonomy if it’s clear how each individual team’s mission fits within the context of the larger overall product strategy AND the teams are coordinating their activities as-needed.

Creating trust-at-scale (across boundaries)

From part 1,

Agile at scale requires trust at scale. The videos suggests that this comes from no politics and no fear. I don’t agree with this. (More later)

There are two key contributors to trust-at-scale:

• A strong culture of cross-pollination;
• A strong culture of mutual respect (aka People > *). This is associated with the shared belief that we’re all in it together and need to help each other to succeed

Cross-pollination encourages trust

Cross-pollination encourages trust by humanising across boundaries.

There are three forms of cross-pollination:

1. Embedding: someone temporarily transfers to another team;
2. Liaisons: someone acts as the primary point-of-contact to another group. Effective liaisons are deliberately selected based on being well-respected and reliably good at developing relationships;
3. Internal movement: someone permanently transfers to another team but still has relationships with their previous team.

Mutual respect encourages trust

Mutual respect is established by the interaction habits of influential role models, the design of systems to encourage respectful behaviour and discourage disrespectful behaviour, and the stories that are told of what is considered good or bad.

Trust-at-scale requires acknowledging the humanity of politics and fear

“Anything that is human is mentionable, and anything that is mentionable can be more manageable.”

Fred Rogers (aka Mr. Rogers)

No to pretending politics and fear don’t happen; yes to encouraging dialogue and safety in response to politics and fear.

(I discussed this previously in Why aligned autonomy is an ongoing struggle)

Decoupling (to enable autonomy)

From part 2,

The architecture is decoupled so that a single Squad’s actions will only impact a small part of the system and not everything. This not only limits the blast radius of mistakes but also allows more independent experimentation.

Architecture follows strategy

Architecture should be coupled where product capabilities should be coupled and decoupled where product capabilities should be decoupled. Architecture should follow product strategy.

Every capability within a product follows a life cycle.

From “Exploit the Product Life Cycle” by Theodore Leavitt, Harvard Business Review Nov 1965

Each stage requires different activities and have different measures of success. For example, market development requires a lot of experimentation, growth requires a lot of iteration, maturity requires a lot of optimisation, and decline may include outsourcing or shutdown.

Technical services supporting product capabilities should not cause capabilities at different stages to be coupled.

Don’t couple product capabilities (especially at different life cycle stages)

Services supporting stable capabilities should not depend on services supporting more volatile capabilities.

Services should only depend on other services that are as stable or more stable

Spotify Models are for the obedience of fools and the guidance of the wise

The next time you hear about the “Spotify Model” please think of it as an example and not something to blindly copy AND at least, instead of Squads, Chapters, Tribes, Guilds, think aligned autonomy, creating trust-at-scale (across boundaries), and decoupling (to enable autonomy).