Software Doesn't Fix Broken Processes
Buying a tool to fix a broken workflow does not fix it — it encodes the brokenness, speeds it up, and makes it permanent. What we have learned automating other people's operations.
I build software and systems for a living, so this is going to sound like I am arguing against my own work: software does not fix broken processes. It never has. When a team is drowning, the instinct is to buy a tool. But a tool applied to a broken process does not repair it — it automates it, accelerates it, and makes it much harder to change later.
I have watched companies spend serious money to digitize a workflow that should not have existed at all, and then wonder why the new system feels exactly as painful as the old one. It feels that way because it is the same process, just faster.
Why the conventional wisdom is wrong
The conventional wisdom treats software as a solution you can buy. Operations are messy, so you purchase a platform, and the platform is supposed to impose order. But software does not impose order — it imposes structure on whatever you already do. If what you already do is incoherent, the software faithfully encodes the incoherence. You end up with a well-engineered version of a bad idea.
A clunky manual approval chain becomes a clunky automated one, now with permissions, logins, and no way to use judgment.
Work that survived on informal exceptions breaks, because the new system does not allow the exceptions that kept it functioning.
The hidden cost of the broken process is now locked into a contract, an integration, and a year of training.
What is actually true
What is actually true is that software is an amplifier, not a fix. It makes a good process faster and a bad process worse, because it removes the human friction that was quietly compensating for the design flaws. The people working a broken process are usually patching it in real time with judgment, workarounds, and favors. Automate it without redesigning it and you remove the patches while keeping the flaw — the worst of both worlds.
The order of operations matters. Fix the process on paper first, where changes are free and reversible. Then — and only then — encode the fixed process in software. Doing it the other way around means paying to make your mistakes permanent.
How to tell the difference
Before you buy anything, ask whether you are automating a process you would be proud to map out for a new hire.
Can you draw the current process on one page? If not, you are not ready to automate it — you do not understand it yet.
Would the process make sense to someone seeing it for the first time, or does it only survive because veterans know the workarounds?
If you removed the tool entirely, would the underlying logic still be sound? If the logic is broken, the tool will not save it.
What we see at TTGC
When a client asks us to build software for an operation, the first thing we do is refuse to build it yet. We map the current process and almost always find steps that exist only because someone added them years ago, approvals that approve nothing, and handoffs that exist to cover for a missing decision. If we automated that as-is, we would deliver a fast, expensive monument to dysfunction. So we redesign first, cut what should not exist, and only then build. Clients sometimes push back — they came for a tool, not a process audit. But the ones who let us fix the workflow first end up with systems they actually trust, while the ones who insisted on automating the mess first usually come back to rebuild it. Software is the last step of fixing a process, not the first.
The honest take
If your operation is broken, do not start by shopping for software. Start by fixing the process where it is cheap to fix — on a whiteboard. Cut the dead steps, resolve the missing decisions, and get to a workflow you would be willing to explain to a stranger. Then automate that. Buy software to make a good process faster, never to make a bad process disappear. It will not disappear. It will just run at scale.
Sources
McKinsey & Company — research on technology adoption and why digital tools fail to deliver value without process change. mckinsey.com
TTGC — patterns across client transformation work.
