Adopting the Spotify Culture—Without Losing Your Way

• You can't copy a tech unicorn's structure and expect it to work—especially if you skip the culture part.

• The Spotify model isn't a model—it's a mindset rooted in trust, purpose, and autonomy.

• If you're focused on squads and ceremonies instead of clarity and team ownership, you're doing it wrong.

When Spotify shared their engineering culture in 2012, it was a revelation on how to do agile at scale. Except… 10 years later, CIOs are just as frustrated with agile as they have ever been.

It all started about a decade ago, when Henrik Kniberg posted a two-part explainer on Spotify's "engineering culture" (note "culture" vs "model" here for later).

Within a year the corporate world was scrambling to copy "the model," as they had previously attempted with Facebook's "move fast and break things" and Amazon's "two-pizza-teams."

And yet, as with previous crazes, corporations failed to make a significant dent in the value they were delivering, or their efficiency.

I'm sure there are one or two success stories, but in the two dozen organisations I've come across, there was no noticeable difference in the impact these teams were making (as judged by their internal customers). I would argue that most of them went backwards, if you count how much effort and time was put into "adopting the model."

What I noticed when I looked under the covers in these organisations, is they were doing exactly the opposite of what Kniberg stressed in his videos.

These days when someone tells me "we're adopting the Spotify model," I know they've not watched the video because I've realised "model" means "structure." You'll notice that Kniberg describes it as "culture" not "model."

For over half of his first video, Kniberg urged viewers to ignore the Spotify structure as an ephemeral thing (even with Spotify). He stressed instead that people should focus on trust, community, respect, motivation, and autonomy.

Organisations did the opposite. They spent months or years restructuring their teams into squads, guilds, chapters, and so on. They spent no time at all with the emotionally harder task of asking "what's our team's purpose, how do we measure success?" Rarely did they make the tough decision to allow teams to make their own choices on technology, architecture, and process.

What I realised eventually is that very few people actually watched the video.

Like Scrum, Lean, eXtreme Programming, and SAFe before it, this fad focused on processes and tools instead of focusing on the humans.

And what does this remind us of?

The first credo of the Agile Manifesto urges us to focus on individuals and the way they interact, rather than on processes and tools. And yet the first thing teams do when adopting any agile practice is to focus on processes and tools. They talk about chickens, pigs, t-shirt sizing, burndown charts, stand-ups, retrospectives, and so on. They don't answer the simple question "what are we trying to do here, what's our purpose?"

I find it really naive that a corporation offering (non-tech) products and services to its customers would imagine they can successfully copy the structure of a massive tech unicorn like Facebook, Amazon, or Spotify. The organisational structure in these organisations is, by necessity, totally different from non-tech corporations. Conway's Law suggests that two organisations with different outputs (tech vs non-tech) must have different communication lines—aka structure.

Ironically, adopting the Spotify culture is as intellectually simple as it is emotionally difficult:

Watch the video, make sure everyone in the team watches it.

Do as Henrik suggests:

• Don't focus on structure.

• First, figure out a way of describing the team's purpose, in a way that the whole team can easily tell if they're succeeding or failing on a given day.

• Remove policies that interfere with the team's ability to make its own choices.

• Let the team figure out the rest, manage them to their purpose rather than breaking their work down into tasks for them.

• At every turn, allow them to do their own thing (as long as they're delivering their stated objective)—this is the ONLY way to foster community, trust, and motivation.

If you're serious about tackling culture instead of structure to maximise productivity and motivation, I would recommend Team Topologies, which is a really practical guide to creating loosely coupled teams with clear purpose. A shout-out to the team at Service NSW for introducing me to this book. I would say they're the best Australian example I've come across, in terms of genuinely addressing the things Henrik espouses in his videos. I notice a similar humility in their language to Kniberg's: "we're never perfect, things often don't work." And yet they've subconsciously adopted the Spotify culture more successfully than most corporations.

Even if you can't adopt the Spotify culture, I'd highly recommend watching the first of the two videos; there are some proper pearls of wisdom in there:

• "We'd grown into quite a few teams and found that some of the Scrum practices were actually getting in the way."

• "We decided that agile mattered more than scrum and that agile principles mattered more than any specific practice."

• "Agile at scale requires trust at scale."

• "If you want to know exactly who is making decisions, you're in the wrong place."

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.