Blind Belief

However, let it be clear: whatever side of the spectrum you adhere to, always be reasonable about choosing your operating model. Here is why.

Spotify vs. standardisation

Let us have a look at the famous Spotify model in which a product team assumes complete responsibility, steering through the entire lifecycle of development —from design to building and running. This framework thrives on the principles of freedom, speed, and innovation. Yet, even Spotify itself, despite pioneering this model, eventually parted ways with it. The culprit? A fragmented ecosystem emerged, as engineers found themselves repetitively reinventing identical building blocks, resulting in a discernible slowdown in innovation. 

On the flip side, there exists a contrasting belief in a centralised and standardised approach seeking to leave little room for deviation. While this ensures uniformity, it also erects barriers to innovation. 

Between these two extremes lies a vast spectrum, free to roam. Unlike the fixed rivalry of El Clasico. The challenge now lies in finding the right operating model(s)—that strike a balance, harmonising autonomy and standardisation to optimise team efficiency while still fostering a culture of continuous innovation.

Define your accountability model(s)

In a hybrid world of innovation, the supporting technology platform brings the potential for accelerated business value creation.  It does however come with a challenge: who is responsible for what task?  “You build it, you run it…”.  A well-known idiom within IT, once said by Werner Vogel of AWS and eventually polished with the addition: “you pay it…”.  Reality is a bit more complex. The definition of who does what, in other words, the accountability model is the starting point to get to an operating model. 

First of all, nobody said you have to pick only one accountability model. There is room for multiple approaches living side by side. After all, your workloads are probably different in nature and thus require a different approach. Would you want to make your SAP developers responsible for patching the enterprise storage solution it is running on?  Or would it be a smart idea to make developers responsible for windows patch management in an IaaS scenario?  

The architecture of a specific application portfolio has a direct impact on the most likely accountability model.  Modern (cloud) applications allow a totally different accountability model compared to a VM based IaaS lift and shift platform. After all, accountability modelling is not a one size fits all exercise.  It goes way beyond beliefs and ideal models. 

Create a canvas  

It is imperative that you get a crisp understanding of all your stakeholders and their interactions. In other words: who is involved in the full lifecycle of the application and how do they relate to each other? Make sure you include your external partners here as well.  Putting all of this down on a canvas will give you a starting point to get to the right operating model. 

Define your capabilities  

Now that you have an idea of your accountability model(s) and your stakeholder canvas, it is time to make this as tangible as possible. To do this you need to understand your IT capabilities, or the various skills, technologies, resources, and processes that enable organisations to effectively use, manage, and leverage information and technology to achieve their goals. These capabilities are crucial for the successful functioning of modern businesses and organisations.  However, the specific IT capabilities needed can vary depending on the nature and scale of the organisation, industry, and its strategic goals.  Focus on defining what your organization’s capabilities are and make sure there is a clear understanding of all of these amongst your stakeholders. 

When the capability level is not tangible enough, it makes sense to look at activities and tasks.  A capability is a grouping of activities and tasks. It is often easier for all stakeholders to understand the specifics of a capability when the underlying activities are shown. 

Map capabilities to your canvas for each accountability model 

Finally, a high-level operating model, without going into the specifics of the underlying accountabilities, is a nice theoretical exercise.  It will unfortunately not help to accelerate innovation or business value creation.  To achieve this goal, you will need to go at least one level deeper. Only when stakeholders understand and agree where they are responsible for, the model will come alive.  This means doing a mapping exercise of the agreed capabilities to the stakeholder canvas for each accountability model.  While this might seem like a daunting task, when each step is carefully executed, this mapping exercise often turns out to be a rather straightforward last mile.

---