Every organization has workarounds. A spreadsheet someone created because the system doesn't quite do what the business needs. A service that gets restarted every Monday morning. A report that requires someone to manually combine data from three different systems. A support team that knows exactly what to tell users when a particular error appears. A Product team that has learned not to touch a certain part of the application because "it's always been temperamental."
Individually, none of these things seem particularly alarming. Sometimes a workaround is exactly what you need. Something breaks, the business needs to keep moving, and smart people figure out another way to get the job done. That's a good thing.
The problem starts when nobody comes back and asks: Why are we still doing it this way?
Temporary Has a Way of Becoming Permanent
I've seen this happen countless times throughout my career. Someone creates a temporary process because a system can't handle something. It works. Six months later, people are still doing it. A year later, it's documented. Two years later, a new employee is trained on it.
Eventually, nobody remembers why the workaround exists. It's simply part of the job. And then someone suggests changing it.
The response? "We've always done it this way."
That's when technical debt becomes operational debt. We've taken something that was originally intended to get us through a problem and quietly turned it into a permanent business process.
The Spreadsheet Isn't Necessarily the Problem
Spreadsheets are a great example. I've heard plenty of technology people complain about businesses running important processes through Excel. But Excel isn't necessarily the problem.
The interesting question is: Why did someone need to create the spreadsheet?
Maybe the application didn't provide the information they needed. Maybe two systems couldn't communicate. Maybe the official process took 20 steps and someone figured out how to accomplish the same thing in five. Maybe Product never understood how people actually used the system.
That spreadsheet may be telling you something important. Instead of immediately asking, "How do we get rid of this spreadsheet?" we should probably ask: "What problem did this spreadsheet solve?"
That's a very different conversation.
Your Users Are Often Designing Solutions for You
People are remarkably good at adapting. Give someone a difficult process and eventually they'll figure out an easier way to do it. They'll build spreadsheets, create templates, copy information between systems, develop shortcuts, write instructions for each other, and even learn which buttons they're not supposed to click.
From an IT or Product perspective, it's easy to look at these behaviors and say users aren't following the process. Sometimes that's true.
But sometimes users are telling us something much more valuable: The process isn't following the business.
Those workarounds can become some of the best requirements gathering you'll ever do. Instead of asking users what feature they want next, watch what they're already doing outside the system. There's usually a reason.
The Cost Is Bigger Than the Extra Steps
A workaround that takes five extra minutes doesn't sound particularly serious. But multiply those five minutes across 50 employees, several times a week, for several years. Now it starts getting expensive.
And labor isn't the only cost. Manual processes introduce mistakes. Spreadsheets create multiple versions of the truth. Tribal knowledge creates dependencies on particular employees. Repeated system problems consume support resources. Temporary integrations become permanent architecture.
Eventually, the organization spends a surprising amount of time and money maintaining things nobody intentionally designed. That's the hidden cost of accepting friction as normal.
This Is Where Leadership Matters
Technology and Product leaders shouldn't eliminate every workaround. That's neither practical nor necessary. The job is to recognize which workarounds are telling us something about the health of the organization.
When I see a recurring manual process, support ticket, production incident, or customer complaint, I start asking questions: Why does this exist? How often does it happen? How many people are affected? What does it cost us? What would have to change to eliminate it?
And perhaps the most important question: If we were designing this process today, would we intentionally design it this way?
If the answer is no, then "we've always done it this way" probably isn't a very good reason to keep doing it.
Workarounds Are Useful. Until They're Not.
There will always be temporary fixes, and there should be. Businesses can't stop every time tech
Thanks,
Michael Cronin
Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/
