Overcoming team resistance to new tools and AI

Resistance is information, not stubbornness

When your team drags its feet on a new tool, it's tempting to read it as laziness, technophobia, or people being "stuck in their ways." That reading is almost always wrong, and worse, it sends you toward the wrong fix — more pressure, more mandates, more frustration on both sides. Resistance is not an obstacle to push through; it's a signal to decode. It's telling you something specific about fear, friction, trust, or fatigue. Read the signal correctly and the resistance usually dissolves, because you fix the actual thing causing it.

The most useful mindset shift here is to stop treating resistance as a character flaw in your team and start treating it as feedback about your rollout or your tool. People are generally rational about their own work. If they're avoiding something, there's usually a reason that makes sense from where they sit — even if it's invisible from the founder's chair. Your job is to find that reason. There are four common ones.

The four sources of resistance (and the fix)

1. Fear. This is the big one — the single largest driver of resistance to new tools and especially to AI. "Will this replace me? Will I look stupid when I can't make it work? Will I get blamed if it produces something wrong?" Fear is rarely stated out loud, which is exactly why it's so effective at quietly killing adoption — people won't tell you they're scared, they'll just not use the thing and find plausible reasons why.

The fix is to name it directly and honestly, because fear is only ever addressed by being brought into the open. Say the quiet parts: nobody's being replaced, this takes the boring work so you can do the work only you can do; mistakes while learning are completely fine and expected; you will never be in trouble for a bad draft, only for sending one to a client unchecked. And model your own fumbles — when the founder admits where the tool has been confusing or wrong for them, it gives everyone permission to be a beginner. Founders who show vulnerability get honesty and adoption; founders who present new tools as flawless mandates get compliance theatre.

2. Friction. Sometimes the resistance is completely rational: the tool is genuinely clunky, slow, or a poor fit for how the work actually flows, and avoiding it is the sensible response. No amount of motivational rollout will fix a tool that makes someone's day harder — and trying to "train past" friction just teaches your team that you'll ignore their legitimate complaints.

The fix is to remove the friction, not push through it. Pilot the tool first with one or two people so you find the rough edges before they hit everyone. Listen to what the pilot users actually struggle with and fix it. And — most fundamentally — choose tools that fit how your team works rather than tools your team has to contort around. Friction-driven resistance is the most honest kind, and the most fixable, because it's pointing directly at a real problem.

3. No clear "why." People resist change whose point they don't see, and "the company wants us to use this" is not a point they care about. If the benefit was never made personal — never tied to their day getting easier — then from their perspective you've added work for no reason, and quiet resistance is the natural result.

The fix is to connect the tool to a benefit they actually feel: less grunt work, fewer errors, faster finishes, less of the specific thing they complain about. Lead with their win, not your KPI. "This ends the status-report scramble that eats your Friday" lands; "this improves our reporting" doesn't. If you genuinely can't articulate a personal benefit, that's worth noticing — maybe the tool isn't actually worth their effort yet.

4. Change fatigue. If you've rolled out five new things this quarter, the sixth meets a wall regardless of how good it is. There's a finite budget for change in any team, and a small team's is smaller than you think because everyone is already doing two jobs. Pile on too much and people stop engaging with any of it as a form of self-protection.

The fix is restraint and sequencing: space changes out, and finish one adoption before starting the next. One workflow that genuinely sticks is worth more than five half-adopted tools, and it preserves your team's appetite for the next change. If you're meeting resistance to a perfectly good tool, ask honestly whether it's the sixth change in two months — and if so, the problem isn't this tool.

A quick diagnostic

Here's a single question that cuts through almost every case of resistance. Ask the resistant person, genuinely and without defensiveness: "What would have to be true for this to make your day easier?"

Their answer tells you exactly which of the four you're dealing with. "I'm worried this means you don't need me" is fear. "It takes longer than the old way because of [specific thing]" is friction. "I don't really see why we're doing this" is a missing why. "Honestly I just can't take on another new thing right now" is fatigue. And because the question is framed around their day getting easier, it signals that you're on their side trying to solve a problem, not interrogating them for non-compliance — which makes people far more honest than a vague "why aren't you using the tool?" ever could. (For the broader people-side approach, see change management for small teams.)

What not to do

A few instinctive responses make resistance worse. Mandating harder — adding pressure to fear produces compliance theatre and resentment, not real adoption. Dismissing complaints as excuses — when friction is real and you ignore it, you confirm that you won't listen, which deepens resistance. Public shaming — calling out non-adopters in front of the team humiliates people and makes everyone more cautious. Piling on more tools to "show momentum" — this just deepens change fatigue. The throughline: every one of these treats resistance as the enemy rather than as information, and so attacks the symptom while leaving the cause untouched.

Turn resisters into advocates

Here's a reframe that changes how you handle resistance: your most resistant person is often your most valuable one to win over, because they're usually resistant for a reason — and that reason is information the rest of the quietly-compliant team won't give you. The person loudly pointing out that the new tool doesn't handle a key edge case isn't an obstacle; they're doing free QA on your rollout. If you address what they raise, you don't just convert one person — you fix the thing that would have quietly held back several others who weren't vocal about it.

So treat your sceptics as a resource rather than a problem. Bring a thoughtful resister into the pilot deliberately; if you can win the person most likely to find fault, the rest of the team's adoption is nearly guaranteed, and that person — having been listened to and having seen their concern addressed — frequently becomes the most credible advocate you have. "I was the one who didn't want this, and now I use it every day" is the single most persuasive thing a teammate can say to a nervous peer. Resistance handled well doesn't just disappear; it converts into the strongest possible endorsement.

Reduce resistance by reducing friction

Across all four sources, one move does the most work: reduce friction at the root by choosing tools that fit your team's real workflow. You can out-train fear and out-explain a missing why, but you cannot out-motivate a tool that genuinely makes someone's job harder — and most off-the-shelf software, built for everyone, fits no one perfectly, so it ships with friction baked in. The lowest-resistance tool is one designed around how your team already works.

That's the idea behind Forge. Instead of buying a generic app and then spending weeks fighting the resistance a poor fit creates, you get internal tools shaped to your agency's actual process — which removes most of the friction before it starts — plus built-in usage tracking, so you can spot resistance early (who's not adopting, where the drop-off is) and address the real cause instead of guessing. See how it works →