Talking to Your Team About AI Without Making It Worse

Most teams contain both an AI enthusiast and an AI sceptic, and most managers treat one of them as the problem to be managed. That's the mistake, because both are usually right about something specific and wrong about how far it generalises.

The enthusiast is right that a lot of work is being done slowly for no reason. They're usually wrong that quality is holding up as well as they think, because they're the ones producing rather than the ones receiving.

The sceptic is right that output has got worse in places, and they can often name them. They're usually wrong that this is a property of the tool rather than of how it's being used.

Treat either as an obstacle and you lose what they're right about — plus, in the sceptic's case, you get quiet non-compliance rather than disagreement, which is far worse because it's invisible.

The conversation that doesn't work

"We're all going to be using AI, here's the tool, here's a training session."

This fails predictably. It answers a question nobody asked (which tool) and ignores the two they're actually asking: is my job at risk, and am I going to be blamed when this produces something wrong.

Until both are answered, adoption is performative. People will attend the training and carry on as before, and you won't find out for months.

Answer the job question honestly

The honest answer is almost never "your job is safe" or "some of you will go". It's that the bundle of tasks is being redistributed, and which parts move depends on the role.

Being specific is what makes this credible. "The reporting and the first drafts are moving; the client judgement and the prioritisation aren't" is a claim people can check against their own week. "AI will augment rather than replace you" is a slogan, and it will be heard as one.

If you genuinely don't know, say that. Anyone who's watched a leadership team profess certainty about a thing that then changed will trust an honest "I don't know yet, here's what I'm watching" considerably more.

Answer the blame question explicitly

This is the one that actually gates adoption, and it's rarely addressed.

If an AI-assisted deliverable goes wrong, who owns it? The answer has to be the person who sent it — that's how accountability works, and courts have started saying so. But that answer is only fair if people have been given time to check, and a standard for what checking means.

Say both parts. You own what goes out under your name; the time to verify it is part of the task, not an overhead you're expected to absorb. Without the second half, the first half reads as a threat, and the rational response is to avoid the tool for anything consequential — which is exactly the work where it would help most.

Make the standard the team's, not each person's

The most common failure I'd expect in a team rollout is that everyone invents their own verification habits privately, at wildly different levels of rigour.

A shared standard fixes this cheaply: for this kind of deliverable, these are the three things checked before it goes out. It takes half an hour to write, it makes review times comparable, and it means a sceptic's concerns become a checklist item rather than a personality trait.

Watch for the tool going underground

If your team can't use AI openly — because policy forbids it, or because admitting to it feels like admitting to cutting corners — they'll use it anyway, on personal accounts, with company data.

That's worse in every dimension: no oversight, no shared standards, and genuine data exposure. A permissive policy with clear boundaries beats a restrictive one with none, because the restrictive one isn't actually restricting anything.

Wes — the sceptic who was right

Wes manages a client services team. One analyst pushed back hard on AI-drafted client updates, which he initially read as resistance.

She was specific when he asked properly: three updates had gone out with confident phrasing about project status that nobody had verified — "on track", "actively monitored" — that the model had produced and the sender hadn't noticed adding.

She wasn't against the tool. She was against sending unverified claims to clients, which is a position he agreed with the moment it was stated that way. The fix was a two-line check before sending. She's now the person who wrote it.

Dilara — the policy that wasn't working

Dilara heads operations at a professional services firm with a restrictive AI policy: approved tools only, no client data, sign-off required.

An anonymous survey found roughly half the team using personal accounts for work tasks anyway — because the approved tool was slow to access and the sign-off took two days.

Her read was that the policy hadn't reduced AI use at all; it had moved it somewhere she couldn't see, with client data in it. She replaced it with a shorter one: an approved tool that's actually fast to reach, a clear list of what must never be pasted, and no sign-off for anything internal.

Measured use went up. Actual exposure went down.

The one thing

Both your enthusiast and your sceptic are right about something. The manager's job isn't to pick a side — it's to answer the two questions nobody asks out loud: is my job at risk, and will I be blamed.

Answer those specifically and honestly, give people a shared standard, and make the sanctioned path the easy one. Otherwise the tool goes underground and you lose the visibility along with the argument.