AI Adoption Is a People Problem

We frame AI adoption like a technical event. “We’re deploying a tool.” “We’re modernizing the stack.” “The infra is ready.” And the infra is ready. It was ready before the first person logged in, before the first prompt was typed, before the first “wait, does it save my keystrokes?” got whispered into a Google Meet.

The disruption was never the machine. The machine is a dumb box with “opinions” now, which is somehow worse.

The disruption is us.

AI as a human issue#

A senior engineer told me, quietly, over a coffee: “It feels like I’m learning my whole job wrong in public.” And then she laughed the laugh you do when you’re not actually laughing.

That’s the one nobody puts in the risk register. The threat model gets a whole page for “prompt injection” and “data exfiltration” and “model hallucinating the credentials.” Real, great, ship it. But the human threat model…? The one where your job, which you have been perfecting for a decade, suddenly has a co-pilot that does some of it in four seconds? That one has no ticket in Jira.

Advanced threats are the same deal. The attacker got smarter. The tooling got scarier. And somewhere in the middle is a human being who now has to trust a system that might be wrong in a way they can’t see. Partnership with the machine is unsettling because the machine stopped being a hammer and started being a colleague.

Colleagues do weird things.

So we lead like it’s a human issue, because it is.

From resistance to resilience#

Day 1 of the AI rollout: I handed out licenses. The silly creatures got very quiet.

Resistance isn’t stupid. It’s not the team being “stuck” or “frozen” or “resistant to change.” Being frozen is a rational response to a thing that looks like it’s going to eat your skills and then ask why you weren’t mOrE aGiLe. The new way isn’t obvious yet, and the old way doesn’t feel safe anymore. So they freeze.

And that freeze is not a personality trait. It’s what happens when the ground under your feet changes and you can’t yet see where the new ground is. Your brain doesn’t get a memo about it. It just feels the shift and does the only thing it knows how to do: hold on.

So you don’t lecture them out of it. You take the fear out of it. You let them touch the thing before anyone announces it, so the change is something they helped make rather than something that happened to them. You stay in the room after the demo, when the real questions come out, “does it remember everything I type?” and you answer them. Because the ones you don’t answer don’t go away. They go underground and come back as a quiet, polite “yes, I’ll try that” that isn’t a yes at all.

Resilience is not the absence of fear. Nobody is not afraid. It’s the team that stops waiting for the perfect plan and starts moving in small, fast steps instead, where each person can adapt as they go.

You can’t memo-resilience into a team. You have to get in the water with them.

Empathy-first, or the rollout fails on a Tuesday#

So how do you actually do it? You replace fear with curiosity, and you do that bottom-up, not top-down. “I use arch, btw” does not land when the person you’re asking to trust you is about to have their job description rewritten.

The old way was command: stack teams in silos, pass information through choke points, hope the forward team figures out why the analysis team’s output is late. It worked when the environment was predictable. Now the environment is complex: fast, interdependent, nonlinear. Any action ripples into more outcomes than it used to. Command doesn’t scale to that. Trust does.

So you build trust. Not the poster-in-the-office kind. The kind where someone can raise their hand and say “wait, what happens to my role” and the room does not gasp.

Let them touch it first. Before the announcement, before the email from leadership, let a handful of actual practitioners play with the thing. Not “evaluate” it. Play. Let them get it wrong, let them be surprised, let them find the weird edge case. And when they do, don’t fix it for them. Ask what’s behind it: “how did it do that? what were you assuming?” Curiosity is born from touching and asking, not from briefing.
Make the hard question sayable. Psychological safety is not a poster in the office. It’s what happens when someone raises their hand and says “wait, what happens to my role” and the room does not gasp. You have to signal, repeatedly, that the question is a good question.
Replace the fear word with the curiosity word. “We’re rolling out X and it may change how you work” is a fear sentence. “We’re rolling out X and I want to see what you can make it do that we didn’t plan for” is a curiosity sentence. Same rollout. Different animal.
Stay in the room after the demo. This is the part everyone skips. The Q&A where the real questions come out. The ones about the money, the job, the “does it remember everything I type.” Answer them. The unanswered ones don’t go away. They go underground.

Fear asks “what will it take from me?” Curiosity asks “what can I build with this?” You can’t lecture curiosity out of a team. You earn it by staying close, staying honest, and not pretending the wave isn’t there.

Ask questions. Let the team touch the thing before you announce it.

The machine was never the hard part.