The most expensive technology problem is not always a failed system.
Sometimes it is a system that technically works—but the people doing the work do not trust it.
That is when a team starts paying twice.
You pay once for the platform, and again for the shadow process people build around it.
Imagine a Service Desk with a modern ticketing platform. It records incidents, routes assignments, measures service levels, and feeds management dashboards. On paper, the operation is fully enabled.
In practice, agents keep a separate spreadsheet.
The official tool takes too many clicks. Mandatory fields do not match the conversation with the customer. Assignment rules send tickets to the wrong queue. Knowledge articles are difficult to find. A ticket can look complete while still missing the one detail the resolver team actually needs.
So the spreadsheet becomes the real operating system.
Agents record callbacks there. Team leads track priority customers there. Remote Support adds troubleshooting notes in another shared file. Managers use the ticketing data for reporting, but use the spreadsheet when they need to know what is actually happening.
Now every update must be entered twice. Sometimes it is. Sometimes it is not.
The customer calls back and hears that the ticket is waiting for information, even though they provided it an hour ago. A major incident begins as five apparently unrelated tickets because the meaningful pattern lives outside the platform. Service-level reports remain green because workarounds and off-system activity are invisible.
The tool has not eliminated the work. It has split reality into two versions.
When the official system and the real work disagree, management usually receives the cleaner version—not the truer one.
This is why Technology & Tools is a management system, not an IT purchasing category.
A tool should reinforce the process, make the right behaviour easier, preserve the evidence needed for decisions, and reduce operational friction. If it does not, people will compensate. Good employees are remarkably creative that way. Unfortunately, their workaround can make a broken design look functional for years.
The wrong management response is to issue another reminder: “Please use the tool correctly.”
The better response is to examine why capable people believe the sanctioned path prevents them from doing capable work.
That does not mean every complaint deserves a customization. Some controls exist for good reasons. But leaders should observe the work end to end: where people leave the system, what they record elsewhere, which fields they avoid, where information is rekeyed, and which reports nobody trusts.
Then decide deliberately. Simplify the workflow. Improve the configuration. Integrate the missing step. Retire the unnecessary control. Train the team where the problem is understanding. And where a workaround must remain, govern it instead of pretending it does not exist.
Technology creates leverage only when the operating model and the tool tell people to work in the same way.
If your team keeps a second system “just to make sure,” you do not have one platform with a backup.
You have two operating models—and you are paying for both.
If this tension between tools, processes, and day-to-day execution feels familiar, I explore the practical management systems behind it in The 7 Essential First-Line Management Systems. You can find the book at www.imadlodhi.com/flm1.
