A leadership team announces that the organisation will "reskill the workforce for AI." A budget line appears. A platform gets bought, the one with ten thousand courses nobody asked for. Everyone is enrolled. A dashboard somewhere lights up green when completion rates climb. Six months on, the work is being done exactly as it was before, except now there's a slide that says the workforce has been reskilled.
I've watched this play out enough times to recognise the shape of it before it finishes. The tell is that the programme measures whether people watched things, not whether anything changed. And reskilling, the real kind, is not a content-delivery problem. It's a change-of-behaviour problem, and behaviour is the most expensive thing in any organisation to shift.
Training is not reskilling
Let me draw the line clearly, because the whole confusion lives here.
Training is when someone learns what a tool does. Reskilling is when someone's actual job changes and they're capable of doing the new version of it. The first is a webinar. The second is months of doing real work differently, with support, while still being expected to deliver.
A two-hour session on prompting an LLM is training. It is genuinely worth doing and it changes almost nothing on its own, because the moment people return to a workflow, a backlog, and a manager measuring them on the old output, they revert. The pull of how-we've-always-done-it is enormous, and a certificate does not counter it. What counters it is changing the work itself — the templates, the definition of done, what gets reviewed, what gets rewarded — so that using the new capability is the path of least resistance rather than an extra thing to remember on top of a full day.
If your programme didn't touch the actual workflow, you ran a training programme and called it reskilling. They are not the same line item, and they don't cost the same.
The realities nobody budgets for
Three things get systematically underestimated. I'll be specific.
- Time. Reskilling is not free time appearing from nowhere; it's productive hours spent learning instead of delivering, which means output dips before it recovers. A team genuinely changing how it works will be slower for a stretch. If you haven't planned for the dip and protected people through it, you've designed a programme that punishes the very people taking part — they fall behind on their normal targets while doing the thing you asked.
- Managers. This is the one that decides everything, and it's the one most programmes ignore. If a manager doesn't change what they ask for and how they assess it, nothing downstream of them changes, regardless of how many courses their reports complete. The manager is the gatekeeper of whether the new skill is allowed to be used. Reskill them first, or accept that you're shouting past the person who controls the day.
- The unglamorous middle. Not everyone is a curious early adopter who'll teach themselves over a weekend. Most of an organisation is competent, busy people who'll engage if it's made genuinely doable and ignore it if it's piled on top of everything else. Design for them, not for the enthusiasts who didn't need you anyway.
Who gets left behind, and the deliberate work of not doing that
Here's the uncomfortable part. "Reskilling" is often the polite word organisations use while a cohort of people quietly gets left behind — usually the ones who've been doing a now-automatable task for fifteen years, are excellent at it, are in their fifties, and have absorbed an unspoken message that the future doesn't include them. The programme technically applies to them. The design does not consider them.
Leaving them behind is rarely a decision anyone makes out loud. It's what happens by default when you don't decide otherwise. So you have to decide otherwise, on purpose. That means looking at who is most exposed before you start, building paths that connect their deep domain knowledge to where the work is going rather than treating them as beginners, and being plain with people about what's changing instead of letting them infer their fate from a vague all-staff email. The domain knowledge in a long-tenured person is often the scarcest asset in the building. Burning it because the retraining was designed for twenty-five-year-olds is an expensive mistake dressed up as progress.
Did it work?
Completion rates tell you nothing. Here's what I'd actually look at, three to six months after the courses end:
- Has the work changed? Pull real artefacts — documents, tickets, code, decks — and check whether they look different from before. If they're identical, the skill isn't being used, whatever the dashboard says.
- Are people using the capability without being told to? Voluntary, unprompted use is the only honest signal that something stuck.
- Did anyone get left behind, measurably? Look at engagement and attrition in the most-exposed groups specifically. A programme that "succeeded" overall while a cohort silently disengaged did not succeed.
Reskilling done properly is slow, costs real money beyond the platform licence, makes the team temporarily slower, and demands that managers change first. None of that fits neatly on a slide. That's precisely why so few organisations actually do it, and why the ones that do will be the ones still standing with their people intact on the other side.
