Operations is a discipline, not a department.

Because an operator who reorganises in week one is guessing. Most teams have never measured how their own work actually flows — they know it feels slow, but not where the time goes or which handoff loses the context. I spend the first two to four weeks watching the work move and putting numbers on it before I change a thing. The diagnosis is what makes the redesign obvious rather than contentious. Move first and you risk fixing the loudest problem instead of the costliest one, and undoing your own work a month later.

A department is a box on an org chart. A discipline is a way of running the whole business — how decisions get made, how quality is held, how the work flows from sale to delivery to cash. Treating operations as a department leads to a team that owns processes nobody else feels responsible for. Treating it as a discipline means the operating model is everyone’s, governed centrally but owned at the edges. My work installs that discipline into how the company already runs, rather than building another silo for it to live in.

The aim is fewer meetings that actually decide things, not more that report on them. Most operating problems are ownership problems wearing a process costume — work stalls because it is unclear who decides, not because there is too little discussion. I make ownership unambiguous for every critical process and set one weekly rhythm where the few numbers that matter are reviewed and decisions are closed. Done well, the calendar gets lighter, not heavier, because the standing status meetings that existed to chase ambiguity are no longer needed once the ambiguity is gone.

Opinion is where most transformation goes wrong. Everyone has a theory about why the work is slow, and the theories conflict. A measured map settles it: it shows that sixty percent of cycle time is queueing between two teams, or that the rework rate spikes at one specific handoff. Evidence chooses what changes, and it also proves afterwards whether the change worked or whether you just felt busy. Without a baseline you cannot tell a genuine improvement from seasonal noise — and you cannot defend the result to a sceptical CFO who wants more than a confident story.

Heroic quality depends on a few people who simply care more, and it fails exactly when demand spikes and those people are stretched. Structural quality is designed into how the work flows: review gates placed where errors are still cheap to fix, escalation paths that function, and measurement that catches drift early. The standard is written down rather than carried in someone’s head, and there is an owner accountable for the number. The test is whether quality holds when the careful people are on leave. If it depends on them, it is not yet structural — it is luck with good intentions.

The principles are general, but they earn their keep in operations-heavy companies that have outgrown improvisation — usually somewhere between fifty and a few hundred people, in delivery, services, production or multi-site work. Smaller than that, the founder’s own attention is often enough. Much larger, and a permanent executive bench is usually warranted. The deciding factor is not headcount but whether the operating model has stopped scaling cleanly: decisions queueing behind one person, quality depending on heroics, growth creating firefighting instead of momentum. Where that is the pattern, the approach holds regardless of sector.

Everything is documented and handed over: the operating cadence and who runs it, the ownership map for every critical process, the leadership scorecard with each metric defined, and the playbooks for the processes that carry the most risk. It goes to your team, or to the full-time COO you are now ready to hire. The transfer is the point because an improvement that depends on me staying is a dependency, not a result. The honest test of the work is whether a capable team could pick it up and run it without me. If they cannot, the engagement is not finished.

A consultant studies a problem and hands you a recommendation; you are left to implement it. I own the implementation. I sit inside the leadership team, make the decisions I am given authority to make, hold process owners accountable, and stay on the hook for whether the operating model actually holds under real load. The deliverable is a running system, not a document. The philosophy on this page is not a method I apply from outside and leave behind in a deck — it is how I work in the room, alongside your team, for as long as the engagement runs.