Operating systems vs operating models

An operating model describes intent. An operating system describes what actually runs.

Most companies can produce the model in under ten minutes. Someone opens a deck, points at a set of boxes and arrows, and says "this is how we work." Fewer companies can describe the system, because the system isn't written down anywhere. It lives in habits: who actually replies to whom, which shortcut everyone takes because the official process takes three days and the deadline is tomorrow, which meeting exists purely to rubber-stamp a decision made somewhere else last week.

The gap between the two

Every company has both. The gap between them is where consultancies make their money, and where most of the value is lost.

Take promotions. The model says: quarterly calibration, structured criteria, panel review, decisions made on merit. The system says: the decision gets made in a five-minute conversation between a manager and their manager's manager, weeks before calibration, and the calibration meeting exists to formalise what's already settled. Nobody lied. The calibration meeting was real. It just wasn't where the decision got made.

Or take onboarding. The model is a 90-day plan sitting in a shared drive, reviewed once a year by whoever owns L&D. The system is a new starter finding the person at the next desk, asking what actually matters, and learning the job from two Slack threads and a Notion page nobody's updated since the last reorg. The plan is real. Nothing in the actual onboarding touches it.

This is the pattern worth noticing: a model is legible enough to put in front of a board on a Tuesday afternoon. The system stays invisible right up until it breaks, and that's the moment everyone finds out what was actually running the business.

Why leaders reach for the model first

The model is easier to build and easier to defend. You can draft an operating model in an afternoon with a decent facilitator and a whiteboard. You cannot draft an operating system in an afternoon, because it isn't drafted. It accretes, one workaround at a time, out of decisions made under time pressure by people who never wrote down what they did or why.

That asymmetry explains most consulting failures. A firm comes in, interviews leadership, and produces a well-structured operating model: clean swimlanes, clear decision rights, a RACI chart nobody will open again after the kickoff. The work gets signed off, the invoice gets paid, and six months later the business runs exactly as it did before, because nobody touched the system underneath. The model changed. The floor didn't.

The same failure, wearing an AI badge

The AI conversation has reproduced this exact gap, just faster and with better production values. An AI operating model is a deck: "AI-first," a Centre of Excellence, a pilot programme, a maturity curve pointing up and to the right. It's the thing you present when the board asks what you're doing about AI.

An AI operating system is the thing quietly triaging inbound enquiries overnight, drafting the first pass of a contract review, screening a candidate pipeline before a recruiter opens it. It doesn't get a deck. Half the time it doesn't get a name. It just runs, and the people closest to the work know it's there because their week looks different than it did a year ago, not because anyone announced it.

The tell is a single question: what changed operationally last quarter because of AI? If the honest answer is "we ran three pilots and wrote a strategy document," that's a model. If the answer is "here's the workflow, here's what it used to cost us in hours, here's what breaks it when it goes wrong," that's a system. Most leadership teams asked this question discover they built the first and have been describing it as the second.

Reading the system before you touch it

You don't fix a business by rewriting its mission statement, and you don't fix an operating model by redesigning it before you've read the system it's meant to describe. The model tells you what people intended. The system tells you what they actually do under pressure, and pressure is where the truth lives.

Reading the system means ignoring the org chart for an afternoon and following the real path of one piece of work: a new invoice, a new hire, a customer complaint. Who genuinely touches it. Where it stalls. What workaround exists because the official route is too slow to survive contact with a real deadline. None of that shows up on a slide, and all of it shows up the moment something goes wrong and three people quietly fix it off the record before Monday's stand-up.

This is also why reading the system has to come before redesigning the model, not after. A model built without reading the system underneath it just adds a second fiction on top of the first. You end up with two operating models and zero operating systems, which is worse than where you started, because now leadership believes something has actually changed.

The useful move

Naming the gap is the first useful piece of work, and it costs nothing. Ask, of any process that matters: is this the model, or is this the system? If leadership can only answer for the model, that's the finding, not a criticism. The system is already there, doing the real work, whether or not anyone's written it down. The job is to go and read it before you decide what to build on top.