The short answer

A COO operating system is the small set of decision rights, operating cadences, shared measures, and feedback loops that turns strategy into coordinated action. It should make priorities visible, expose trade-offs early, and move reliable information between customers, product, engineering, quality, support, sales, and finance.

Key takeaways

  • Design around value streams and decisions, not the organizational chart.
  • Use one portfolio language from customer problem through adoption and renewal.
  • Separate the cadence for running the business from the cadence for changing it.
  • Measure outcomes, flow, reliability, and learning together; no single metric is sufficient.

Start with the five loops the company must close

An operating model is useful only if it closes the loops that determine performance. In enterprise software, five loops matter most: customer signal to portfolio choice; portfolio choice to delivered capability; release to adoption; service reliability to investment; and learning to operating change.

Each loop needs an owner, a decision, a clock, and evidence. If a customer request enters a backlog but never meets an explicit portfolio decision, the loop is open. If a release ships but adoption and support signals never influence the next decision, the loop is open. Open loops are where activity multiplies while confidence declines.

  • Signal loop: What customer or market evidence changed?
  • Portfolio loop: Which problem deserves scarce capacity, and why now?
  • Delivery loop: What is the smallest coherent outcome we can validate?
  • Reliability loop: What level of operational risk are we accepting?
  • Learning loop: What will we change because of what we observed?

Make decision rights explicit

Cross-functional work slows down when everyone can contribute but nobody knows who decides. A useful decision-rights model distinguishes the person who frames the choice, the people who provide evidence, the person who commits the organization, and the people who execute. The names matter less than the clarity.

Portfolio decisions should include the customer problem, expected business effect, capacity implication, principal risk, and the date the decision will be revisited. That turns a roadmap from a list of promises into a set of testable choices. It also gives commercial teams an honest language for discussing confidence without pretending uncertainty does not exist.

Use different clocks for different work

A company needs a fast clock for operating signals, a medium clock for portfolio and capacity choices, and a slower clock for strategy. For many organizations, that means a weekly operating review, a monthly portfolio review, and a quarterly strategy refresh. The exact intervals should follow the speed at which evidence changes, not a fashionable calendar.

The weekly review should be an exception-and-decision forum, not a tour of status slides. The monthly review should reconcile customer evidence, delivery confidence, quality, capacity, and commercial implications. The quarterly discussion should decide which assumptions still hold and where the company will stop investing. Every forum needs a written purpose and an explicit list of decisions it can make.

Build one measurement spine

The measurement system should connect business outcomes to product adoption, delivery flow, service health, and organizational capacity. DORA's delivery measures are useful because speed and stability are considered together. They are not, by themselves, a company scorecard. Customer value, unit economics, reliability, and learning still need to be visible.

The SPACE framework offers another important guardrail: developer productivity cannot be represented by one number. Satisfaction, performance, activity, communication, and flow describe different dimensions. The same logic applies at company level. A balanced operating review asks whether the system is producing value sustainably, not whether one local metric is green.

Keep the operating system intentionally small

Process accretes when a painful event produces a permanent ceremony, template, or approval. Over time, the company pays for every old lesson on every new piece of work. A healthy operating system includes deletion: each recurring forum has an owner, a decision purpose, and an expiry or review date.

The test is simple. Can a leader explain the company's top choices, current constraints, material risks, and next decisions from the same evidence used by teams doing the work? If yes, the system is creating alignment. If those answers require a separate executive reporting layer, the information architecture is probably broken.

A practical implementation sequence

Begin by mapping the five loops and finding where decisions wait, evidence is translated repeatedly, or commitments escape the system. Define the minimum decision record, assign decision rights, and establish the smallest cadence that can close the important loops. Only then choose tooling.

The COO's aim is not maximum control. It is a company that can sense reality, make coherent choices, deliver with confidence, and learn quickly. The best operating system becomes quieter as it matures because shared context replaces escalation.

Sources & further reading