Why Most Organizations Don't Have an Operations Problem — They Have a Systems Problem

Most organizations that think they have an operations problem don’t. What they actually have is a systems problem wearing an operations costume.

The symptoms look like people problems: someone dropped the ball, a deadline slipped, a manager had to chase three people for one answer. So the instinct is to fix the person — more training, more meetings, more reminders. But if the same kind of breakdown keeps happening with different people in the same role, the person was never the variable. The system around them was.

01 — The Hidden Operations Problem

The symptoms are usually quiet, not dramatic. Nobody declares “our operations are broken.” Instead:

Information about the same piece of work lives in three different places — a chat thread, a spreadsheet, someone’s memory — and none of them fully agrees with the others.
Ownership is technically assigned but practically diffuse: three people could plausibly be “responsible,” which in practice means none of them feels fully responsible.
Reporting is fragmented — a status update exists, but it’s a snapshot someone had to reconstruct by asking around, not something the system already knew.
A manager has to follow up to find out what’s happening, rather than being able to look and see it.
Decisions get made reactively, in response to something that already went wrong, instead of from visibility into something that was starting to go wrong.

None of this is a crisis on any given day. That’s exactly why it survives — every individual instance is small enough to route around, so the underlying pattern never gets named. It just quietly sets a ceiling on how much the organization can grow before the same friction gets more expensive.

The tell is usually a sentence, not a metric: “let me check and get back to you,” said by someone who should already know. Said once, it’s nothing. Said as the default answer to routine questions about routine work, it’s a symptom — the organization has no reliable way to know its own current state, so every question has to be answered by going and looking.

02 — People Are Not the System

Here’s the distinction that matters: people execute systems. People should not have to become the system.

When there’s no real operating structure, capable people compensate for it — they remember what the spreadsheet doesn’t track, they follow up because nothing else will, they hold context that should live somewhere durable instead of in one person’s head. It works, for a while, and it looks like competence. But it’s fragile: it depends on specific individuals being available, attentive, and willing to keep absorbing that cost. The moment one of them is out sick, distracted, or gone, the gap they were quietly filling becomes visible all at once.

That’s not a hiring problem. It’s a design problem. The fix isn’t finding more people willing to be the glue — it’s building a structure that doesn’t need glue in the first place.

03 — The Five Layers of an Operating System

I think about an operating system as five layers, each one depending on the one before it:

Structure. Who owns what, and where does one person’s responsibility end and another’s begin. Without this, work has no clear home — it gets picked up by whoever notices it, which means it sometimes doesn’t get picked up at all.

Process. The repeatable way a given piece of work actually happens, written down clearly enough that it doesn’t depend on one person’s memory of how it went last time.

Visibility. Whether the current state of the work is something anyone can see, rather than something they have to ask about. A status that lives only in someone’s head isn’t visibility — it’s a bottleneck with a friendly face.

Accountability. Not blame — a clear, standing answer to “whose job was this, and did it happen.” Accountability without visibility is just an argument waiting to happen; visibility without accountability is a dashboard nobody acts on.

Improvement. The mechanism by which the system gets better from what actually happened, instead of staying frozen at whatever version got set up first. A process that can’t be revised based on real information isn’t a system — it’s a habit.

Skip any one of these and the whole thing tends to collapse back onto people compensating for the gap. Structure without process just tells you who to blame when nothing’s written down. Visibility without accountability produces a report nobody reads twice.

04 — From Activity to Control

There’s a real difference between people doing work and management having actual visibility and control over how that work is progressing — and it’s easy to mistake one for the other.

Activity is the day-to-day motion: tasks getting done, messages going back and forth, things technically happening. Control is something else: it’s being able to look at the state of a process — right now, without asking anyone — and know honestly where it stands, what’s at risk, and what needs attention next.

An organization can be extremely busy and have almost no control. That’s usually the moment someone senior starts asking, half to themselves, “wait, how is this actually going?” — not because people stopped working, but because the system never gave anyone a way to see it without interrupting the people doing it.

05 — What I Learned From Building Operational Systems

This isn’t theoretical for me. It’s the pattern I keep running into directly while building real operational systems — a daily site reporting system, a project operations framework, a material request workflow, and a portfolio-level operations dashboard.

Each of those started from the same underlying complaint, phrased differently depending on who raised it: reports that had to be manually reassembled before anyone could answer a simple question, requests that existed only as a message with no trail from “asked for” to “delivered,” day-to-day site activity that never made it into a form management could actually see, and no single place that showed how an entire portfolio of active work was actually doing at once.

None of these were people problems. The people involved were doing their jobs. What was missing was the structure around the work — a defined owner, a repeatable process, a way for status to be visible without someone reconstructing it by hand. Building each system meant designing that structure first, then making the tool that captured it. I’m not going to attach invented numbers to any of this — some of that work is still building the evidence trail, some of it involves information I can’t share publicly — but the shape of the problem was consistent every time: fragmented information, unclear ownership, and a management layer forced into follow-up mode instead of visibility mode.

What struck me building these was how similar the underlying diagnosis was, even though the surface work looked completely different — a dashboard pulling together a portfolio of active projects has almost nothing in common, mechanically, with a form for requesting materials on a site. But both were solving the same actual problem: someone needed a straight answer to a routine question, and getting it required reconstructing information that should have already existed in one place. Once that’s the real diagnosis, the specific tool matters less than getting the structure right first.

06 — The Goal Is Not More Process

It’s worth saying directly: a good operating system should reduce friction for management, not add bureaucracy on top of the work. If a new process makes people spend more time reporting on work than doing it, that’s not an operating system — it’s overhead with good intentions.

The test isn’t “did we add a process.” It’s “did the process make the work easier to see and easier to run, with less follow-up required to know what’s going on.” A system that adds five steps to save someone thirty seconds of asking a question has the priorities backwards.

07 — A Practical Test

If you want to know whether an organization has a real operating system or is running on people compensating for the absence of one, five questions are usually enough:

Can management see what is happening, without asking someone directly?
Does every critical process have one clear owner — not “the team,” a person?
Can the work continue if one key person is unavailable for a week?
Are problems visible early, while they’re still small, or only once they’ve already caused a delay?
Can the process actually improve based on real information about how it’s been running — or is it frozen at whatever version got set up first?

A confident “yes” to all five is rare. Most organizations will find at least one or two of these genuinely uncomfortable to answer — and that discomfort is usually pointing at exactly where the real work is.

Where this leaves the work

Organizations don’t get easier to scale by finding more disciplined people. They get easier to scale when the way work actually happens becomes clearer, more visible, and more repeatable — when the system carries the weight instead of the people inside it.

That’s the lens I bring to operations work: not task management, not headcount, but system design — structure, process, visibility, accountability, and a real mechanism for improvement, in that order.