What an operating system is,
and how to tell whether yours is capable

The purpose of this piece is to define what I mean by an organisation's operating system, to explain why the one an organisation believes it has and the one it actually runs are rarely identical, and to set out how an executive can judge whether theirs is capable of converting strategic intent into enterprise value. I realise the term risks sounding like another name for the operating model, which is already a crowded idea with a large literature behind it, so it is worth being explicit at the outset about why I think the distinction earns its place.

The question tends to arise at a specific moment: when an organisation is preparing for a major restructure, integrating new capabilities during a technology change, or asking whether its current model can absorb the next stage of growth or a shift in strategy. If you are looking for operating model design support in Australia for one of those reasons, the useful first step is usually not a new organisation chart but an honest reading of the system the organisation actually runs, because that is what the redesign has to work with. The Enterprise System Health Check is designed to give that reading across eight capability domains before any redesign begins.

It is also worth conceding that operating model work is valuable and that many organisations have a well-designed one. This piece does not contend that those models are wrong. It contends that a model describes how an organisation intends to work, whereas what converts strategy into results is the system that runs from day to day, with its workarounds, informal decision paths and inherited habits, and that system is frequently not the one the model describes.

Why "operating model" is not quite enough

An operating model, in the way it is usually commissioned, is a design artefact. It describes a target state, often in terms of capabilities, structure, locations, governance and technology, and it is typically produced at a point in time to support a strategy or a reorganisation. That is a reasonable thing to produce and it gives an executive team something to point at. The difficulty is that it tends to describe the organisation as designed, and the organisation as designed is arguably a poor predictor of how a decision is actually made on a Tuesday afternoon, which is the thing a CEO needs to understand when a strategy is not converting.

When I use the term operating system, I mean the whole interlocking arrangement through which the organisation actually runs: how decisions are made, how information moves, what work is done and how, who is responsible for what, which systems and data people rely on, and what the organisation is for. It is the current state, operating, and it exists whether or not anyone has designed it. In that sense every organisation has one, and the more useful questions are whether it was designed or accumulated, and whether it is capable of doing what the strategy now asks of it.

The eight domains, and the question each one answers

I describe an organisation's operating system across eight capability domains, set out in more detail in The Living Organisation. They function as a connected system and not as independent workstreams, so a change in one tends to require a response in the others, and Data is the foundation layer on which the rest depend. The table gives each domain with the plain question an executive can ask of it.

Domain	The question an executive can ask
Technology	What systems do we depend on, and do they support the way we actually work?
Governance	Who decides what, under what authority, and how would we know a decision had been made?
Structure	How are work and accountability divided, and does that division match how value is created?
People	Do we have the capability, capacity and working norms that the strategy assumes?
Process	How does work actually flow, including the workarounds?
Information Flow	Does the right information reach the right person in time to change a decision?
Data	Do we agree on what our numbers mean, and does anyone own them?
Purpose and Objectives	Is it clear what we are here to achieve, and can people at every level connect their work to it?

The system you believe you have, and the one you run

The first of the three enterprise principles I use is Operating System Configuration, which borrows from configuration management in systems engineering, where the first task is to establish an accurate, agreed picture of what a system currently consists of before anyone proposes to change it. Applied to an organisation, the principle asks for a baseline picture of the operating system across the domains as it actually is, and not as the strategy documents, the organisation chart or the operating model describe it.

The gap between the two is usually unremarkable in any single place and significant in aggregate. The chart shows decisions rising to a committee, while in practice a particular executive decides in conversation and the committee ratifies. The documented process has seven steps, while the team follows four and keeps a spreadsheet for the rest. Two functions report the same measure with different definitions, and each is right by its own convention. None of these is a scandal, and each is a sensible local adaptation, but together they describe an operating system that differs, sometimes substantially, from the one the executive believes they are steering.

I would add, in fairness, that this is not evidence of poor management. Organisations are living things, and three of the domains in particular, Purpose and Objectives, Structure and Process, evolve continuously as people adapt. That is precisely why the configuration has to be maintained deliberately and not documented once, because a baseline taken in January is arguably an approximation by September.

The delivery system and the operating system

A second distinction matters for anyone running change. The operating system is the organisation as it runs today, the business as usual, with its external stakeholders and vendors. The delivery system is the future-state arrangement of projects, programs and portfolio through which change is made. They are different, but they draw on the same eight domains and, importantly, on the same people, so a program that changes the operating system does so while the operating system is still running, and a program that ignores the capacity of the operating system to absorb it will find that out at an unwelcome moment. Considering both concurrently across all eight domains is, in my view, one of the things most commonly missing from transformation plans.

How to judge whether yours is capable

Capable, in this sense, means able to convert strategic intent into enterprise value, and I find it more useful to break that into three questions, each of which corresponds to one of the three enterprise principles and each of which is explored further elsewhere on this site.

The differences between the answers are the useful part of this exercise, since they show where the system is running differently from the way it is described.

What this approach does not claim

I should be clear about its limits. Asking these questions from within the executive suite gives a perception-based view, shaped by who is asked and what they are willing to say, and perception is not the same as evidence. That is the reason the Enterprise System Health Check is described as a screening that tells an organisation where to look, while the Enterprise System Diagnostic is the instrument that establishes what is true. There is also a reasonable objection, which some systems thinkers make, that the word system and the engineering vocabulary around it can make an organisation sound more mechanical and controllable than it is. I take the objection seriously, and the response I would offer is that the vocabulary is borrowed to give executives disciplined questions about a living organisation, and is not intended to suggest that people can be configured like components.

If the operating system is the thing that actually converts strategy into results, and the one that is running differs from the one that is described, would it not be reasonable for an executive team to ask, before the next investment or restructure is approved, who in the organisation currently holds an accurate picture of what that system is, and how they would know?