What is the Spotify model?

Spotify is more than just a great music streaming service—they also shared a series of videos that describe their engineering-focused culture. When I first came across these videos a few years ago, they gave a glimpse of Spotify’s culture and how they build great teams.

Spotify instills in their teams autonomy, balance between process and innovation, and trust. No matter what your team decides to do, the organization trusts that you can make the best decision for how your team operates. If one team loves Kanban but another prefers Scrum—great. If one team uses Node.js and another Java—that’s fine too. The premise is simple: if you’re a “build and run” team, you should have the authority to make those decisions.

Honestly, I’m a sucker for team empowerment, and I loved these videos when I first saw them. If you haven’t seen them (or haven’t watched in a while), check them out:

• Spotify Engineering Culture – Part 1
• Spotify Engineering Culture – Part 2
• Agile Product Ownership in a Nutshell (Henrik Kniberg)

Fast forward a year

The organization I worked for decided to move the entire Technology team toward agile methods and use Spotify as the foundation. I thought this was a great idea—it resonated with me, and there’s a lot of content to support the transformation.

Armed with a team of coaches, we began working with squads (cross-functional teams) and started seeing success. Teams embraced empowerment, and our early engineering teams—already cross-functional—really leaned into agile concepts.

But things were tougher in TechOps (Infrastructure). These teams had a deeply ingrained project mindset. Work was time-bound, structured, and often individual. Agile and Spotify were seen as checklists to follow, not ideas to adapt. “What do I need to do to be agile?” or “How does Spotify solve this?” were common questions. The mindset shift wasn’t happening.

Strange things started to happen

Engineering teams made progress, but TechOps teams began to struggle. They used Spotify terms—Squads, Chapters, Tribes—but not in the spirit of the model:

• 40-person departments became “Squads” (but not cross-functional)
• “Chapters” were just existing reporting lines
• The “Tribe” was the entire TechOps org

They applied the labels without understanding the purpose. I saw the trainwreck coming, but held my tongue. Instead, I introduced three ground rules:

1. Focus on outcomes for your customer
2. Get frequent feedback with the team
3. Step back every few weeks to improve

Even with those guardrails, things eventually stalled.

What outcomes do you want from your team?

After a few months, the team was still stuck—going through motions, not making progress. The Spotify vocabulary was a distraction. There was no clarity about when to use Scrum or Kanban, or what the terms even meant.

I pulled in the key stakeholder and asked her a simple question:
“Forget everything. What outcomes do you want from this team?”

The conversation shifted. She gave me this list:

• Focus on major priorities
• Tell me what you’re delivering (not how)
• Collaborate better

We formed a small team (6–8 people) focused on one of her goals: improve employee productivity. But before calling them a Squad, we ran a test to see if this model would work. If successful, we’d scale.

Help the team align to their goals

When forming a new team, I like to run a chartering session. Here are a few questions I ask to help guide alignment:

• What do you want to accomplish in the next 90 days?
• Who benefits from this goal, and how will they know?
• Who do you rely on to accomplish this?
• What risks or dependencies might get in your way?

Invite people who can answer those questions—and the people doing the work. If the group grows too large (10+), tighten the goal and shrink the team.

A few weeks after chartering, run a retrospective to check in. The point isn’t to get it perfect—it’s to learn and adapt.

Remember—it’s just a model

After a few weeks of running the experiment, the team liked the approach. We held a retrospective, made adjustments, and started planning our next experiment.

Models like Spotify are great starting points. But they aren’t blueprints. You can’t just copy-paste someone else’s org design and expect it to work.

Instead:

• Start small
• Form a hypothesis
• Run an experiment
• Reflect, measure, and adapt

If the team improves, amplify the experiment. If not, dampen it. Always remember: it’s just a model—you have to adapt it to fit your context.