Discover our blogs

Fairytales don’t exist.  Especially not in IT.  With Cloud technology emerging, a new type of operating model started to get a lot of traction and attention.  The “old school” siloed IT department running projects in a waterfall way is not the best match with the new technology possibilities.  People were looking for inspiration for the new digital native companies and how they run their IT. 

Enter: the Spotify model

What is the Spotify model?

The Spotify model is a people-driven, autonomous approach for scaling agile that emphasises the importance of culture and network. It aims to increase innovation and productivity by focusing on autonomy, communication, accountability, and quality.  The Spotify model was first introduced to the world in 2012, when Henrik Kniberg and Anders Ivarsson published the whitepaper Scaling Agile @ Spotify.  This article will not go in detail to explain the model as such.  Just as a reference, the model is often visualised like this:

There is an interesting fact about this way of thinking: Spotify never used the Spotify model themselves.  Without going into the details, in a world of ultimate freedom, one would introduce in-efficiency and the model would become way too expensive.  Especially once you start to scale out.

So, the original model evolved to one where we speak about product teams and platform teams.  The idea behind this evolution is to have more efficiency in terms of shared capabilities.  The reality often turned into: product teams are autonomous teams that are less autonomous than squads.

What are we trying to fix?

Let’s take a step back.  What we are really trying to fix is to increase innovation and productivity by bringing teams closer to the business.  If we take that as the starting point and we look at the complexity of an enterprise scale IT team, it’s a lot more complex to work out a workable, efficient, and modern operating model.

An existing IT team will have to deal with a lot of legacy.  In terms of systems, tools, architectures, but also skill sets.  A Cloud transformation is never a greenfield approach.  A “big bang” approach is simply not possible.  So, there will always be a “hybrid” situation.  Often the aim is that this should be temporary, reality turns out if mostly “for a long time”, if not permanent.  Your operating model needs to take this reality into account.

The Annapurna of models

Thinking of how projects are done is an interesting topic.  Even if you don’t do projects anymore, but translate it into feature releases, the point is how new stuff is being built.  And that needs to fit into an efficient model.  What is however equally, or even more, challenging, is how this stuff will be supported.  

You build it, you run it…  Brutal reality check.  The run part turns out to be the Annapurna of enterprise scale transformations.  Annapurna is the deadliest mountain in the world.  Nobody says you can’t reach the summit, but most people die trying.

Now what?

A copy of the “Spotify model” is not a good idea.  Which means the way forward is to use theoretical models as input, mix it with experience from the market, blend in the knowledge of your own organisation to come up with a model that works for you.  

Going into detail is way beyond the scope of a blog.  But giving a couple of topics you must tackle might be a good start.

• How are you going to organise your “project teams”?
• How are you going to deal with external partners brought in by the business teams?
• How are you going to structure your platform teams?  What is in scope for them?
• How will the project and platform team interact?
• How will you deal with finding the required skills at the scale you have in mind?
• How will you set up the accountability matrix between the different actors?
• How will innovation fit into the equation?
• What will your deployment cycles look like?
• …

Let’s start a conversation if you are interested.  At 45 Degrees we are not interested in writing a book about any of these topics, but in helping enterprise customers to make it work in their organisation.