BONUS Why the Spotify Model Didn't Work (Even at Spotify) With Marcus Hammarberg and Tore Fjaertoft

BONUS Why the Spotify Model Didn't Work (Even at Spotify) With Marcus Hammarberg and Tore Fjaertoft

BONUS: Why the Spotify Model Didn't Work (Even at Spotify)

Imagine a company that spends a year building an iPad app—and on launch day the product owner says: "Now it'll be interesting to see IF anyone uses it." In this episode, Marcus Hammarberg and Tore Fjaertoft share why organizations keep installing frameworks like software, why it still doesn't work, and what they've learned from places like Spotify about treating your way of working as a product in itself.

When Copying Without Adopting Becomes the Norm

"It becomes more about following whatever this framework tells you to do, rather than to understand what the problem you're trying to solve is all about."

Marcus and Tore met at a consultancy in Malmö and within 15 minutes realized they shared the same frustrations—despite coming from opposite directions. Marcus comes from the ground up as a software developer and coach, while Tore works top-down with leadership teams on product organization design. Both had worked at Spotify and both had seen organizations copy famous frameworks and models without adopting the underlying mindset. The telltale sign, as Tore describes it, is when people focus on compliance rather than being pragmatic—following the manual without questioning whether the way they're working is actually serving the organization. As Marcus frames it through Cynefin, product development lives in a domain where best practices don't even exist—only emergent practices that you discover by trying things out.

Treat Your Process Like a Product

"The easiest way for us to explain things has been: take the mindset you use for your product, and then use that same mindset when you're approaching how you set things up and how you work internally."

The core idea Marcus and Tore keep returning to is deceptively simple: see the way you operate as a product in and of itself. Just as a digital product is never finished—you ship it, observe how customers use it, and evolve accordingly—your operating model should follow the same cycle. Tore explains that the "customers" of your process are your employees: they need less friction, more empowerment, and the ability to spend more time on work that actually moves the needle for users. Marcus connects this to the lean concept of True North—a shared direction that everyone understands, so that every experiment and process change moves the organization closer to what matters. He contrasts this with the three Agile transformations he participated in that all had the same misguided tagline: "get more out of our development organization." As Marcus points out, even the AI DORA report shows developers feeling more productive individually—but is individual productivity really the goal?

The Factory Floor Story: Empowerment Needs Alignment

"Everyone down here knows that anything we do needs to be the best in the world, in every step."

Marcus shares a powerful story from a Swedish lorry factory where workers changed their workstation instructions several times a day—written on a whiteboard with a pen, not locked in a manual. When asked how they got everyone to engage in continuous improvement, the factory managers didn't understand the question. Every worker on the floor knew they were building the most expensive lorry in the world, and they wanted it to stay the best. That shared purpose drove improvement without mandates.

But Marcus is quick to add the counterbalance: empowerment without alignment leads to local optimization. The factory combined local metrics with overarching flow metrics, so everyone could see how their station fit into the whole chain. Marcus and Tore distill this into three interconnected principles: empowerment to enable people to change how they work, alignment to steer toward shared outcomes, and collaboration to prevent teams from optimizing in isolation.

From Static Frameworks to Dynamic Ways of Working

"We realized that Spotify didn't use the Spotify model. They moved on, because they see the way they work as a continuously evolving approach."

Tore reveals one of the most striking lessons from their Spotify experience: the company that accidentally created "the Spotify model" had already moved beyond it by the time the rest of the world started copying it. The reason? Spotify treated its way of working as something that continuously evolves—not a static blueprint to install and follow. Marcus adds a practical example from Spotify: on your first day, you got access to the company's key metrics. Everyone knew the True North—at the time, increasing monthly active users—and every process change, every experiment, every team decision was oriented toward that outcome. The contrast with organizations that "install" a framework and then wonder why it doesn't work couldn't be sharper. As Marcus puts it: "We tried process X, it didn't work. We tried process Y, the opposite, and that didn't work either. Why doesn't the process work?" The answer is that the "how" must emerge over time, guided by a clear "why."

Always Know Why You're Doing What You're Doing

"I don't want anyone to work on anything if you don't know why."

Tore shares a policy from a product management colleague at Spotify: every single day, everyone on his team should be able to articulate not just what they're working on, but why—and the "why" could not be "because person XYZ told me to." It had to connect to the company's purpose and users. Marcus takes this even further, recounting how he once stopped productivity at an entire company by telling developers: don't work on anything unless you know why. Nobody could continue. The uncomfortable silence that followed became a powerful catalyst for change. With an 80% failure rate for product experiments being the industry standard, packaging that risk into year-long projects is a recipe for the iPad app scenario they opened with. The alternative is to build the organizational muscle for rapid experimentation—cheap hypotheses, fast feedback, and the humility to let outcomes guide the way forward.

Self-reflection Question: When was the last time you asked your team—or yourself—"why are we doing this?" and got an answer that connected to a real business or user outcome rather than "because the framework says so"?

About Marcus Hammarberg and Tore Fjaertoft

Marcus Hammarberg is a product and software coach and consultant who has seen product organizations from the inside and from the trenches. He works at Humane, part of the ADRA consulting collective, and has experience from Spotify, Tradera, and multiple Agile transformations across banks and insurance companies.

Tore Fjaertoft is a product organization advisor who works with leadership teams on how product thinking actually scales in large, complex companies. He works at Above, also part of the ADRA consulting collective, and has experience from Spotify and Volvo Cars.

You can link with Marcus Hammarberg on LinkedIn and Tore Fjaertoft on LinkedIn.

Avsnitt(200)

BONUS The Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software With Ran Aroussi

BONUS The Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software With Ran Aroussi

BONUS: Why the Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software How do you build mission-critical software with AI without losing control of the architecture? In this e...

14 Mars 37min

Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right

Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right

Junaid Shaikh: Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right Junaid opens with a line that cuts straight to the most common PO anti-pattern: "You are the...

13 Mars 16min

How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics

How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics

Junaid Shaikh: How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics Junaid's favorite retrospective format? The vanilla: what went well, what could have gone better, wha...

12 Mars 11min

Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times

Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times

Junaid Shaikh: Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times For this week's coaching conversation, Junaid brings a challenge that resonates well bey...

11 Mars 15min

Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It

Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It

Junaid Shaikh: Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid's book recommendation is The Culture Map by Erin Meyer. As a Scrum Master working at co...

10 Mars 15min

The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire

The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire

Junaid Shaikh: The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire In this episode, Junaid shares a story from his early days as a Scrum Master when enthusiasm got ahead of e...

9 Mars 14min

BONUS: Leadership Is Contextual With Daniel Harcek

BONUS: Leadership Is Contextual With Daniel Harcek

In this CTO Series episode, Daniel Harcek shares how leading engineering teams across radically different scales — from a 7-person fintech startup to a 2,000-person cybersecurity company — taught him ...

8 Mars 41min

Populärt inom Politik & nyheter

aftonbladet-krim
svenska-fall
p3-krim
rss-krimstad
fordomspodden
rss-expressen-dok
flashback-forever
rss-sanning-konsekvens
motiv
aftonbladet-daily
spar
rss-vad-fan-hande
blenda-2
olyckan-inifran
rss-krimreportrarna
rss-frandfors-horna
rss-flodet
dagens-eko
svd-ledarredaktionen
grans