When a company invests in new enterprise software, SaaS platforms, or automation, there is usually an expectation that employees will embrace the change.
...Then reality arrives...
People keep using spreadsheets. They hang onto an older program. They duplicate information in two systems. They create manual checks that were never part of the implementation plan. Someone finds a workaround that completely bypasses the new workflow, then you find yourself over 6 months later holding the bill for a big tech overhaul and no actual improvements in efficiency or outcome. At this point, it is tempting to conclude that your company has an adoption problem, or more specifically, an employee adoption problem.
However, this conclusion can lead to additional management choices that will only make your problems worse. When employees resist a new system, your first question should not be, "How do we make them use it?", it should be "What are they telling us about the system that we do not know yet?"
Resistance Is Often Information
There is plenty of advice surrounding software implementation that treats adoption primarily as a matter of enforcement.
Managers are told to eliminate old options, require employees to use the new platform, establish consequences for noncompliance, and avoid allowing reluctant employees to derail the transition. And yes, there are situations where clear expectations are necessary, because a company cannot maintain five different processes indefinitely just because everyone has a personal preference.
But treating resistance primarily as an attitude problem overlooks something important: The people doing the work often understand details that the people managing the implementation never encounter.
A manager may understand the business process at a high level. An executive may understand what the company needs from its technology. An IT consultant or software developer may understand the technical requirements, but the employee using the system eight hours a day understands something different. They know the strange exceptions. They know which customer requests do not fit the normal process. They know which pieces of information have to be verified before something can move forward. They know which five-minute task actually takes twenty minutes when certain conditions occur. They also know which old feature looked insignificant during a software demonstration but turns out to be essential when someone is processing 40 transactions on a Tuesday morning.
This kind of mismatch is a commonly recognized problem with enterprise systems. In a three-year study of an enterprise-system implementation, researchers Diane Strong and Olga Volkoff identified misfits involving functionality, data, usability, employee roles, organizational controls, and culture. They noted that packaged enterprise systems are built to serve generic requirements and can therefore be an imperfect fit for a particular organization.
When employees resist a new system, they may be resisting change, or they may also be identifying a genuine shortcoming of the new system. Finding out which one is happening should come BEFORE deciding how to respond.
A New System Can Be Better and Still Make the Job Worse
Software evaluations are frequently built around improvements: The new system has better reporting, it integrates with accounting, it automates customer notifications, etc. All of these things may be true, but software does not have to be worse overall to create serious problems. It only has to make certain critical parts of someone's job harder.
Imagine replacing a system with one that adds several new and clearly beneficial features only to discover that some task your employees perform 60 times per day, now requires 4 additional clicks, or the new search function cannot find records using the information customers typically provide, or a piece of key information that used to remain visible throughout the workflow is now hidden three screens away, or the automation occasionally produces an incorrect result, so your employees start checking every automated transaction manually.
Your organization may have gained several useful capabilities while simultaneously creating a substantial operational cost. That does not necessarily mean the new software should be abandoned, but it does mean that the problem should be investigated rather than blamed on the people experiencing it.
Watch What Employees Do Around the System
One of the best indicators that something is wrong with a new implementation is not what employees say, it is what they start doing.
Employees are remarkably good at building unofficial systems around official systems when the official process does not meet their needs.
They may:
- Maintain a spreadsheet because the software does not create the reports they need.
- Write notes in inappropriate fields because the new system does not provide the right field.
- Copy data into another application because they can not effectively find information in the one provided.
- Skip step that create bottlenecks in thier workflow.
- Perform manual quality-control checks because the automation does not always work.
- Keep temporary records in another program because they are afraid something will time out and make their information disappear.
- Share credentials or bypass security controls because the approved process interferes with getting the work done.
Some of these workarounds are inconvenient, but others can introduce security, compliance, or data-integrity problems, and almost all of them can create labor that was never accounted for when management calculated the benefits of the new system. An automation may supposedly save an employee ten minutes, while the employee quietly spends fifteen minutes verifying that the automation worked correctly. From management's perspective, the automation is operating successfully, but from the employee's perspective, their workload just increased.
Research on enterprise content-management systems has documented this relationship between system quality, information quality, user satisfaction, and workarounds. In a study combining 34 employee interviews with data from 247 system users, researchers found that system and information quality affected user satisfaction, which in turn influenced workaround behavior. Employees who used workarounds to avoid the enterprise system also experienced lower individual net benefits from the system.
In other words, workarounds should not simply be dismissed as evidence that employees refuse to follow directions. They are often evidence that something about the system or the information it provides is not working well enough for the people expected to use it.
Do Not Let Employee Feedback Become a Game of Telephone
One of the most damaging implementation mistakes is creating too many layers between employees and the people responsible for the technology.
An employee tells a supervisor: "The system doesn't work when a customer has multiple locations."
The supervisor tells a manager: "They're having trouble with customer records."
The manager tells the IT provider: "Some employees are struggling with the new customer workflow."
By the time the information reaches the person who can fix the problem, the actual problem has disappeared. Now IT thinks the employees need additional training, the employees think IT does not understand their jobs, and Management thinks employees are refusing to adapt. Everyone becomes frustrated, and the underlying technical problem remains.
There is research behind this concern as well. Michael Gallivan and Mark Keil studied a software project that failed despite substantial user involvement. They found that breakdowns in the communication process prevented developers from learning the underlying reasons users were avoiding the system. Their research is an important reminder that merely saying employees were "involved" in implementation does not guarantee that useful information actually reached the people building or configuring the system.
During a major implementation, the people doing the work should therefore have a way to communicate technical problems to the people capable of investigating them without requiring every observation to pass through multiple layers of interpretation. That does not mean every employee should independently dictate system changes, but it does mean that technical feedback should be able to travel without being translated into something unrecognizable.
In our experience, a short conversation between a developer and the employee actually performing the task can often uncover an issue that management has been discussing for weeks.
Examine the Workflow in Action
There is a significant difference between asking "What don't you like about the new software?" and "Show me what happens when you try to do your job."
When you ask the first question, you will often hear a response that sounds insignificant on the surface like "It just feels wrong", "It is slower", or "I can never find what I need in it". While these might sound like the sorts of issues that should go away with time, they often hide real structural problems with the new system that they simply don't know how to articulate.
Instead you should have employees demonstrate real workflows. Watch the screens they visit. Watch what information they need. Notice where they hesitate. Ask why they opened another application, why they wrote something down, why they checked the customer's record twice, and what would happen if they skipped that step.
Frequently, important implementation requirements are discovered after the software has gone live because real work exposes circumstances that demonstrations and requirements meetings never uncovered. That is not necessarily evidence that the implementation failed. It may be evidence that implementation is not finished.
Sometimes the Right Answer Is to Change the New System
Businesses sometimes approach software selection as though features are permanent, but that is not always the case. If employees relied heavily on a feature in the previous system, ask whether that capability can be recreated.
Depending on the technology, the answer might involve:
- Changing a configuration.
- Adding a custom field.
- Modifying permissions.
- Creating a different dashboard.
- Changing the workflow.
- Building an integration.
- Adding an automation.
- Modifying custom software.
- Creating a small companion application.
- Requesting a feature from the SaaS provider.
This is one reason flexibility should be considered when selecting business technology in the first place. Two systems may appear comparable during the buying process, but one may provide substantially more room to adapt once the company learns what its employees actually need. When picking out a new platform for your company, picking one that can be customized is often a better investment than one that is cheaper or comes with better native features. Forcing your organization to conform perfectly to the software often creates worse long term results than having software can conform to your organization.
Mandatory Use and Unquestioning Use Are Not the Same Thing
None of this means employees should simply be allowed to use whichever systems or processes they prefer. Sometimes a new system absolutely has to be mandatory. Cybersecurity controls cannot necessarily be optional. Neither can financial controls, regulatory processes, records-management requirements, data standards, or companywide systems that depend on consistent information.
At some point, management may legitimately have to say, "This is the system we use." However, mandatory use and unquestioning use are not the same thing. If employees repeatedly have to fight the system to accomplish legitimate work, enforcing compliance without investigating the cause can simply hide the problem. An employee who bypasses a security control may be creating an unacceptable security risk; that behavior needs to stop, but management should still ask why the employee felt the need to bypass it. Sometimes this means additional training is needed or sometimes it means the employee misunderstood the process, but quite often it means that the approved process makes a routine part of the job unnecessarily difficult, and that there is a way to redesign it while preserving the security requirement.
Good management should BOTH enforce a necessary rule AND investigate why people struggle with it.
Training Still Matters
Employees sometimes resist unfamiliar processes simply because the previous method is familiar. It is very normal to see about 3-6 months of resistance against a new system simply because your employees are still learning how it is meant to be used. This does not mean you should ignore their complaints during this transition period, just that some resistance should be expected even when there is nothing functionally wrong with the new system.
Training Should Include Scheduled Hands-On Practice
One of the biggest mistakes employers make during a software change is underestimating how much training people actually need. A product demonstration or a few hours of instruction may be enough for employees to understand how a system should work in theory, but understanding a process in a training environment is very different from being able to use it comfortably during a busy workday. Everything may make sense when an instructor is walking through a clean example one step at a time only for problems to appear later when employees encounter real customers, unusual records, interruptions, deadlines, competing responsibilities, and the dozens of small variations that make up their actual jobs.
Whenever possible, employees should have time to work in the new system before they are expected to rely on it for normal production. Give them realistic exercises where they have to duplicate actual client records in the new system. Have them enter sample transactions, make mistakes, ask questions, and repeat common workflows while the consequences are still low. If there is a test environment or sandbox available, use it. Most importantly, make sure that training time is actually scheduled, and not just left open to do "when you have time". It is normally your most critical employees who have the tightest schedules and will be unable to self-schedule training that become the most resistant to new systems because they don't see themselves as having the time to learn before you launch, and because small feature changes that slow them down will affect them more than your less vigorous staff members.
... that said, these are also normally the employees who can give the best feedback before you go live with a new system to make sure that it is actually able to support your business before you make it responsible for holding it up.
Is It a Training Issue or a System Issue?
Training matters, documentation matters, clear expectations matter, but training should not become the automatic explanation for every adoption problem. If several experienced employees independently struggle with the same workflow, the organization should investigate the workflow before just scheduling another training session. There is an important distinction between "I don't know how to do this" and "Doing it this way creates additional work" or "Doing it this way creates problems when..." You need to know which problem you are actually solving, before you can determine if more training will solve the issue.
Be Careful With the Sunk Cost Fallacy
Software implementations are expensive. They consume money, management attention, employee time, consulting fees, data conversion work, training, and sometimes months of planning. That makes admitting that something is not working psychologically difficult. "We have already invested too much to change direction" can become a powerful argument, but it is one that is ultimately dangerous for the long term well-being of your business.
The Sunk Cost Fallacy is the belief that the more you've invested into something, the more obligated you are to stick with it; however, the money and time already spent are gone whether the company continues using the system or not. So, the useful question is "what happens next?"
That does not mean previous investment should be ignored when evaluating your options. Changing direction may create new migration expenses, contractual costs, retraining, disruption, or development work. Those are legitimate costs because the company would incur them in the future, but the fact that you already spent $100,000 on a product does not necessarily make using the product a good investment. If it is costing you $60,000 per year in reduced productivity, then you need to ask yourself if this software was actually the right choice and be willing to accept that answer no matter how bad it may feel.
Sometimes the correct decision is to modify the system, sometimes it is to replace a component, and occasionally, it is to admit that the software was the wrong choice all together. Continuing a bad implementation indefinitely does not recover the original investment.
What Does A Successful Adoption Look Like?
Real-world use reveals problems and requirements that are difficult to uncover during planning alone. The objective is not simply to get employees to use the new system. The objective is to create a system worth adopting. When employees start working around the technology, bypassing processes, adding manual verification, or returning to old tools, those behaviors should be treated as operational signals rather than dismissed as resistance.
Some workarounds may need to stop immediately, especially when they create risks involving security, compliance, financial controls, or data integrity. But stopping the workaround is only half of the job. You also need to understand why it appeared and what the system is failing to provide. That means bringing the employees who understand the day-to-day work together with the technical people who understand what can be changed.
Sometimes the answer will be better training. Sometimes it will be better communication. Sometimes the software itself will need to change. And sometimes your employees will have identified a flaw in the new system before management did. That is not information you want to stamp out. It is information you want to use.
