If you've heard of operating models before, it was probably from a consultant, or someone like one. You know the type - someone who sounds confident and clever, but when you play back their words in your mind, it doesn’t actually feel tangible or meaningful. You might have sat there and quietly wondered what on earth this all has to do with anything real.
At work, I’m usually something between a product manager and a service designer. I like to feel like I’m making something that has real, functional value in the world. I used to make physical stuff; digital service design is about as ‘de-materialised’ as I like to get. I use visuals, but they need to be super straightforward - journey maps have to be simple enough for anyone, a call centre employee or a junior developer, or even a CEO - to be able to understand, debate, amend, and agree on.
By contrast, ‘op model’ diagrams always seemed like an arcane arrangement of boxes and abstruse terminology, somehow both highly theoretical and crazy-obvious.
But on a project last year, my opinion of op models changed. Instead of having one service to work on, my job was to improve my client's capability to create and run services across the organisation. The usual problems - poor communication and hand-offs, disjointed customer experiences, inefficient processes - applied across a system of services. I had to figure out what specifically needed improving, and how. It was 'service design for how services are designed'. In other words, it was an op model project. (I’ll admit I was a little bewildered by this new vantage point, but I guess that’s what happens when you say you’re ready for new challenges.)
To make a target operating model, first we build a capability map, which is less a map and more a list of all the different jobs that need to be done, in the future world where everything works. Then we identify where the gaps are, and have conversations about how they could be filled. I’m obviously not going into specifics here, but for the project I mentioned above, this capability map / list would be familiar to anyone who’s worked in digital transformation: it covered governance, design, delivery and running of services, as well as enabling capabilities (like legal and HR). Through interviews and workshops I gathered and tested ideas for what the future world needed to look like. I sketched diagrams to play ideas back, and iterate them. Working together, we created a solution in which:
new services are built using flexible resource with the right skills (user research, service design, content design, and so on)
when services transition from 'delivery' into 'live', a service owner should take on accountability for the end-to-end costs and value
a small team coordinates key resources within existing processes, making sure services are built in the right way
I figured it would be useful to summarise this all in a simple, high-level diagram. I had boxes to represent teams and capabilities, and arrows denoting relationships and flows of information. The spatial arrangement took a few different versions to feel right, to make it tell the stories about the organisation I needed it to - but at one point it clicked into place. And just like that, I'd created one of those damned op model diagrams.
The diagram didn’t solve any problems by itself, but it did give leaders and their teams a shared mental model for how things would/should fit together and make sense in this future world. In a complex organisation where teams feel threatened by change, clarity can be transformative. People realise they’re actually on the same side, and start to pull together. In this case, the visuals helped persuade a skeptical and risk-averse senior leadership of the value of the whole exercise, and they decided to support the transformation and fund the work for the coming year.
And so - somewhat begrudgingly - I learned that operating models actually are quite useful. There's no getting around the fact that they are very abstract. You can’t fully collapse an organisation into a simple collection of boxes and arrows. If you get them wrong, they can obscure complexity in an unhelpful way. And just as, in service design, we make sure we include input from users; a good op model should be developed in collaboration with the teams it describes, grounded in real insight and experience. When it’s done right, it can work like a wiring diagram, revealing how things connect, and showing leaders what changes they need to make, and how. Not bad for a few boxes and arrows.
(Postscript: For the avoidance of doubt: an op model is not an org chart. Org charts, generally, are branching hierarchies that explain the management structure. While they sometimes imply ways of working, they don’t capture what skills people have, who they actually work with, or how teams interact with one another. In a modern ‘design org’, for example, designers might report to a head of design, but be accountable to the product team in which they're embedded, as shown below. You’d use an operating model diagram to map out these kinds of relationships, to an appropriate level of complexity - whatever that looks like! One corollary of this is that creating an op model diagram can require a degree of creative license.)
Op model diagram example: the ‘centralised partnership’ (diagram taken from ‘Org design for design orgs’ by Kristin Skinner and Peter Merholz). In this example, a central design team has individuals ‘seconded’ to work closely with a product team, and a team lead who works closely with the head of product. This allows a single approach to design across the org (including things like a design system) while ensuring specific designers develop deep knowledge of a service area.