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

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

Aligned autonomy

Alignment vs autonomy in a 2x2 matrix
Alignment vs Autonomy (picture extracted from part 1, drawn by Henrik Kniberg)
  • Leaders communicate what problem needs to be solved and why;
  • Teams collaborate to find the best solution.
  1. (alignment) A clearly expressed product strategy;
  2. (autonomy) Empowered Product Teams (aka Squads)

Clearly expressed product strategy

  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)

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

Creating trust-at-scale (across boundaries)

  • 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

  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

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

Decoupling (to enable autonomy)

Architecture follows strategy

Stage #1: Market Development; Stage #2: Growth; Stage #3: Maturity; Stage #4: Decline
From “Exploit the Product Life Cycle” by Theodore Leavitt, Harvard Business Review Nov 1965
Product capability dependent on a single technical service (fine); product capability dependent on two technical services (fine); two product capabilities dependent on one technical service (might not be fine)
Don’t couple product capabilities (especially at different life cycle stages)
“Market Development” services can depend on “Growth” or “Mature” services; “Growth” services can depend on “Mature” services
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

--

--

--

Staff Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

A Critical Approach to Evidence Based Management in the Agile Context

How to Shape Salesforce Products on the IdeaExchange

Influence the product roadmap. Salesforce IdeaExchange. Trailhead character Astro with a foam thumb in an outside setting.

My product management toolkit (49): Systems Thinking tools & techniques

Product Requirements Document: Fingerprint Feature BCA Mobile Apps

How to Create an Agile Community of Practice

6 MONTH JOURNEY

How to build your product startup from a project

Incremental and Iterative approach of Agile Methodology.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jason Yip

Jason Yip

Staff Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl

More from Medium

You need a delivery manager on your team

Three women sitting on a sofa with Macbooks

Spotify: The Agile Nirvana?

Guiding principle: consent over consensus

“We don’t have time! I’ll make the decision myself!” leading to “Why can’t we execute?!?”

Refactor → Organisation

An organisation is represented by a matrix of circles, representing teams; and strong lines joining them in a grid, representing team interactions. The diagram poses the question “Arrange departments like this?…” and shows the teams being grouped in columns — with strong vertical lines and weak horizontal lines. It then poses the question “… or like this” and shows the teams being grouped in rows with strong horizontal lines and weak vertical lines.