Jason Yip · Follow
8 min read · Jan 28, 2023
Part 1 here
NOTE: Although I was at Spotify for around 8 years, I‘m not familiar with how every area worked and I have my own biases, preferences, etc.
I define “Spotify Model” as any concept or practice mentioned in the Spotify Engineering Culture videos. I’m only covering part 2 in this post.
“we aim to to make mistakes faster than anyone else”
“fail fast → learn fast → improve fast”
“failure recovery > failure avoidance”
This failure tolerant, learning focused mindset seemed to vary with both tenure and area of the company. I’d say old-timers were generally more likely to be learning-focused than newcomers.
Depending on the product life cycle stage, there might be different tolerances for failure (or at least what kind of failure is tolerated) and what kind of learning is valued. This makes sense. Fail fast to learn fast should be interpreted differently for innovation capabilities vs differentiation capabilities vs commodity capabilities.
One interesting thing I noticed was the ongoing allure of shifting to larger changes. The more was learned, the more likely there was creeping overconfidence about what was known, the more it seemed wasteful taking small steps to learn fast. Given we know more, why not take bigger Bets? Why not have bigger, splashier, market launches? Why do we need to be embarrassed by our first MVP? Why can’t everyone love our first MVP?
Fail fast to learn fast? Yes, BUT adjust learning focus based on product life cycle stage AND watch out for creeping overconfidence.
I’d also expect recent layoffs to undermine the sense of safety required to fail fast.
“a strong culture of continuous improvement, driven from below and supported from above.”
“This is never about ”who’s fault was it”. It’s about ”What happened, What did we learn, What will we change”.”
There are generally two ways to undermine a culture of continuous improvement: blame and ignoring problems. A retrospective/post-mortem that concludes that everything went perfectly was either incompetent or lying. Retrospectives are primarily intended for learning, not for celebration.
This is especially important as demonstrated by senior leaders. If a senior leader hides a mess with fiction, everyone watching will understand the culture is one of “looking good”, not improvement.
A culture of continuous improvement? Yes, and be very strict about retrospectives/post-mortems being about learning, not celebration.
“…failure must be non-lethal, or we don’t live to fail again.”
Limited blast radius is enabled by decoupled architecture and gradual rollout.
Limited blast radius? Yes. This is pretty much what every modern tech firm does.
Spotify’s version of Lean Startup is Think It Build It Ship It Tweak It.
There were some attempts to add an Understand It stage to reflect initial exploratory discovery activity. This wasn’t accepted across the board.
There was also misunderstanding, especially from newer people, about what the stages meant. For example, misunderstanding “Think It” as just talking and preparing documents as opposed to an initial cross-disciplinary pilot team exploring a problem and producing an initial prototype.
In the cases of misunderstanding, I suspect the main gap is the idea of using building-to-learn versus trying to anticipate up-front.
There was some effort to provide more explicit guidance to the Product community, but I don’t know how that ended up.
I also encountered complaints that not enough effort was allocated to Tweak It, but I suspect this was more a reflection of misalignment in product strategy.
Think It Build It Ship It Tweak It? Yes, but don’t assume every product manager/leader has the same understanding of Lean Startup.
Approaching the direct listing and after going public there was a larger emphasis on predictability.
I think private vs public should be irrelevant.
Instead, I see two important considerations for innovation vs predictability: product lifecycle stage and cascading schedule failure.
If the capability is intended to discover a new market, then yes, innovation is likely more important than predictability. If the capability is intended to iteratively improve in a known market, then it should be more balanced between innovation and predictability. If the capability is commodity, then predictability is likely more important than innovation.
When a lot of teams are working together to deliver a larger initiative or Bet, one team being late can cascade to other teams being late which then cascades to more teams, etc. In these kinds of scenarios, predictability can be more important than any local innovation. Set-based design approaches help here.
Innovation > predictability? Depends on the lifecycle stage AND predictability can be more important when coordinating larger initiatives/Bets.
Another way of describing this is that delivering value is more important than delivering features. That is, feature count is not equivalent to valuable outcomes, better experience, etc.
There is also a related phrase: “release on value, not on time”. This one I don’t like because it can be interpreted as a justification for bigger batches and being slow at iterative delivery. I’d prefer “release quickly and iterate on value”.
Value > velocity? Yes, but this should not be interpreted as a justification to shift to bigger batches and being slow at iterative delivery.
Hack time allows people to exercise their own initiative, try out low probability bets, just mess around and play.
There is strategic value in all of this that I’m not always sure everyone understood.
I like to say, “autonomy is not a benefit, it’s an expectation of responsibility”. Similarly, “hack time is not a benefit, it’s a deliberate mechanism to help people develop initiative”.
Hack time? Yes, and it should be framed in terms of strategic value, not as a benefit.
“instead of arguing an issue to death, talk about things like ”what’s the hypothesis”, and ”What did we learn”, and ”What will we try next””
“more data-driven decisions, and less opinion-driven, ego-driven, or authority-driven decisions.”
An experiment-friendly culture was generally in place or was generally being strived for, but I wouldn’t say it was universal.
Also, it’s very hard to maintain an experiment-friendly culture without deliberate selection and explicit cultural expectations, especially with new leaders.
Every decision a new leader makes from a position of authority rather than from data undermines the idea that the culture is experiment friendly.
Experiment-friendly culture. Yes, but this wasn’t universal and it’s a fight to maintain this.
“If it works, keep it, otherwise dump it.”
Do we share the same understanding of what is valuable? If not, the definition of waste won’t match either.
“This is not how we did it back where I used to work” is not equivalent to wasteful.
Waste-repellent culture? Yes, but probably more important to be clear about what value and waste means.
Spotify had more cohesion within Business Units than across Business Units. This meant projects within a Business Unit were typically easier to coordinate than projects (aka Bets) across Business Units.
Some Business Units were easier to work with than others. I’ve previously written about tactics to use for the ones that were not easy to work with.
Luiza Nunes and James Lewis wrote a nice article back in 2020 that pretty much summarises how to do big projects in “product-mode” organisations. I also added my own thoughts reflecting on that article. Quick summary of the key points:
- Invest in a kick-off or a pilot team;
- Manage dependencies, don’t just list them;
- Strong communication and information radiators;
- Have a dedicated, competent program manager
These things were not consistently done.
Big projects? Still not as good as it could be.
“what is the minimum viable bureaucracy? — the least amount of structure and process we can get away with to avoid total chaos?”
A popular phrase was “controlled chaos” but just saying “controlled chaos” doesn’t mean the chaos is controlled AND there is a big difference between chaos caused by the inherent complexity of the context and chaos caused by lack of clarity on strategy and guardrails.
The answer goes back to the idea of Aligned Autonomy from part 1. Push hard on clarity, use autonomy as an expectation of responsibility, be explicit about guardrails.
Chaos > bureaucracy? I might actually suggest chaos is worse. Focus on aligned autonomy instead.
“most problems are short-lived, because people actually do something about them. This company is pretty good at changing the architecture, process, organization, or whatever is needed to solve a problem.”
Healthy culture heals broken process… until it doesn’t, and the broken processes begin to corrupt the culture.
When an organisation grows quickly, the new people outnumber the old people. The new people can only interpret the culture based on what they can observe (i.e., all the broken processes). The broken processes tell the new people what the culture is and there aren’t enough old people to correct this misconception.
From How NUMMI Changed Its Culture by John Shook:
What I learned was most powerful at NUMMI was to start with the behaviors, with what we do. Define the things we want to do, the ways we want to behave and want each other to behave, provide training, and then do what is necessary to reinforce those behaviors. The culture will change as a result.
Using healthy processes and behaviours to systemically develop a healthy culture is more reliable than the reverse.
Healthy culture heals broken process? Not necessarily and even if it does, unless you fix the process, eventually it won’t.
“No one actually owns culture, but we do have quite a lot of people focusing on it, groups such as People Operations, and about 30 or so agile coaches spread across all squads.”
“Mainly, though, culture spreads through storytelling, whether it happens on the blog, at a post-mortem, a demo, or at lunch.”
There hasn’t been a People Operations for a while and the number of Agile Coaches has dwindled, especially in terms of ratio to the number of Squads. Traditional HR is generally not effective at spreading culture — too few, too far removed, and a lack of trust (which will be worse with a layoff).
When it comes to spreading culture, I like the model from Systems Leadership: role models, systems and policies, and only then storytelling and symbols.
Storytelling and symbols are useful for spreading culture BUT only if they’re consistent with what is spread through the behaviour of influential role models and what is implied by the design of systems and policies. When storytelling and symbols are inconsistent with role models and systems, all they do is reinforce a sense of hypocrisy.
Culture spreads through storytelling? Yes, but role modelling and systems are more important.
