Spotify adopted a model of autonomous Squads and Chapters to encourage innovation at scale. Squads are small, cross-functional teams that self-organize delivery of features end-to-end. Chapters are competency-based communities that provide coaching. This align-autonomy model balances independence with consistent direction. Spotify also emphasizes a fail-friendly culture, continuous experimentation, and frequent releases through automation and a microservices architecture.

1. Part 1: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
Part 2: https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
Credits to Henrik Kniberg and Spotify Labs
Spotify Engineering Culture - Summary by Luis Weir
@luisw19
www.soa4u.co.uk

2. Spotify was pretty much a Scrum based company, but as the number
of scrum teams grew, some of the standard Scrum Practices got in the
way (meaning becoming counter-productive). For this reason they
decided to make all of the Scrum practices optional.
”Rules are a good start, but break them when needed”
Agile matters more than Scrum.

3. Slowly they moved away from Scrum and started to
adopt their own flavour of Agile:
• Scrum Masters became Agile Coaches
• Scrum teams became Squads.
• Main driving force were therefore Autonomous
squads.
Squads is a small cross-functional and self-organising
team (<8 people). They own all activities end to end,
design, dev, ops, maintenance, etc.
Spotify believes that autonomy is critical as it’s
motivating. And motivated people performs better.

4. Squads even have their own physical space space,
with lots of white-boards and an environment that
encourages collaboration.
Autonomy also enables speed, as many decisions
happen within the Squads.

5. Although Squads are autonomous, they are all align
with product strategy, company priorities.
“Is kind of like a Jazz band. Musicians are
autonomous however they all listen to each other
and focus on the whole song together.
Loosely coupled, but tightly aligned Squads.”

6. Spotify has over 50 Squads spread across 4 cities. So
some sort of structure was needed.
• Squads are group in Tribes. A Tribe is a
lightweight matrix organisation,
• Squads are the primary organisation and focuses
on product delivery,
• However people within a Squad also belongs to a
Chapter, which is a competency area (e.g. UI
development, Agile Coaching, Microservices, etc),
• Chapter leads are the formal line managers and
focus on coaching and mentoring individuals
within the chapter,
• Furthermore special interest groups were created
for individuals across Chapters and Squads to
gather and share knowledge around a specific
topic (e.g. leadership, Web Development, CICD).
Individuals can enter/exit Guilds at any time. A
Guild typically has a mailing list, a bi-annual
conference, and/or other informal means of
communication.

7. In reality, things aren’t as simple and lines aren’t as straight as
things keep changing. But this is ok.
”The most valuable communication happens informally and in
unpredictable ways”
“Organisation charts are an Illusion. So focus in on Community.”

8. The model is based on high alignment and
high autonomy (align-autonomy) as it
delivers a good balance of independence
with consistent direction across squads.

9. The Job of a leader is not to boss around
and tell people what to do. Rather provide
direction by indicating problems that have
to be solved and why.
Squads then collaborate to find the right
solution (each within their own
boundaries).

10. There is no mandated standards or tools.
They follow a culture of Cross-pollination.
Squads copy from other Squads what
works. Then eventually certain practices
and/or tools sort of become the defacto
standard. But nothing is mandated.

11. Spotify follows a Microservices Architecture. Each system delivers a single
functionality (e.g. playlist management, search, monitoring) and they are build,
tested, deployed and manage independently by a Squad.
In practice, a Squad typically owns more than one system (or microservice).
“Spotify promotes an internal open source model, with a culture of sharing as
opposed to owning.”

12. Because Spotify’s architecture is decoupled, failure is
limited to specific features. This is called “Limited
Blast Radius” so a failure doesn’t propagate to the
entire system. Sort of what the Microservices
Community refers to as Bulkheads and/or Circuit
Breakers.

13. Spotify has a strong culture of Mutual Respect.
People credit each other for the work they do.
There is very little “I” culture and no room for “ego”.

14. Even though Spotify has experienced a massive growth in staff
in the recent years, the focus remains heavily on motivating its
people. It’s impressive and encouraging to see how much
emphasis is made to their people and good is never good
enough.

15. Spotify invests heavily in test automation and
continuous delivery to ensure releases are small
and frequent.
”release should be routine, not drama”.
Again, pretty much in-line with the culture of
automation in Microservices Architectures.

16. Spotify changed their monolithic architecture to a
decoupled (Microservices?) one to enable decoupled
releases. This enables Squads to been able to release
code independently.

17. Squads evolved into 3 main types:
• Feature: focuses on one feature area
(e.g. search),
• Client App Squad: focuses on making
release easy o specific client platforms
(e.g. IOS, Android, etc),
• Infrastructure: Provide self-service tools
and routines for things like Continuous
Delivery, A/B Testing, etc.
Hand-offs are avoided, and a self-service
model is favoured.
Infrastructure Squads in other models are
referred as Platform teams, and they do a
similar role. Create self-service capabilities
that their customers (developers) can use
to deliver solutions end to end.

