We had to replace our oven a few months ago. Not a choice, really, the old one gave up, and I am a mad baker so cannot live without an oven.
 

The new oven is a marvel. We didn’t spend top dollar, but just being modern it has touchscreen and some cool features. An air fryer mode built right in. Different baking modes and fancy self-cleaning. I am still overwhelmed with something like fifteen cooking modes, most of which I could not describe to you under oath.

Do you know what I use it for?

Bake. 180. Done.

Same as the old oven. Because at 6pm on a Tuesday, with hungry teenagers keen for dinner, I do not have the spare brain to work out what “moisture plus” is for. The old way is the known quantity, and requires nothing of me. Learning the new modes means looking things up, getting a timing wrong, producing something slightly disappointing, and doing it in front of my family. Not keen!

The capability arrived. The habit didn’t.

I’ve been thinking about that oven a bit because I think organisations often roll out AI the same way.
The capability turns up (often inside tools people already have, whether they asked for it or not) and we assume the value comes with it.

Though this is also where my oven lets me down as a metaphor. My oven will have exactly the same fifteen modes next year. It’ll behave the same way in November as it did in March. AI won’t, and that turns out to matter quite a lot.
 

It’s not a software roll-out, and that’s the problem

We know how to do software rollouts and find there’s a comfortable shape to them.
Scope it, configure it, pilot it, train everyone, hypercare for a few weeks, close the project, hand it to BAU, celebrate. I feel like this was 10 – 15 years of my change management life. Clear cut, rinse and repeat… to an extent.

That shape works because traditional software is finite with a defined set of things. You can document those things. The tool you trained people on in March is the same tool in November. While this has changed a lot over the last decade with Software as a Service and the calendar of updates, there is still an overarching sense of it and method to using it that can be consistent with a group of users.

AI isn’t that, in a few ways that really matter.

It changes underneath you
The model gets better. Features appear. Something that failed embarrassingly six months ago works beautifully now, and nobody told the person who tried it, got a bad answer, and quietly decided it wasn’t for them. There is no “final” training deck. The material is out of date the moment you publish it, and that’s not a failure of your instructional design, it’s the nature of the thing. It can be so frustrating and hard to keep up with.
 

You can’t specify the value up front
With most software, you buy a defined outcome. Invoices get processed, tickets get routed.
With AI you’re buying a capability, and the actual value gets discovered by the person using it, doing their particular job, in week six, when they think “hang on, could it do this too?”.
That’s genuinely difficult for a business case. It’s genuinely difficult for a steering committee that wants to know what success looks like before you start.
 

And there’s no finish line
This is the one I’d underline. The set-and-forget instinct is so strong, and it’s completely reasonable given how we’ve always done this. But closing the project at go-live, for AI, is closing it at the exact point where the learning needs to start.
 

Which brings us to the people

There’s a second reason the software-rollout shape doesn’t fit, and it’s the one that gets labelled resistance.

Adopting AI into your actual daily work means unpicking habits you’ve built over years, and those habits are load-bearing. You know how you write a proposal. You know your process for prepping a meeting. It’s automatic, it’s efficient, and on a busy day it is the only reason you’re functioning.

Asking someone to use AI for that task is asking them to take a familiar, automatic thing and make it effortful and awkward again. Temporarily worse, in the hope of eventually better. That’s a genuine cost, and we tend to wave it away as a mindset issue.

Which is a whole post of its own, and I’ll come back to it properly. For now the point is just this: the discomfort isn’t a barrier to get past before the real work starts. The discomfort is the work.

So what does that ask of us?

Two things, I think, and neither is a training problem exactly.

Stop designing for a finish line. If the thing keeps changing, the support has to keep going — the nudge, the prompt, the reason to come back and try it again now that it works better than it did last time. Go-live isn’t the end of the project. It’s roughly the beginning.

And stop teaching features. Start with the task the person actually dreads, and work backwards from there. One thing that genuinely saves them time on a Thursday will do more than a full tour of the capability.

I did eventually learn the air fryer mode on the oven. Not from the manual, which I have never opened. From someone showing me the one thing I’d actually want it for, on a night I happened to have ten minutes spare.

Everything else is still bake, 180, done. And honestly, that’s fine. One thing that sticks beats fifteen modes nobody touches.