Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spotify engineering culture summary


Published on

A summary and perspective of the Spotify engineering culture.

Published in: Technology
  • Be the first to comment

Spotify engineering culture summary

  1. 1. Part 1: Part 2: Credits to Henrik Kniberg and Spotify Labs Spotify Engineering Culture - Summary by Luis Weir @luisw19
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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