Welcome to part two of our ultimate guide to enterprise operating model transformation!
In part one, we covered the theory of what an operating model is, the pitfalls to avoid and the core principles of a killer operating model.
In the second part, we will look at the practicalities of implementing and evolving your operating model successfully:
- How to harmonise the different business domains
- How to evolve your operating model effectively over time
- Top tips for getting started with your operating model transformation
Even if you have an overarching operating model for your entire business, it is still the case that each area of your business will have to define its own local mode of operation.
And it’s helpful to have a separate operating model for cloud, data and product and so on because they are separate concerns with different considerations.
But they can’t operate completely in isolation.
If there is no overarching schema for determining effective decision-making in those domains then you start getting conflicting objectives, incentives that pull in different directions and cultural differences start to emerge. Your business becomes fragmented with different parts moving in different directions.
And then the people at the top need to start making heavy-handed top-down decisions to hold the company together, which destroys the autonomy and trust that is so critical to a modern business.
But an effective operating model, as we have seen, empowers people throughout the business to make effective decisions such that their role complements the direction of the business.
This should be true at the level of the individual, the team and the domain.
In this context, the operating model is what helps to guide and enable better decision-making across boundaries. It is a kind of choreography that brings all the different parts of the business together like an orchestra to create a symphony of innovation!
Think of a Venn diagram, where each domain is distinct, yet connected with overlapping concerns.
Where there are commonalities and links between business domains is where there should be North Star metrics that show where they need to work together to avoid conflicting objectives and incentives.
These commonalities should of course be linked back to business objectives! (But you knew that).
But how do you get from A to B?
You can’t just jump to a whole new operating model overnight.
It has to evolve and emerge piece by piece.
This inevitably involves what is often known as bimodal IT: a mode of operation where one part of the business is running on the existing operating model and another part has moved into the new operating model.
But most people misunderstand bimodal IT. They view it as an enduring state where there are just two parts of the business permanently at odds with each other.
I would like to suggest a different way of viewing bimodal IT as a dynamic, evolving system based on Simon Wardley’s concept of pioneers, settlers and town planners.
These three categories describe different stages of the innovation cycle.
Pioneers: these folk are at the forefront of innovation. They are coming up with new ideas and are empowered to experiment, try things out and fail fast. They tend to work in the lab working directly with customers, while developing prototypes.
Settlers: these are the ones that take the pioneers’ prototypes and turn them into viable products. They tweak the initial idea based on feedback and consider how it could work at scale.
Town planners: these people are able to take a proven product idea and industrialise it. They turn it into a stable commodity or utility that can be used at scale.
These categories represent the whole spectrum of innovation from prototype to product to commodity.
What you need is a bimodal (or multimodal) operating model that is linked to the evolution of your products and services on the spectrum from more experimental/innovative to more stable/commodity.
So in the pioneer realm, the emphasis might be on experimentation: rapidly developing new product prototypes, testing them with a small number of people and iterating fast in the early stages. There is no fixed technology or architecture: the right tools and way of working will emerge iteratively from this process.
And the people, process and tech will be different for this stage.
For example, you need a specific kind of person that is comfortable with uncertainty and that is OK taking ownership and making decisions and changes quickly.
The processes might be different, because your team might be building and running the prototypes (end-to-end ownership) and interacting closely with a small number of customers to get rapid feedback and minimise the blast radius if anything goes wrong.
And the tech might be different because you are rapidly spinning up new cloud-native environments to quickly test new code or using cloud-native services to experiment with new ideas in a rapid, low friction manner.
Then as your prototypes start to develop—based on key objectives and metrics—your operating model might change to become more steady-state.
Where in the beginning you might have put out 100 iterations of a new app in a six week period the rate of fundamental change might be slowing down.
This is then akin to the ‘settler’ phase, where you might be running several versions of a product and testing them with a wider range of customers.
Again, here you will have a different set of people, processes and technology suitable for a more predictable and stable way of working.
Once you’ve mitigated the 4 key product risks (value, usability, viability and feasibility) for your product you will transition to the commodity state. Here your operating model is less about innovating the product and more about scaling the number of users and the operational aspects.
In this ‘town planner’ phase you want the kind of people, processes and technologies that are well-suited to maintaining long-term stability and resilience at scale.
The Innovation Spectrum
What this looks like from a birds-eye view is that you’re allowing new technologies, applications and ways of working to emerge through experimentation and then allowing them to become ‘commoditised’ so that they become part of the standard way of working.
As Simon puts it: “activities and practices move from chaotic (poorly understood, uncertain, constantly changing, rare, future source of worth) to more linear (well defined, predictable, stable, common, cost of doing business) … Understanding this and using the right methods and tactics is important to creating a balance between the unstable but potentially high margin activities (chaotic) and the stable and low margin (linear). This process of evolution from chaotic to linear is why "one size fits all" mentalities are so dangerous because you either impact survival today (through poor efficiency) or survival tomorrow (through future wealth creation).”
The key point is this: your operating model needs to be able to prescribe different people (roles/responsibilities), processes and technologies based on where a given product/service sits in the business.
This is then ‘true’ bi- or multi-modal IT, which is dynamic, responsive and ever-changing. Not static and stuck.
Finally, let's round things out with some critical ideas and concepts that will help you get started on the operating model journey.
It’s good to have a North Star: an inspiring vision of what could be. But this should only be to stoke ambition and motivate people. Not something you attempt to create overnight.
Instead of trying to boil the ocean you should think big, but start small. So you might start running experiments where you start forming teams that are experimenting with new ways of working, changing roles and responsibilities at a small scale. When you have small successes you can then start scaling these across the business.
I call these ‘lighthouse projects’: low-cost, low-impact mechanisms to give you feedback on whether a given hypothesis or experiment is viable that can be quickly dismissed or further scaled.
People want to define their target operating model and just hope that that’s the end of it!
But this leaves no scope to learn and grow. This whole process is an iterative process of feeling your way into the right operating model. It’s an ever-evolving adaptation.
Your people will need support when they are being asked to change how they work in fundamental ways. And the payoff from investing in supporting them is massive.
Create ‘mini-consultancies’ that help to introduce new capabilities into the business. E.g. a new core cloud or core data capability. That team exists solely to adopt the new technology and coach the business in new ways of working.
Your whole operating model should be in constant evolution. In fact, one of the key goals of an effective operating model would be to ensure that the business is capable of continuous improvement.
As you scale the roll-out of the operating model you want to track key metrics and use your feedback mechanisms to drive the evolution of the operating model.
When you cultivate that ability to incrementally adapt then you are no longer dependent on these big, disruptive step changes every 5/10 years.
Transforming an operating model is a massive undertaking.
But so long as you are clear on your business objectives and take the time to talk to the business and make slow, stepwise progress towards your next iteration you should be able to reliably improve the throughput of business value.
If you’re still feeling a little mystified, the folks here at Mesh-AI have deep experience in creating and transforming operating models in a wide range of enterprises.
Interested in seeing our latest blogs as soon as they get released? Sign up for our newsletter using the form below, and also follow us on LinkedIn.