You’ve signed off the software build. It’s smart. It’s sleek. It solves all the problems you set out to fix.
There’s just one problem: nobody’s using it.
That’s because getting software built is only half the job. Getting people to use it, that’s where most projects stumble. Not because the system’s bad. Because the change was too fast, too unclear, or too disconnected from day-to-day reality.
Here’s how to win team buy-in for tech change, and how we bake it into every GGA project from day one.
1. People don’t hate software, they hate surprises
It’s not the tech that causes pushback. It’s being left out of the loop.
If your team wakes up to a new system they didn’t ask for, weren’t consulted on, and don’t understand… of course they’ll resist it.
The fix? Involve the team early. Not just in the build, but in the why behind it.
- What’s the problem this solves?
- What gets easier?
- What pain goes away?
Make that crystal clear. Then show how the tech supports them, not just “the business.”
2. Design for the doers, not just the decision-makers
Systems often fail because they’re built around leadership’s idea of the process, not the people doing the work.
We dig deep during discovery with front-line users. We ask:
- Where do things fall over?
- What annoys you every day?
- What’s manual that shouldn’t be?
When your system solves their problems, you don’t have to push adoption. They pull it in themselves.
3. Onboarding isn’t optional
You can’t drop a new system on someone and expect them to figure it out.
Even the cleanest UI needs a nudge. That’s where digital adoption matters, and where most dev agencies drop the ball.
At GGA, we build:
- Embedded prompts and tooltips (lightweight Digital Adoption Platforms)
- Quick video walkthroughs (Looms, not 40-page manuals)
- “What’s changed” modals that show new features
- Help buttons that actually help
And most importantly, we involve the team in testing before launch. So they don’t just use the system, they shape it.
4. Make it safe to mess up
If people fear getting it wrong, they’ll stick to what they know. That’s how shadow systems and workarounds creep back in.
So we create:
- Sandboxes to practise
- Role-specific views (no overwhelm)
- Clear fallback plans if they hit a snag
Training is ongoing, not one-and-done. The more support we build in, the faster people get confident, and stay that way.
5. Ownership beats cheerleading
The best adoption we’ve seen comes from teams where:
- There’s a named champion internally
- They get early access and real input
- They’re supported to support others
One engaged ops lead can do more for adoption than any roadmap or training doc. We always identify a “system owner” as part of launch.
Final thought
People don’t resist new tech because it’s difficult; they resist it because they’re busy, unsure, or weren’t asked.
Want buy-in? Build systems that serve them, explain the why, and support the how from day one. Do that, and your fancy new tool won’t just get used, it’ll become essential.
