Spotify engineering culture (part 1)

Here’s part 1 of short animated video describing our engineering culture (here’s part 2).

This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)

Here’s the whole drawing:


(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)

Here’s Part 2.



  1. […] As we have seen the high-level flow of continuous delivery, this whole process ensures smooth production deployment. The organization that follows this process, do more deployment in a day than single deployment for a month. In the current world, many technology providers who are top in the market follow this process to deliver the quality, reliable and hassle-free service to the end user. As Netflix topper in streaming service, Spotify is another giant in music service. You can read how they are delivering the service to the customer and how it is possible in the spotify technology world. […]

  2. […] Separately, Agile encourages smaller work groups, working on specific problems. It is like having indigenous tribal groups (which model btw, was applied at Spotify). […]

  3. […] mind, and after having digested the points of view about  “Spotify Engineer Culture” – Part 1 and Part 2, from Henrik Kniberg, I’m also joining the discussion with my point of view structured […]

  4. […] Spotify, for example, groups its more than 2,000 employees into agile teams, called squads, that are self-organizing, cross-functional, and colocated. There is no single appointed leader of a squad. The mantra is that “alignment enables autonomy — the greater the alignment, the more autonomy you can grant.” A leader’s job is to figure out the right problem and communicate it, so squads can collaborate to find the best solution. […]

  5. […] The english language is sometimes a system for confusion. That is not what language should be! But consider the times “there” is used when it should be “their”. That “read” (in the past tense!) and “red” are said the same but have nothing to do with each other (unless you “read a red book”). That you drive on a parkway and park in a driveway. And that Spotify is not just a streaming service but also an agile framework! […]

  6. […] La métaphore est quasiement trop simpliste mais constitue pour autant l’épine dorsale de l’adage agile : « on ne négocie pas la date, on négocie le contenu » (cf. « inverser la logique du triangle ressource, temps, périmètre »). Pour les afficionados de l’organisation Agile de Spotify, vous retrouverez la même idée dans ce schéma issu de leurs vidéos « Engineering Culture » […]

  7. […] Team เป็นสิ่งที่เราเรียนรู้มาจากบทความของ Spotify เรื่อง Engineering Culture ซึ่งยอด (CEO) […]

  8. […] I strongly believe that while the classic waterfall model is generally falling out of favor, an organization with full buy-in and a strong implementation of a waterfall method throughout the organization will outperform and have happier, more fulfilled team members than an organization with a half-assed agile-scrum method that is not well defined and executed. Some organizations could do amazing things with complete buy-in on a vanilla agile-scrum methodology. Some will need more of a chaos model. Some would do best with old-school waterfall. The goal of this blog is to define the tools and methods that can be used to find and define tools and methods for determining an approach that could be considered a best practice. In short – what tools and ideas can be used so that every team can have a model named after them like the Spotify Model? […]