The operations maturity model.

When a founder asks me to "fix the ops," the first thing I do is refuse to answer. Not because the operation does not need fixing, but because "fix" is the wrong verb until you know what stage the operation is at. The fix for a team drowning in daily fires is not the fix for a team that is documented but unmeasured, and neither is the fix for a team that runs well but only when the founder is in the room. Name the stage, and the next move becomes obvious. Skip that step, and you install a sophisticated solution to a problem the operation is not ready to have.

An operations maturity model is the ladder that lets you name the stage. It describes how an operation evolves, from reactive firefighting at the bottom to a self-improving engine at the top. It is not a maturity badge to collect. It is a diagnostic, and its only job is to tell you the one rung you are standing on so you can take the next one.

The five stages

Stage 1FirefightingReactive and manual. The founder is the system.

Stage 2DocumentedWritten down and repeatable, but still pushed by hand.

Stage 3MeasuredNumbers and a cadence. You can see the operation.

Stage 4Self-runningNamed owners run it. The founder is off the daily tree.

Stage 5CompoundingThe operation improves itself. Ops becomes the moat.

Stage 1 · Firefighting

Everything is reactive and manual, and the founder is the operating system. Work gets done because someone notices it needs doing and does it, usually the founder, usually late. There are no SOPs, the same problems recur weekly, and the team is busy in a way that produces motion more than output. The trap that keeps companies here is that firefighting feels productive. Putting out a fire is satisfying and visible, and a founder who is good at it can run a surprisingly large business on adrenaline. What moves you up is the boring decision to write the recurring work down instead of reacting to it again.

Stage 2 · Documented

The work is written down. SOPs exist, roles are defined, and a new hire can be handed a process instead of a person to shadow. The operation is repeatable, which is real progress, but it is still pushed by hand: the documents describe the work, and a manager still has to chase whether it actually happened. The trap here is mistaking documentation for control. A binder of SOPs nobody is held to is shelfware. What moves you up is attaching numbers to the work, so you can see whether the documented process is producing the documented result.

Stage 3 · Measured

Now there are numbers and a rhythm. A weekly operating cadence reviews a metric tree, each number has an owner, and the operation is visible: you can tell on a Monday morning whether last week worked. This is where a lot of competent operations plateau, and it is a comfortable plateau, because measured-but-founder-dependent looks healthy on a dashboard. The trap is that the founder is still the one who reads the dashboard and decides what to do about it. What moves you up is transferring not just the numbers but the decisions to named internal owners.

Stage 4 · Self-running

This is the jump that matters. The cadence runs, the scorecards are owned, and the decisions that used to route to the founder now resolve inside the team. The founder can be out of the building for two weeks and the operating metrics hold. This is the stage most growth-stage companies are actually trying to reach when they say they want to "fix the ops," and it is the one almost nobody reaches by accident, because getting here requires someone to deliberately build the owner map and then step back. It is also the exact gap Plenor exists to close: the work between a documented, measured operation and one that runs without the founder in every meeting.

Stage 5 · Compounding

The operation improves itself. Teams run their own retrospectives, surface their own root causes, and ship their own fixes without being told to. Operations stops being a cost center to manage and becomes a source of advantage, the thing the company does better than competitors who are still firefighting. Few companies live here durably, and the ones that do got here by climbing every rung below, in order. You do not arrive at a self-improving operation. You build one that can.

Where most companies actually are

The honest answer is Stage 2, stuck on the way to Stage 3, or Stage 3, stuck on the way to Stage 4. The first plateau is a company that documented its processes during a calmer quarter and never wired numbers to them, so the SOPs slowly drift out of date and the operation quietly slides back toward firefighting. The second plateau is more dangerous because it looks like success: a measured operation with clean dashboards that nonetheless stops the moment the founder goes on holiday, because every real decision still flows through one person.

Both plateaus share a root cause, and it is not a skills problem on the team. It is that climbing a rung requires deliberately building the thing the next stage needs, and that work rarely makes it onto a calendar already full of the current stage's fires. The operation does not lack capability. It lacks the person whose job is to build the next rung.

You cannot skip a stage

The most expensive operations mistake I see is a company reaching for Stage 4 or 5 tooling while standing on Stage 1. Automating a broken, undocumented process does not give you a self-running operation. It gives you a broken process that now fails faster and is harder to inspect. Buying the analytics platform before the metric tree exists gives you dashboards nobody trusts. The order is not bureaucratic caution, it is structural: each stage is the foundation the next one stands on. Document before you measure, measure before you hand off, hand off before you expect the operation to improve itself. Skip a rung and the ladder does not hold weight.

How to find your stage

You find it the same way you find anything true about an operation: you read it, you do not guess it. Sit in the operating meetings, pull the operating data, and look for the tells. Are the same problems recurring (Stage 1)? Do SOPs exist but go unchecked (Stage 2)? Is there a cadence and a metric tree, but every decision still waits for the founder (Stage 3)? The honest read usually lands half a stage lower than the founder expects, because founders grade the operation on its best week and the operation lives in its average one.

That read is exactly what the one-page operating diagnostic produces, and it is the first thing a Plenor engagement delivers. The Operating Teardown names your stage in a week and ranks the gaps between you and the next one. The Bridge Method is how you climb, most often the climb from a documented, measured operation to one that runs itself. If your operation is stuck on a rung and you want an outside operator to name where you are and what unlocks the next stage, that is fractional COO work.