If you've been involved with any digital delivery, you might have heard of operating models or capability maps. You might have sat there and quietly wondered what on earth they had to do with delivering actual services.
I usually describe myself as something between a product manager and a service designer. As such, I use visual artefacts a lot, I like thinking visually - but it’s important to stay anchored to tangible inputs (like user feedback) and outcomes (like product features that address the feedback). For example, we usually summarise the end-to-end experience of a product as a ‘journey map’, which everyone, from the CEO to the call centre employee to the junior developer, can understand and agree on.
By contrast, when I've seen op model diagrams created by colleagues on parallel teams, they've seemed like an arcane arrangement of boxes and abstruse terminology, either overly theoretical or crazy-obvious. Reader, I was naïve, I was wrong. I’m a convert now. Don’t @ me.
My stance on op models changed because of a project I worked on last year. Instead of having one service to work on, with one set of users, stakeholders and legacy infrastructure, my job was to improve my client's capability to create and run services across the organisation. I was working with a system of services, and figuring out what specifically needed improving, and how. With my service designer hat on, it was 'service design for how services are designed'. More properly: 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. I’m grateful to my colleagues for their deep expertise, guidance and reassurance throughout this process!)
A key starting point was to build the capability map, which is basically a list of all the different jobs that need to be done, in the future world where everything works. This helps us identify the main gaps, and have conversations about how they could be filled. (My knowledge of service design and product definitely helped make this nuanced and comprehensive.) Interviewing people and gathering clues like a detective, I pieced together a list of issues. I’m obviously not going into specifics here, but the list would be familiar to anyone who has worked on any kind of digital transformation and change programme. Teams supporting different parts of the same services didn't communicate or coordinate well, which resulted in disjointed customer experiences, inefficient processes and higher-than-necessary running costs.
Through those interviews, and follow-up conversations, I also gathered and tested ideas for how things might be improved. I sketched diagrams to play ideas back, and iterate them. We ended up creating a solution together, such that:
new services should be built using flexible resource with the right skill mix (like user research, service design, content design, and so on)
once services transition from 'delivery' into 'live', a service owner should take on accountability for the end-to-end costs and value
a small team should help manage key resources within the existing processes, and ensure services are built in the right (agile) way and meet the needs of both their users and the organisation
I summarised this in a simple, high-level diagram, which consisted of labelled boxes, and arrows between them denoting relationships and flows of information. And just like that, I realised I'd created an op model.
The artefact didn’t solve any problems by itself, but it did give leaders and delivery teams a shared mental model. It helped them see how things would (or should) fit together differently, in a way that makes sense. In a complex cash-strapped organisation, where teams feel threatened by change, this can be transformative. It helps people realise they’re actually on the same side, and can start to pull together. Once it exists, this shared vision becomes a starting point for more detailed work: terms of reference for new teams, job descriptions for new hires, new processes for decision-making and sign-off. In this case, the visuals also persuaded a skeptical and risk-averse senior leadership team of the value of the whole exercise, and they decided to support the transformation and fund the work for the coming year.
What I learned in this process was that, just as a service needs a journey map to help the team building it focus on how it should feel to users, an organisation can use operating models to make sense of processes and relationships.
For the avoidance of doubt: an op model is not an org chart. Org charts, generally, are simple branching hierarchies that explain the management hierarchy. While these hierarchies can sometimes imply interactions or similarities, line-management isn’t the only kind of interaction teams have with one another. For example, designers might report to a head of design, but be accountable to the product team in which they're embedded (see example below). You’d use an operating model diagram to document and communicate these distinct relationships. For this reason, creating op model diagrams requires a degree of creative license and aptitude.
There's no getting around the fact that operating model diagrams are very abstract. They speak a language of boxes and arrows, denoting groups of people, relationships and processes. They can sometimes obscure sense as much as they create it, and can easily feel impenetrable or academic. When building a service, it’s good practice to include input from its users; in the same way, a good op model should be developed in collaboration with the teams it describes, grounded in real insight and experience. It can then serve as a kind of narrative glue or, perhaps, a 'wiring diagram', revealing how things connect, and showing leaders how to drive effective change.
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.