The Slogan on the Wall: Five Tests That Reveal Whether Your Operating Model Is Real
Photo: Governor Glenn Youngkin, CC BY 2.0, via Wikimedia Commons
An operating model should explain how work flows, who decides, how performance is measured and where capacity is created. An org chart explains reporting lines. When the first is missing, the second quietly takes its place. The result is familiar: a polished diagram in a board pack, a set of boxes with impressive titles, and a service routine that behaves nothing like the picture.
This is not an argument against org charts. Every service needs accountable roles. The problem is that a chart can masquerade as a model for years, especially when governance is mature enough to produce papers but not decisions. The following five tells are practical rather than philosophical. They are the symptoms operations leaders tend to recognise once they stop defending the diagram and start tracing a real customer request.
1. Decision forums meet, but decisions are deferred
A forum that exists to govern service performance should leave a trail of decisions: demand thresholds changed, capacity released, risks accepted, priorities refused. If the same item appears on three agendas without a resolution, the forum is performing governance rather than exercising it. Terms of reference may be comprehensive, but decision rights are vague. The chair sums up by agreeing to take the matter away, and the queue continues to set policy by default.
2. Handoffs follow departmental boundaries, not service journeys
In a real operating model, handoffs are designed around the work. In an org chart in disguise, they are designed around the boxes. A request waits for a weekly team meeting because one department cannot release work to another outside its own calendar. A case is passed to a specialist unit because that unit owns a system, not because the customer needs a specialist. Handoffs are then counted as control points rather than delay. The chart looks tidy; the journey looks like a relay race with no one responsible for the baton.
3. Metrics reward escalation rather than resolution
Service measures are never neutral. They teach people what to optimise. If the scorecard rewards first response time, average handle time and closure within a team, staff will transfer complex cases to protect those numbers. Escalation becomes a sign of diligence rather than a failure of the model. End-to-end resolution time is reported, but no one is accountable for it. The operating model then produces exactly what it measures: activity at each stage, not service at the end.
4. The governance calendar is detached from the service rhythm
Queues change hourly. Demand patterns change daily. Capacity decisions often sit in a monthly meeting, while risk and investment decisions sit in a quarterly one. That cadence may be appropriate for some choices, but it cannot be the only rhythm in the model. If front-line teams are adjusting priorities every morning without a documented route to release capacity, the model is being improvised. A useful test is whether the governance calendar names the operational decisions it is meant to make. If it only names the papers it receives, the cadence is decorative.
5. Change control has no capacity or risk trade-off
A new policy, product or compliance requirement arrives as a project go-live. It is approved on the basis of policy intent and delivery date, not on its effect on demand, skills, queue design or failure demand. No one owns the cumulative load. The organisation then wonders why service performance dips after every change programme. In a functioning operating model, change control is a capacity and risk conversation, not an administrative checkpoint.
A short diagnostic: trace one routine request
Leaders can compare the chart with the daily routine in under an hour. Choose one common request type, ideally one that crosses at least two teams. Reconstruct the last ten cases from the system trail, emails and team recollections. Note each step, waiting point, decision, system, handoff and rework loop. Then ask four questions.
- Which role made each decision, and is that role named in the operating model?
- Which forum approved any exception, and did it actually decide?
- Which handoffs exist in practice but not on the chart?
- Which metric rewarded each step, and did it reward resolution or transfer?
If three or more discrepancies appear, the chart is not describing the operating model. It is describing the reporting line. The next step is not a wholesale restructure. It is usually a narrower repair: clarify decision rights, redesign two or three handoffs, replace one local metric with an end-to-end measure, and set a capacity trigger that can be pulled without waiting for the next quarterly cycle.
The chart is a map, not the route
An org chart is useful for accountability. It cannot explain how service is produced. The test is whether the model changes what happens on a Tuesday morning when demand exceeds capacity. If the answer is that people escalate informally and the diagram remains untouched, the operating model is a slogan on the wall. The work of service improvement begins when managers trace the routine, accept what it reveals, and give the model enough decision rights to behave like a system rather than a slide.
