When to Stop Patching and Start Redesigning

Every business accumulates workarounds. A manual step inserted because two systems don't talk to each other. A spreadsheet that bridges a gap between what the CRM tracks and what the team actually needs. A process that technically works, but only because one person knows exactly where to click and in what order.

These aren't signs of failure. They're signs of a business that kept moving when things weren't perfect — which is almost always the right instinct in the moment.

The problem isn't that workarounds exist. It's that they tend to quietly shift from temporary fixes into permanent infrastructure. And once that happens, the business starts adapting to its own patches rather than the other way around.

If you've followed along from Making Invisible Workflows Visible and Mapping Your Business Without Overengineering It, you've already built the foundation: you can see how work actually moves through the business, and you've captured it in a format that stays current. The question now is what to do with what you see — specifically, when a workaround is fine to leave in place and when it's telling you something needs to change.

How workarounds accumulate

Workarounds rarely arrive as conscious decisions. They emerge from a reasonable response to a constraint: a tool doesn't do quite what you need, a process doesn't account for an edge case, or a handoff between teams has a gap that someone fills manually.

In the moment, the patch makes sense. It's faster than redesigning the process. It costs nothing to implement. And it works.

The accumulation happens because each workaround is small enough to seem insignificant on its own. Nobody raises a flag over an extra copy-paste step or a quick check in a separate spreadsheet. These things just become part of how the work gets done.

Over months and years, a business can end up carrying dozens of these small compensations — each one rational in isolation, but collectively creating a web of dependencies that nobody fully sees.

This is normal. It's worth naming that clearly, because the instinct is often to feel embarrassed about it. There's nothing to be embarrassed about. Every business that has grown beyond its initial setup carries this kind of accumulated adaptation.

When patching becomes structural

There's a meaningful difference between a workaround that compensates for a known limitation and one that has become load-bearing.

A temporary patch is something the team is aware of and could describe as a compromise. A structural one is something the team has stopped noticing — it's just "how we do things."

A few indicators that patching has moved from temporary to structural:

The workaround has its own workarounds. When a patch requires additional steps to function — or when people have developed tricks to make the patch itself more reliable — you're looking at something that has embedded itself into the workflow.
New processes are designed around the limitation. Instead of questioning why a step exists, new team members are trained on it as if it were intentional. The patch has become part of the official process.
Removing it feels risky even though it was never meant to be permanent. When people are reluctant to change something that was supposed to be temporary, it's usually because other things now depend on it in ways that aren't fully understood.
The same friction appears in multiple places. A single workaround in one workflow is a patch. The same kind of workaround appearing across several workflows is a pattern — and patterns point to something more fundamental.
Decisions are being shaped by the patch, not by business need. When the answer to "why do we do it this way?" is essentially "because the spreadsheet requires it" or "because the system can't handle it otherwise," the tool limitation has started directing the business.

None of these are emergencies. But they are signals that the relationship between the business and its systems has shifted.

The cost of not deciding

The risk of accumulated workarounds isn't usually a dramatic failure. It's drift.

Drift looks like this: the business gradually orients itself around its own limitations. Decisions that should be driven by strategy get filtered through operational constraints. Teams spend more time maintaining patches than doing the work the patches were supposed to support. New opportunities get evaluated not on their merits but on whether the existing systems can accommodate them.

This is hard to see from inside the business because it happens incrementally. There's no single moment where things go wrong. Instead, there's a slow narrowing of what feels possible — not because of the market or the team's capability, but because of accumulated operational weight.

The cost isn't usually financial in the obvious sense. It's in time spent on coordination that shouldn't be necessary. It's in the ideas that never get pursued because the operational overhead of change feels too high. It's in the gradual erosion of a team's confidence that things can actually get better.

A framework for evaluating: patch or redesign

Not every workaround needs to be redesigned. Some patches are perfectly fine to leave in place indefinitely. The goal isn't to eliminate all workarounds — it's to make conscious decisions about which ones to keep and which ones to address.

When you're looking at a specific friction point, a few questions help clarify whether patching or redesigning is the appropriate response:

How many people does this affect? A workaround that one person manages once a week is very different from one that an entire team encounters daily. The broader the impact, the more the cumulative cost matters.

Is the frequency increasing or stable? A patch that handles a rare edge case is usually fine to keep. One that's being triggered more often as the business grows is a candidate for redesign — because growth will only make it worse.

What breaks if the person who manages this leaves? If a workaround depends on one person's knowledge and there's no documentation or transferability, it's a single point of failure regardless of how well it functions today.

Does this constrain decisions beyond its own scope? Some workarounds stay contained. Others influence how adjacent processes work, what tools get adopted, or what the team believes is feasible. The more a patch shapes decisions in other areas, the more it warrants attention.

What would the redesign actually involve? Sometimes the fix is smaller than expected — a configuration change, a simple integration, a minor process adjustment. Other times it's genuinely large. Knowing the rough scope matters before deciding.

When patching is fine

Patching gets a bad reputation, but it's often the correct choice. A few scenarios where leaving a workaround in place is reasonable:

The friction is minor and stable — it doesn't get worse as the business grows
The cost of redesigning significantly outweighs the ongoing cost of the patch
The area is likely to change again soon, making a permanent fix premature
The team is aware of the workaround and can manage it without undue effort
There are higher-priority areas where time and attention would create more value

Choosing to keep a patch isn't the same as ignoring it. The difference is awareness. A conscious decision to leave something in place — documented, understood, and periodically revisited — is fundamentally different from a workaround that nobody has examined in two years.

When it's time to act

Redesign becomes the right call when the cost of maintaining the status quo has started to exceed the cost of change — not in a dramatic sense, but in a practical one.

A few situations where redesign is usually worth pursuing:

Multiple workarounds point to the same root cause. If you're patching the same underlying limitation in several places, addressing the root issue once will resolve several friction points at once.
The workaround is blocking growth. When the business can't take on new work, serve new customers, or adopt new practices because existing systems can't accommodate them, the patch has become a constraint on the business itself.
Maintenance cost is accelerating. A patch that took five minutes a week last year but takes an hour a week now is on a trajectory that won't improve on its own.
The team has lost confidence in the process. When people start treating a workflow as fundamentally broken rather than temporarily imperfect, morale and quality both suffer. That sentiment is a signal worth taking seriously.

When you do decide to redesign, the workflow maps from earlier in this series become genuinely useful. You're not guessing at how things work or starting from a blank slate. You have a current picture of the actual workflow, created by the people who do the work, and you can use it to identify exactly where the redesign needs to happen — and, just as importantly, where it doesn't.

Incremental redesign over wholesale replacement

One more thing worth naming: redesign doesn't have to mean replacing everything at once.

In most cases, the most effective approach is incremental. Address the highest-impact friction point first. Let the team adjust. Evaluate. Then decide whether the next layer needs attention or whether the remaining patches are now acceptable.

This avoids the common trap of launching a massive systems overhaul that introduces its own set of problems — new tools nobody knows how to use, processes that look clean on paper but don't match how work actually flows, and a team that's exhausted from the change itself.

Small, deliberate changes — informed by clear visibility into how the business actually operates — tend to produce better outcomes than ambitious transformations. Not always. But more often than most businesses expect.

The goal isn't a perfect system. It's a system that evolves intentionally alongside the business it supports.