18. However there is a level of coordination and sync when doing releases. Spotify addresses
this with Release Trains and Feature Toggles.
• Each client app has a release train that departs on a specific schedule. They are frequent
and the reason being is to avoid too much up-front planning,
• When a release includes are feature that is not finished, it’s hidden using a Feature
Toggle –which allows to show and hide features in test as well as production. Toggles
are also used when conducting A/B testing and gradually roll out features.

19. For Spotify Trust is far more important than Control.
”Agile at scale, requires Trust at scale. This means NO POLITCS, and NO FEAR.
Fear kills trust and innovation. If failure gets punished no one will dear to try new things.”

20. “To make something really cool, mistakes will be made along the way. Each failure can also
be a learning. And if we fail fast, we can also learn fast and improve fast. It’s a strategy for
long term success.”
Spotify is a Fail-friendly environment where the main interest is in Fast-failure recovery as
opposed to Failure-avoidance.

21. Some Squads even have a Fail Wall, to
capture and share the latest failures
and learnings.
Failures are always followed up with a
post-mortem to find out not just what
happened but also lessons-learnt and
what should be changed to improve.
“Spotify has a Culture of Continuous Improvement.
Driven from below, but supported from above.”

22. Product Development approach is based on Lean
Startup principles.
”The biggest risk is building the wrong thing”
• Before building a new product our feature,
research happens to validate the idea (e.g. do
people actually want the feature?),
• If idea is qualified, narratives (elevator pitch
showing the benefits) are defined and prototypes
built to get a feeling of the feature or product,
• The next stage is to build an MVP with the
minimum possible set of features,
• Release happens gradually to the entire audience.
A/B testing used to measure impact.
• Then iteratively tweak the MVP to improve it.

23. Spotify cares more about innovation than
predictability as the more predictability the less
innovation there is.
Only when it can’t be avoided, date commitments
are made (e.g. partner integrations).

24. Innovation comes from people, but people then
need to have the time to play around and
experiment.
“if we try many good ideas, we’re bound to find
gold from time to time”
Spotify encourages its staff to spend around 10%
of their time to experiment new ideas (hack time).
Once a year, Spotify has a week-long hackathon,
with a big party at the end.

25. Overall Spotify has an Experiment-friend Culture.
Even the hack-week started as an experiment.
But Spotify also has a Waste-repellent culture.
Practices that don’t work are dumped, those that
work are kept.
I love it!!

26. A common source of waste is big projects. Thus when they can’t be avoided (because the benefits outweighs
the risks) big projects are broken down into smaller efforts.
Practices like white boards to visualise progress, daily sync meetings for Squads to discuss dependencies,
frequent demos and a small but tight leadership group (to keep eye in the big picture) help reduce risks on
big projects.
Spotify acknowledges they’re not great at big projects yet thus they are still experimenting.

27. As Spotify continues to growth, they still battling with
growth-pain. As they grow, they also risk falling into
chaos, or the opposite too much bureaucracy (if too
much structure is introduced).
So the question is what is the Minimum Viable
Bureaucracy?
The waste repellent culture and agile mindset helps
Spotify remain balance and avoid falling into chaos or
bureaucracy.

28. Squads often define what Awesome means. This helps
them set goals and direction.
Also agreeing on what good actually looks like,
improvement efforts can be more focused and progress
better tracked. A lean technique called Toyota Kata is for
example used to define Awesome, and
achievable targets and steps.

29. Spotify continuous to grow very fast but is also changing fast. However the challenges
that come with growth are overcome because people actually do something about it.
“Spotify is pretty good a changing the architecture, process, organisation, or whatever
is needed to solve the problem.
Healthy culture heals broken process”.

30. The Spotify engineering culture empowers its people at many different levels
as it provides a very good balance of freedom and structure. It’s open approach
towards collaboration, respect and trust, ensures that Squads are align, share
knowledge and experiences, thus avoiding common pitfalls –whilst not
reducing the amount of innovation.
Their experimental and “fail fast-learn fast-improve fast” culture is an engine
for innovation as teams are encouraged to try new ideas out, without being
worry of being punished if some of the ideas fail.
Spotify’s decoupled architecture (probably based on Microservices although
not explicitly mentioned) is most likely a result of their engineering culture, as
opposed to purely driven by technology and/or architectural preferences. Can’t
help it but to say it’s Conway's law in action.
This model however, is not for all organisations and many will find it very
difficult to adopt. Specially large traditional corporations where the level of
politics and bureaucracy is so high that change take ages to occur, shifting to
the Spotify way of doing this will be a huge undertaking. For such
[traditional] organisations, keeping pace with more innovative companies
(those that do succeed in adopting a Spotify like model) will be a struggle. On
the flip-size, large organisations that do manage to shift, will be able to benefit
from their size and market reach plus the agility, speed and innovation enjoyed
by the likes of Spotify. Only time will tell!!
Summary