Check out our newsletter archive. If you like 0800-DEVOPS, please share the good vibe and forward this article to your friends. Thanks, you rock!
Or you can just sign-up here.

Roll your own Spotify Model

A fantastic article appeared recently with Jeremiah Lee, a former Spotify employee, confirming what has been known (but ignored!) for years – there are serious flaws with organizations understanding and using the Spotify model.

What came to be known as “the Spotify model” is in fact a snapshot in time of a continuous improvement journey that this company is undertaking. As such, this snapshot is not perfect, nor is the current state where the company is today, nor is the final state that the company will end up. At the time of coining the term, the Spotify model was only aspirational, and time proved that it was never even fully implemented. This is perfectly normal since the model demonstrated weaknesses and Spotify, in continuous improvement manner, made further improvements.

There is one particularly interesting weakness of the Spotify model that Jeremiah notes.

Although organized in smaller teams and equipped with all necessary tools, the productivity suffered since teams didn’t collaborate and tended to solve the same problems, again and again, each team in its own way.

This resonates well with the main DevOps message: focus on people, processes, and tools – in that order!

Believing there is a one-size-fits-all universal prescription on how to structure any organization is much easier than accepting that in the improvement journey there are no shortcuts. Over time, The Spotify Model became just another cargo cult, a blue pill from The Matrix. What we should do instead is learn from Spotify, but roll our own “Spotify model”.

And what is interesting, nobody can blame Spotify since they have themselves communicated many times that this model is only aspirational, has serious flaws and is in no way perfect, even for them, let alone for other organizations. But we people hear what we want to hear. There is a name for this bias and you can find it in our book recommendation!

Hand picked

+ Digital Transformation Is About Talent, Not Technology. “Every technological disruption has generally led to automation and the elimination of outdated jobs, but it has also always created new jobs.” This is especially true when introducing DevOps culture to your organization. Automation will free up more time for your people to be creative. Invest in their leadership, collaboration, and learning skills so that time is not squandered, but used for creative and value-generating activities. “Since nobody knows what the key future hard skills will be, the best action is to bet on the people who are most likely to develop them.” Once again, automation is only one side of DevOps coin, people are the other!

+ Matthew Skelton, co-author of Team Topologies describes taking excellent structure from a famous book Continuous Delivery and turning it into a Trello board to gain more visibility into challenges that need to be addressed when implementing the concept. Since no two teams are identical and working in identical organizational contexts, this board shouldn’t be used as a universal one-size-fits-all checklist for implementing Continuous Delivery. Rather, it should always be used for facilitating discussions around options and priorities that will drive specific improvement actions.

+ Marek Bartík is summarizing the 10 most common mistakes using Kubernetes. How many boxes can you tick? Just remember that less is better

+ Due to Conway Law, deployment pipelines in your organization will be highly influenced by your organizational hierarchy. Check out some of the typical structural anti-patterns as well as one pattern that has always proved beneficial, a pattern that promotes organizations as “a place where they enable individual teams to succeed on their own terms, while still giving them the guardrails and training they need to meet the org’s standards of cloud excellence.”

+ Service Mesh is an architecture pattern aimed at managing cross-cutting aspects of service-to-service communication such as security, observability, service discovery, circuit breaking, etc. Although promising as a concept, specific implementations have for long been in the development phase and deemed complex to use. In its latest release of Technology Radar, good people from ThoughtWorks have placed Istio (as one specific Service Mesh implementation) in Adopt ring suggesting production maturity. If you are new to Service Mesh pattern, here is a nice collection of resources to catch up with this concept.

Read with us

Cloud Native Transformation: Practical Patterns for Innovation

Stripped down to its basics, cloud native transformation is all about organizations finding their way toward something new (cloud native technology) in an environment full of uncertainties. As such, this journey is not straightforward, nor linear, and there can be no detailed up-front project plan.

There are however a number of practices (or patterns) that proved beneficial when applied in a certain order. What exactly does it mean to apply these patterns in the context of a specific organization is up to that organization alone.

The thought process and patterns described in this book are super relevant not only for cloud native transformation, but for any organizational transformation in the face of uncertainty. Recommended 14/10.

Quote of the Day

“Technology itself doesn’t deliver velocity, though it can certainly help. Changing your culture—the way you work every day—is how an organization gains true velocity.” 

—Pini Reznik, Jamie Dobson, Michelle Gienow, authors of Cloud Native Transformation

Check out our newsletter archive. If you like 0800-DEVOPS, please share the good vibe and forward this article to your friends. Thanks, you rock!
Or you can just sign-up here.