A few weeks back, I commented on a post about people who inadvertently normalized working around systems they could no longer rely on, and even added automation on top of that.
In my own experience, this is a pattern that keeps recurring at different scales.
When a process or tool fails, someone capable finds a way around it, and the workaround becomes how the work gets done for years afterwards. This is not a problem that arises from scaling alone. Such things can become part of a company’s operating system much earlier.
A workaround gets formed
Consider a report that is needed for an upcoming review. Shortly before the meeting, people find that the numbers in it don’t reconcile. Then, someone who understands the data downloads the report, checks the discrepancies and quickly builds a spreadsheet people can use.
The review goes well. The person who put the spreadsheet together forgets about the issue.
The problem begins when this becomes the expected preparation for every review. The spreadsheet is asked for because the people in the review trust the person who prepared it the last time.
Over subsequent reviews, more people start depending on that one file. Then, someone adds a new chart or table as a new requirement. A new employee learns how to maintain it as part of a handover. Eventually, nobody in the team remembers exactly what was wrong with the original report and why this spreadsheet came into existence.
I have seen such workarounds survive changes in leadership because nobody wanted to risk breaking what was working “just fine”. Fixing the workaround means disturbing several people’s routines. Leaving it alone requires no explanation. What is one employee’s additional hour spent on cleanup compared to that peace of mind? There is another problem here that most people won’t think of. Once a person becomes the workaround, they often end up being expected to fix any problem in that process too.
As long as the work gets done
The management only sees a report that arrives when it is needed. The people who make this possible develop a reputation for being dependable and resourceful.
What is harder to see is how much dependence gets created on these people as a result of their resourcefulness. In fact, such people can become so effective at working around failures that the extent of those failures remains hidden. And the root cause remains unaddressed.
Automating the workaround
Eventually, someone notices the manual effort and proposes automation as a solution. On the face of it, this might make sense. After all, when people spend hours assembling a report periodically, automation can save a lot of time, especially with AI thrown into the mix.
However, the more important question to ask is why the report needs to be assembled this way. Perhaps two teams use different definitions for the same metric. Perhaps the data being entered in the system is incomplete or even inaccurate. Perhaps the original report never answered the questions raised in the review.
Automation might reduce the effort involved in collating and cleaning up the data. The organization could still end up spending money maintaining something that should never have been needed in the first place.
There will be cases where automating a workaround is a practical interim choice. That choice should include an explicit understanding of the unresolved issues and a timeline for resolution.
Process before tools
Many of these problems begin with the original tool selection. A company invests in a platform and then finds out that key data isn’t captured in it. People adapt their process to the tool’s constraints, find somewhere else to record the missing information, and learn to live with the extra steps. This is why getting the process nailed down before getting a tool is important. We need to understand the flow of work before deciding which tool should support it.
There will be defensible exceptions now and then. An existing process can be updated because a tool offers a better or easier way of working. The important thing is that we should be able to explain why adopting that change improves the process, including what happens to requirements the tool cannot accommodate.
The cost of keeping a workaround
The nature of the workaround matters a lot here and influences how long it can survive. A spreadsheet can be put together in a couple of hours. The continued effort needed to keep it going then gets absorbed into someone’s workload, often without anyone questioning whether that is a reasonable use of their time.
In manufacturing, the cost can be much harder to justify. A process workaround might require an additional part, a new inspection step, extra handling or a complete rework of a process step. And in some cases, the workaround might become the new process. But that should happen only after considering the effort needed to introduce it, the cost of continuing it, and the cost and disruption involved in correcting the underlying problem.
Making the correction
Toyota’s description of its production system is useful here. It explains the need to understand and improve work done by hand before replacing those operations with machines. The principle is relevant well beyond the factory floor.
If you are grappling with a single or multiple workarounds in any process at your organization, start with one recurring workaround and first have a discussion with the people who use it. Gain a thorough understanding of the process end to end before trying to figure out where they intervene and why. There are many ways to do this and each situation might warrant a different approach. Without this step, removing the workaround or modifying it further could create problems elsewhere.
Once the actual causes for the workarounds are identified and the impact assessed holistically, then you can decide to correct the original process or adopt the workaround with tweaks as a better way of doing the work. Either decision needs to account for the effort involved and the impact on everyone who depends on the output.
More importantly, all the impacted teams need to understand the proposed change and have their concerns addressed before the person accountable for the process makes the decision. If you choose to defer the correction, every stakeholder needs to be clear about the cost they are accepting and when they need to revisit it.
Process is not a choice. Simplicity is.
Organizations run on processes, regardless of how people feel about it. Even a single person business runs on processes. They are the nervous system of the organization. Whether the system runs seamlessly with just the right set of processes or gets bogged down by processes for the sake of structure and power games, or worse, completely goes off the rails with no controls in place, is entirely up to what the people inside are willing to fix and what they are willing to live with.
What workaround has become part of everyday work in your organization? I would be interested to hear how it came to be and why it is still around.