Written by: David Carneal – Digital Efficiency Consulting Group – DECG
Read Time: 3 min
Workflow failure rarely arrives with thunder, sirens, and a committee named Project Phoenix. More often it arrives as a sentence nobody thinks is unusual anymore.
Just email Maria. You have to enter that twice. Sales handles those differently. That report is not always right. Accounting has to release those manually. Sometimes the warehouse does not see the change.
Those phrases are workflow gremlins. Small pieces of friction the organization has adapted to so completely that they no longer register as problems.
Adaptation can hide the cost
People are very good at making imperfect systems work. They build side spreadsheets, remember unwritten rules, send a quick message to the person who knows the shortcut, and manually reconcile what two systems disagree about. That resourcefulness is valuable. It is also camouflage.
When a workaround succeeds every day, leadership may never see the failure it is compensating for. The order ships. The customer is happy. The report gets finished. Somewhere underneath that outcome, an experienced employee may have spent thirty minutes stitching the workflow back together.
The gremlin test
Listen for language that suggests the official process and the practical process have separated. Then ask a second question: how often does this happen? A one-off workaround may be reasonable. A workaround performed fifty times a week is a process.
- "Just send it to me" often signals unclear routing or ownership.
- "Enter it in both places" points to disconnected systems or redundant controls.
- "I keep my own tracker" suggests the official system is not trusted or does not provide needed visibility.
- "We always override that" may mean an old rule is generating work without reducing current risk.
- "Only Jordan knows how" identifies a tribal-knowledge dependency and continuity risk.
Do not automate the gremlin
A common response is to buy technology or automate the manual step. Sometimes that is exactly right. Sometimes it simply turns an unnecessary step into a faster unnecessary step.
Before automating, ask why the step exists. Is it required by the customer? Does it protect a real risk? Is it correcting bad information from upstream? Was it introduced years ago after a problem that no longer exists? If nobody can explain the purpose, you have earned the right to investigate before you code.
A 15-minute gremlin hunt
- Pick one workflow and ask employees for the five phrases they repeat when the normal process does not work.
- Estimate how often each workaround occurs in a week.
- Multiply frequency by the minutes required to perform or recover from it.
- Identify which gremlin creates rework, delay, risk, or customer confusion downstream.
- Fix one small source of friction before launching a grand transformation.
That last step matters. A gremlin does not require a dragon-slaying budget. Often the useful improvement is a cleaner input, a retired rule, a clearer ownership point, or one reliable system of record.
CTA: Ask your team one question today: What workaround do we use so often that nobody calls it a workaround anymore? Start there. The gremlin will probably introduce itself.