A team invests in a new digital system to make work easier.
The software promises better organization, fewer mistakes, and smoother collaboration. Employees receive training. The system goes live.
Then, a few weeks later, something interesting happens.
Someone creates a spreadsheet.
Another employee starts keeping a separate list of pending tasks. A supervisor asks colleagues to send updates by email because the dashboard doesn't show everything needed for the morning meeting.
Soon, the organization has two ways of managing the same work: the official system and the informal processes that have developed around it.
The instinctive response might be to blame poor adoption, inadequate training, or employees who resist change.
But there is another possibility worth investigating:
What if the workaround is telling us something important about the system itself?
The scenario above is illustrative, not an account of a particular organization.
The difference between how work is designed and how work actually happens
Organizations often purchase technology based on how they expect a process to function.
A request comes in. Information is recorded. Someone reviews it. The next person receives it. The task is completed.
On paper, the workflow looks straightforward.
In reality, work rarely follows such a perfectly predictable sequence.
An urgent request may need to bypass a normal queue. A decision may depend on information stored in another department. An employee may need to track a deadline that the software does not clearly display.
These details matter because the process described in a software specification is not always the process experienced by the people doing the work.
Research into information-system workarounds supports taking these differences seriously.
A published case study of an electronic medication administration system examined how users responded when the technology did not fully fit existing work processes. It found that different responses to system limitations could have different effects on the system's benefits and effectiveness.
Another study examining documentation and collaboration in a clinical advisory center investigated workarounds within an informal, or shadow, information system.
These studies are situated in healthcare, so their findings should not automatically be generalized to every industry. Nevertheless, they illustrate an important principle: people sometimes adapt their work around technology, and those adaptations deserve investigation rather than immediate dismissal.
A workaround can be useful and risky at the same time
Consider an employee who maintains a separate spreadsheet to track cases waiting for review.
The spreadsheet might provide something genuinely valuable: a quick overview of outstanding work, deadlines, and responsibility.
Perhaps the official system requires several screens to obtain the same information.
From the employee's perspective, the spreadsheet solves a practical problem.
But it may also create new ones.
If information is copied manually, the two systems can become inconsistent. If the spreadsheet includes confidential information, inappropriate sharing or storage could create privacy and security risks. If only one employee understands the file, continuity becomes a concern when that person is unavailable.
The lesson is not that spreadsheets are inherently bad.
It is that a useful workaround can solve one problem while quietly introducing another.
This creates two responsibilities for organizations: understand the need the workaround addresses, and assess the risks created by the way it operates.
Simply prohibiting an informal process without addressing the underlying need may leave employees with the same unresolved problem.
Equally, allowing every informal process to continue without scrutiny can weaken accountability, recordkeeping, and information security.
The right response requires more than choosing between acceptance and prohibition.
It requires understanding.
Five questions worth asking before purchasing another tool
When an organization identifies repeated manual steps, disconnected records, or unofficial tracking systems, there is an opportunity to learn before spending more money.
1. What is happening outside the official system?
Start by identifying the activities that depend on spreadsheets, paper notes, messaging applications, email chains, or memory.
Look especially at activities employees consider essential for completing their responsibilities.
The objective is not to catch someone doing something wrong. It is to understand the complete process.
2. Why does the workaround exist?
A separate process might compensate for a missing feature, but that is only one explanation.
It might also exist because employees lack training, an established procedure is unclear, the available interface is difficult to navigate, or responsibility between departments has never been properly defined.
Different causes require different solutions.
3. Who carries the extra work?
A process may appear efficient from a management dashboard while requiring substantial manual effort behind the scenes.
Who copies information between systems? Who checks for inconsistencies? Who follows up when records are incomplete?
Understanding where that additional effort occurs can reveal costs that software licensing and implementation budgets do not capture.
4. What could go wrong?
Not every workaround has the same risk.
An informal checklist for arranging a meeting is different from an unofficial record containing sensitive case information.
Organizations should examine confidentiality, accuracy, permissions, auditability, retention, and operational continuity.
In public safety, legal, healthcare, and other sensitive environments, these questions are especially important.
5. What should change first?
Only after understanding the first four questions should an organization decide what to improve.
Sometimes the answer will be better software.
Sometimes it will be an integration between existing systems, a revised workflow, clearer responsibility, improved training, or a small adjustment to the interface people already use.
The most effective improvement is not necessarily the most technologically sophisticated one.
It is the one that addresses the underlying problem.
Good technology begins with understanding the work
This approach is consistent with established service-design guidance.
The UK Government Digital Service's Service Standard emphasizes understanding users and the problems they are trying to solve before committing to a particular solution. Its guidance encourages teams to examine the broader context in which people interact with services, test assumptions, and conduct ongoing user research.
That thinking is valuable beyond government technology.
For an organization considering a new digital platform, a useful starting point is to observe how work moves from beginning to end.
Not just what the software records, but what happens before information enters the system, what people do while waiting for a decision, and what remains unfinished after the dashboard marks a task complete.
These observations can expose problems that would otherwise be missed.
They can also help an organization avoid buying another tool that reproduces the limitations of the previous one.
A practical exercise for your team
Before your next software procurement discussion, choose one recurring process.
Ask the people who perform it to walk through a recent example from start to finish.
Pay attention to moments when they leave the official system, repeat information, consult an unofficial record, or contact another person to complete a step.
For each moment, document three things:
- What the person was trying to accomplish.
- Why the existing process did not fully support that task.
- Whether the alternative introduced additional effort or risk.
Then review the findings together.
Do not assume every workaround requires a new feature. Do not assume every deviation is a problem. And do not assume a process is efficient simply because its official workflow appears orderly.
Start with evidence. Then decide what deserves to change.
The bigger question
As organizations adopt increasingly sophisticated digital tools, including AI-enabled systems, it becomes tempting to equate technological capability with organizational progress.
But a system can be technically impressive and still fail to support important parts of everyday work.
The measure of useful technology is not simply how many functions it offers.
It is whether people can complete meaningful tasks accurately, securely, and with less unnecessary effort.
At LeshCore Technologies, that distinction is central to how we think about technology, public safety, and research.
We believe the starting point for thoughtful innovation is understanding the problem clearly enough to recognize when technology is useful—and when a simpler change may be better.
Before purchasing another system, upgrading another platform, or automating another workflow, follow the workaround.
It may lead you closer to the problem that actually needs solving.
Technology with Purpose is an editorial series from LeshCore Technologies exploring digital systems, public safety, research, and the relationship between technology and the people it serves.
Discussion question: What is one task your organization still handles outside its primary system—and why does that extra step remain necessary?
LeshCore Technologies Technology · Public Safety · Research & Insights https://leshcore.com