Operating model design.
The structure that decides whether anything else holds. Management operating systems, accountability and decision rights, process architecture and documentation.
The problem this solves.
Improvement work decays for structural reasons, not motivational ones. An initiative is delivered, the project team disperses, and the routine that would have sustained it was never set up. Six months later the measure has drifted back and nobody can say when.
The symptoms are recognisable. Meetings that recur without a defined purpose, input or output. Reports produced because they always have been. Decisions that escalate because nobody is certain who is entitled to make them, or that are made twice because two people believed they owned it. Processes that live in the heads of long serving staff and leave the business when they do.
This gets mistaken for a people problem more often than not. It is a structure problem, and structure can be designed.
What a management operating system is.
A management operating system is the defined set of routines by which a business is actually run: which meetings happen, at what frequency, at which level, with what inputs, producing which decisions, and feeding what upward or downward. Written down, it usually fits on a few pages. Undefined, it consumes an extraordinary share of management time.
A workable MOS has layers that connect. A shift review feeds a daily production meeting, which feeds a weekly operations review, which feeds a monthly business review. Each layer has a defined scope and a defined escalation path, so a problem raised on shift has a route upward and a decision made at the top has a route down. Where those connections are missing you get plenty of activity at every level and no alignment between them.
I have designed and implemented a first management operating system at multi site scale, alongside the improvement programme it was built to sustain. The two are difficult to separate: improvement without an operating system reverts, and an operating system without improvement work has nothing to carry.
Accountability and decision rights.
Most organisations can name who does the work. Fewer can state clearly who decides, who must be consulted before a decision, and who merely needs to be told afterwards. That ambiguity is expensive: it slows decisions, generates rework, and produces the familiar situation where everyone believed someone else was handling it.
The fix is dull and it works. Map the decisions that actually matter, establish who holds each one, agree who has to be consulted first, and write it down somewhere people will look. A RACI is the usual instrument. The instrument matters far less than the argument it forces you to have.
Process architecture and documentation.
Process documentation has a poor reputation, mostly deserved. Written badly it produces shelfware that describes an idealised business nobody recognises. Written well it captures how the work is genuinely done, including the exceptions, and becomes the basis for training, audit, systems configuration and eventually sale of the business.
The same discipline applies to complex external rule sets. Regulatory, market and contractual requirements get written to be legally precise, which is not the same as being followable. The cost of that lands on whoever has to comply: misinterpretation, avoidable non-compliance, delays, and a steady stream of clarification requests back to the issuing body. Turning those rules into logical flow charts clears up most of it. It is the same skill as the rest of this work. Take something technically correct but practically opaque, and make it possible to follow.
- Management operating system. Meeting and reporting architecture by layer, with defined inputs, outputs and escalation.
- Accountability model. Decision rights and RACI for the decisions that actually matter.
- Process maps and procedures. Written as the work is done, exceptions included.
- Flow charts for complex rule sets. Regulatory, compliance or contractual requirements rendered as followable logic.
- Meeting and reporting calendar. What happens when, and what each occurrence is for.
Is this the right fit?
Usually yes, if
- Improvements are delivered and then quietly reverse
- Management time is consumed by meetings of unclear purpose
- Decisions stall, or get made twice by different people
- Critical knowledge sits with a small number of long serving staff
- You are preparing for growth, sale, audit or a systems implementation
Probably not, if
- The organisation is mid restructure and reporting lines are still moving
- Leadership is unwilling to relinquish or reassign any decision rights
- You need a certified management system rather than a working one
- The real constraint is capability or headcount rather than structure
Start a conversation.
The first conversation costs nothing and usually takes half an hour. Tell me what is not working and I will tell you honestly whether it is something I can help with.