Employees resist new technology because it threatens the competence they worked years to build, not because the software is bad. Your team isn’t rejecting a tool. They’re protecting the version of themselves that already knows how to do the job.
I’ve spent 35 years in technology consulting, and after a decade of handling technology change management for small business clients across Southern California, I get the same call every September. A managing partner asks me why the staff hates the new software. Every time, the software has nothing to do with it.
Fall is rollout season. Firms close out summer, look at their budgets, and decide this is the year they finally replace the clunky document management system or move off the spreadsheet three people are editing at once. The timing makes sense on paper. New fiscal year, fresh budget, a slower month before year-end work hits.
What doesn’t make sense, at least not to the partner writing the check, is why Denise in accounts payable, who has been with the firm for eleven years, suddenly seems to be sabotaging the rollout. She isn’t. She’s scared, and she has good reason to be.
The Real Reason Behind User Adoption Resistance
Denise didn’t wake up one day and decide to be difficult. She spent years learning the old system’s quirks. She knows which button to double-click and which one crashes the program if you’re not careful. That knowledge is invisible until you take it away.
When you introduce new software, you’re not asking someone to learn a feature. You’re asking them to become a beginner again, in front of coworkers, at a job they’ve done well for over a decade. That’s a real loss, and treating it like a training problem misses what’s happening.
I watched this play out at a law firm I’ve worked with for years. The partners wanted to switch practice management platforms. Every objection that came back from staff sounded like a software complaint – too many clicks or confusing menus. The whole thing felt slower than what they already knew.
The complaints weren’t really about the software. They came from a paralegal who had built her entire reputation on being the person who never made mistakes, and was suddenly worried she’d look incompetent in front of a client on the phone.
What Workplace Technology Training Gets Wrong
Most workplace technology training treats resistance as an information gap. Teach people the buttons, the thinking goes, and the complaints stop. I’ve sat through enough of these sessions to tell you that’s backward.
Training answers “how do I use this.” It doesn’t answer “what happens to me if I get this wrong in front of everyone.” Until someone trusts that a mistake won’t cost them their standing, they won’t retain a single instruction you give them, no matter how well you explain it.
We don’t handle rollouts by building a better training deck. We sit down with the people who will resist, before launch, and ask what they’re worried about. Usually it’s not the software at all. It’s whether they’ll still be the person everyone turns to when something breaks.
Fix the Person’s Problem, and the Software Problem Solves Itself
Once you know what someone is afraid of losing, you can address that directly instead of throwing more training hours at a group that’s already tuned out. Sometimes that means giving your most resistant employee a head start on the new system, so they’re the expert again by launch day instead of the last one to catch up. Sometimes it means naming, out loud, what they built in the old system, so the switch doesn’t feel like an erasure of years of work.
At a property management firm I’ve worked with, we gave the office manager who’d run the old system for a decade a two-week head start and made her the go-to person for questions once the rest of the staff went live. She stopped fighting the rollout the moment she had something to be good at again.
That’s the part software vendors never mention in their sales pitch, because it isn’t their job. It’s the job of whoever is managing the rollout, and most firms hand that job to a vendor who has never met Denise and doesn’t know she exists.
A smaller version of the same fix works even when you can’t give someone a head start. Ask your most resistant employee to test the new system a week early and report back what confused them. You’re not really asking for feedback. You’re handing them back their expert status before anyone else in the office has touched the thing. People protect what they helped build, and that includes a rollout they had a hand in shaping.
Before You Roll Out Anything This Fall
If you’re planning a technology change this September, spend less time evaluating features and more time figuring out who on your staff has the most to lose by becoming a beginner again. Talk to that person first, not last. Give them a reason to want the new system instead of a deadline to accept it.
Review your rollout plan against one question: does it treat your staff like people with something to protect, or like obstacles between you and go-live day? The answer usually explains every “software problem” you’ve had in the past.
