The Coach's Role in AI Transformation

Organisations spend serious money getting AI adoption wrong in a very specific order: licences first, security review second, infrastructure third, and then, almost as an afterthought, a training day. The figure quoted most often for where this lands is a 15% adoption plateau — I’ve seen it repeated enough times to treat it as directionally true, but I’ve never seen anyone name the study behind it, so take it as a shape rather than a settled number. What’s more reliable is the pattern underneath it: the rollout stalls not because people don’t understand the tool, but because nobody on the project owns the part of the job that has nothing to do with the tool.

Knowing how something works and using it as a habit are two different states, and the distance between them is exactly where a coach operates, not an engineer. Ten years running a 1:1 coaching practice, guiding people through career changes and the kind of life transitions nobody schedules a training day for, taught me something that transfers directly here: people rarely resist change because the logic of it escapes them. They resist because using the new way, in front of colleagues, exposes exactly how much they don’t yet know how to do — and that threatens something more specific than productivity. It threatens the sense of being the person in the room who’s competent.

An engineer solves for the tool working. A coach solves for a specific person being willing to look incompetent in front of their team long enough to stop being incompetent. Those are different jobs, and most AI rollouts only staff the first one, because it’s the one with a line item and a deliverable. Coaching doesn’t produce a system you can point to when the budget gets reviewed, so it gets treated as optional even in the rollouts that will, on paper, tell you people are the priority.

What that work actually looks like, when someone does it: working with the resistance instead of arguing it down, because arguing rarely moves someone whose objection was never really about logic in the first place. Building enough psychological safety that trying the tool badly, in view of a manager, doesn’t read as an input to a performance review. Translating “this model can do X” into what that specifically changes about the Tuesday-afternoon task this particular person already hates — abstraction convinces nobody, specificity does. And then staying present through the stretch where the person is visibly worse at their job than they were a month ago, which is the part every organisational timeline is designed to rush past.

I don’t think most companies will create this role voluntarily, because it’s hard to specify in a job posting and harder to measure in a quarter. Whether it becomes standard practice anyway, or whether AI transformation keeps quietly failing at the same human step every technology disruption before it also failed at, is the open question nobody funding these rollouts seems to be asking yet.