The system isn't broken, it's working exactly as designed.

Friction that keeps coming back usually traces to a system doing exactly what it was built to do. Here's how to see what it's really optimized for before you try to fix it.

Every operator has had some version of this conversation. A process that used to work stops working, and everyone assumes something broke: a step got skipped, a tool failed, someone missed something. So the step gets fixed, the person gets retrained, the tool gets replaced, and the problem is supposed to go away.

Most of the time it moves instead. The team that missed one deadline misses the next, the approval that took three days now takes five, and the handoff that lost one customer's request finds a new way to lose the next. A real fix would make the friction disappear, and this friction keeps turning up elsewhere in the same shape.

The giveaway is simple: one broken step produces one failure, and a pattern that keeps reappearing in different clothes is a system at work, doing exactly what it was built to do.

The system underneath the symptom

Every operation runs on a system, whether or not anyone designed it on purpose, made of who owns which decision, what information moves and what doesn't, what gets measured, and what people are actually rewarded for, which can differ quite a bit from what they're told matters. Nobody writes it down, and it exists anyway, in the accumulated habits of how the work gets done.

Systems are conservative, they protect whatever they're currently optimized for, even when that differs from the outcome everyone wants on paper. A sales team rewarded for closed deals will spend less effort on onboarding, since onboarding never shows up in a commission check, and a support team measured on ticket volume will close tickets quickly before it closes them well, since speed is what gets counted. Both teams are doing exactly what their incentives, ownership, and information tell them to do.

The intended outcome is what leadership wants, and the actual outcome is what the system, as currently built, is set up to produce. When the two drift apart, encouraging people to try harder can't close the gap, because the constraint lives in the structure around them.

Why the patch keeps getting tried

Patches are fast, and looking straight at a system is inconvenient. Retraining someone takes one conversation and replacing a tool takes one purchase order, while changing who owns a decision, what information moves between two teams, or what gets rewarded at review time touches org design, incentives, and habit all at once, which is slower and more uncomfortable and asks someone to say out loud that the current structure is producing the current result, even if nobody meant it to.

So the patch goes in, the symptom fades for a quarter, and then it comes back somewhere slightly different, because the constraint that produced it never moved.

The cost doesn't sit on any one line of the budget, and you can see it everywhere once you look: capacity spent solving the same problem again and again, decisions made without the information that would have sped them up, and teams quietly building workarounds because the official path doesn't hold. Those workarounds are the most honest information a company has about where its systems no longer match its work, since nobody builds a workaround around a step that's working.

Diagnose before you design

The more useful question is what this system is currently optimized to produce, and whether that's the outcome you actually want. Answering it means tracing the result back through ownership, information, and incentives instead of stopping at the first visible failure, and the answer is often uncomfortable, because the system turns out to be succeeding at the wrong thing.

Once that's visible, the intervention looks different from a patch. Sometimes it means moving a decision to the person closest to the information, so it stops traveling three layers up for a signature. Sometimes it means changing what information flows between two teams that have been working from separate pictures of the same customer. Sometimes it includes new workflows, tools, or automation, once the real constraint is clear, because technology aimed at the wrong constraint just makes the wrong thing happen faster.

The order matters more than the tool. Understand how the work actually happens before touching anything, diagnose the system producing today's result before designing what should replace it, and build the intervention the diagnosis calls for instead of the one that happened to be on hand.

What changes when the system changes

Companies that work through this well rarely describe the result as automating something or rolling out a tool, they describe friction disappearing from a place they'd stopped noticing, because they'd built whole workarounds around it. Decisions that took a week start taking a day because the decision moved to the person who already had the information, and handoffs stop losing requests because someone clearly owns the handoff now.

All of that comes from seeing what the system was really built to produce and redesigning it to produce what the business needs. So the next time something in your operation looks broken, it's worth pausing before the obvious fix to ask whether it's actually malfunctioning, or working exactly as it was built, with the build itself being what needs to change.

Back to articles