the cost of the workaround

Every workaround adds distance, not destination.

Every business has at least one. The extra approval someone insists on because a mistake happened once, two years ago. The manual reconciliation nobody’s automated because “the system doesn’t quite handle it.” The specific person everyone routes a certain request through, because that’s simply how it’s always been done. Ask why, and the answer is rarely a good one — it’s usually some version of “that’s just how we do it here.”

Individually, each of these looks harmless, even sensible. Collectively, they’re a permanent, invisible tax on the operation — and because no single workaround looks big enough to fix, almost nobody ever adds them up.

Why workarounds are so easy to accumulate

A workaround is rarely created carelessly. It usually starts as a genuinely reasonable response to a specific problem — a process broke once, so someone built a manual check around it; a system couldn’t handle an edge case, so someone built a spreadsheet to cover the gap. At the moment of creation, every workaround is solving a real problem cheaply and quickly.

The trouble is what happens next: almost nothing. The original problem that justified the workaround often gets fixed, or stops occurring, or the person who created it moves on — but the workaround itself rarely gets removed. It’s easier to leave a small manual step in place than to revisit why it exists, confirm it’s no longer needed, and formally remove it. So workarounds accumulate the way sediment does: slowly, quietly, and without anyone deciding it should happen.

The compounding cost nobody sees on a single day

On any given day, a workaround costs almost nothing. Someone spends ten extra minutes on a manual step, or a request takes one extra day because it has to pass through a specific person’s desk. That’s genuinely not worth fixing on its own — which is exactly why it never gets fixed.

But operations don’t run for one day. They run for years, at volume. Ten minutes, multiplied by every transaction, every week, for years, is not ten minutes anymore. And the cost isn’t only time. Every manual step is a place where the process depends on a specific person’s memory or attention rather than a defined system — which means it’s also a place where errors quietly creep in, where onboarding a new employee takes longer because nothing is actually written down, and where the business becomes fragile to exactly the kind of disruption that shouldn’t matter: one person being on leave, one spreadsheet being on the wrong laptop.

Why workarounds resist being questioned

Workarounds have a strange kind of institutional protection that formal processes don’t. Because they were never officially designed, nobody formally owns them — which means nobody is quite the right person to challenge them either. Suggesting a workaround be removed can feel like criticising the person who built it, even when that person would happily agree it’s outdated. And because the workaround genuinely does solve something, however inefficiently, removing it without understanding exactly what it’s covering for carries a real risk of breaking something nobody remembers is fragile.

This is precisely why workarounds tend to survive audits and process reviews that would catch almost anything else. A formal process gets scrutinised because it’s visible and documented. A workaround, by definition, exists in the gaps — informal, undocumented, and easy to simply not mention when someone asks “walk me through how this actually works.”

How to actually find and remove them

The fix isn’t a single sweeping process redesign — that tends to miss exactly the informal layer where workarounds live, because a redesign usually documents what the process is supposed to be, not what people actually do to make it function. Finding workarounds requires a more specific kind of listening.

Ask the people doing the work, not the people who designed the process. The person managing the process on paper often doesn’t know about the manual step someone quietly added to make it function. The people executing it every day know exactly where the friction is, because they’re the ones absorbing it.

Look for anything that depends on a specific person rather than a defined rule. “Ask Ramesh” is the single most reliable signal of an unaddressed workaround. If a process only works because one particular person remembers how to handle an exception, that’s not resilience — it’s a single point of failure wearing a familiar face.

For each workaround found, ask what it was originally solving — and whether that’s still true. Some workarounds are still genuinely necessary; the underlying gap they cover hasn’t actually closed. Others were solving a problem that no longer exists. The distinction only becomes clear once someone actually asks the question, which is rarer than it should be.

Fix the underlying gap, not just the symptom. Removing a workaround without addressing whatever originally caused it just recreates the same problem, and probably a new workaround along with it. The goal isn’t to delete the patch. It’s to make the patch unnecessary.

What this is really about

None of this is about blaming anyone for building a workaround in the first place — every one of them was a reasonable response to a real problem at the time. The issue is only that nobody ever goes back to check whether the reason still holds. A business that periodically asks that question stays lean. A business that never does slowly accumulates an invisible layer of friction that eventually shows up as slower operations, harder onboarding, and a process that only a handful of long-tenured people actually understand — which is its own kind of fragility, quietly built one small shortcut at a time.


If parts of your operation only work because one person remembers how, that’s a workaround worth surfacing before it becomes a dependency. See how our Operations & Supply Chain practice works →