The module gets completed. The work does not change.
The pattern is familiar enough that most L&D teams recognise it before it finishes. A company-wide AI session is commissioned, attendance is strong, completion is reported, and the following Monday everybody does their job exactly as they did the Friday before.
People finish the module. Almost nothing changes about how they actually work the next day.
That is Judge Group's description, and their diagnosis is the important part: this is not a motivation problem or a content-quality problem, it is a design problem. Their sharper version of it is the sentence worth keeping, that generic AI training was never going to produce specific behaviour change, because the jobs it is trying to change are not generic either.
Why the generic version cannot work, structurally
Three things go wrong, and they compound.
- The question is too abstract to answer. Ask a mixed room how AI could help their job and most people go blank. Not because it could not, but because the question does not map onto anything in their actual day.
- The examples belong to nobody. A demo prompt written for a generic knowledge worker is written for an average that does not exist, so it lands as mildly interesting rather than as something to use on Tuesday.
- The failure erodes trust. Someone tries the example prompt, gets a mediocre result because it was not built for their workflow, and concludes the tool does not really work for what they do. That conclusion is much harder to reverse than the original ignorance was.
The third one is the expensive one and it rarely gets counted. A generic session does not merely fail to help. It can inoculate a team against the tool, and the next attempt now has to overcome a prior belief rather than a blank slate.
Role-based is not the same as a track per job title
The market's answer to generic training has been role-based catalogues: a track for marketing, a track for finance, a track for engineering. That is better, and it is not the same thing, because a job title is not a job.
Two people with the same title in the same company can have entirely different weeks, different tools provisioned, and completely different things blocking them. Assigning both the same track because they share a title reproduces the original problem at a smaller scale.
Real role-based enablement starts three levels lower than the title:
- The tasks that role actually performs, in the order the week actually runs, including the steps nobody documented.
- The tools that person already holds a licence for, rather than the tool the training was built around.
- The specific capability that is missing for that person. Prompting, tool literacy, workflow integration, judgment and influence fail independently of each other, and the fix for one does nothing for another.
You cannot plan role-based enablement without a role-based measurement
This is the part that usually gets skipped, and skipping it is what turns role-based enablement back into a catalogue. If you do not know which capability is missing for which person, the only thing left to route on is their job title, which is where you started.
Consider two people on the same team with the same overall score. One is a confident, fast prompter who verifies nothing. The other verifies everything and has never moved AI into the shape of their week. Send both to the same role-based session and you have helped neither: the first needs a verification habit, the second needs their workflow redesigned. The average of the two needs nothing at all.
So the sequence is fixed, and it is the opposite of how most programmes run. Measure per role, then design. Not design, deliver, and measure attendance.
What the measurement has to produce for enablement to be plannable
- A read per capability rather than one score, because a single number cannot be routed on.
- A read against what the role needs rather than against a company bar, so that strong for this job is distinguishable from strong in general.
- The barrier the person actually named. It is frequently not skill. Unclear policy, fear of being seen to use it, and a tool that is genuinely wrong for the task all look identical from the outside and only one of them is fixed by training.
- Something aggregate. If eleven people in one team share the same missing capability, that is a session. If eleven people have eleven different gaps, that is coaching, and running the wrong one of those two wastes either money or time.
That last distinction is worth being deliberate about. The instinct is always to run a session, because a session is visible and schedulable. The evidence should decide it.
The size of the problem
38%named user proficiency as the single largest challenge in AI adoption, more than double technical integration at 16 percent and organisational adoption at 15 percent. (Prosci, Keys to Unlocking AI Adoption, 1,107 participants)
Proficiency being the top blocker is the case for enablement existing at all. It is also the case for measuring it properly, because it is the one blocker that produces no signal in any system you already own, and a budget aimed at a problem nobody has measured tends to be aimed by whoever argues most confidently.
How to run it
- Pick one team and write down what good looks like for each role in it, at the level of tasks rather than competencies.
- Measure each person against their own role, per capability, before designing anything.
- Sort the gaps into systemic and individual. Systemic gets a session built around that team's actual work. Individual gets coaching in the flow of the work.
- Build every example from that team's real tasks and their own provisioned tools. An example from someone else's job is the generic problem wearing a role-based label.
- Re-run the same measurement at ninety days. Completion is not evidence. Movement is.
Where the plan comes from
AI Litmus is AI adoption software that produces this rather than a course. It learns every role you employ and every tool assigned to it, reads each person against their own job across five capabilities, names the barrier they actually reported, and turns that into the enablement move for each team. Coaching happens in the flow of the work rather than in a session. The companion reads are whether your team is using AI well and the AI maturity model that measures people.
Frequently asked
Why does generic AI training fail? Because generic training cannot produce specific behaviour change when the jobs it is trying to change are not generic. Three things compound: asked how AI could help their job, most people in a mixed room go blank because the question is too abstract to map onto their day; example prompts written for an average worker land as interesting rather than usable; and someone who tries one, gets a mediocre result and concludes the tool does not work for them is now harder to help than before the session.
What is role-based AI enablement? Enablement built from the tasks a specific role actually performs, the tools that person already holds a licence for, and the specific capability they are missing. It is not a course catalogue with a track per job title. Two people sharing a title can have different weeks, different tools and different blockers, so routing on the title reproduces the generic problem at a smaller scale.
Why does enablement need a measurement first? Because without knowing which capability is missing for which person, the only thing left to route on is job title. Two people with the same overall score can need opposite interventions: a fast prompter who verifies nothing needs a verification habit, while someone who verifies everything but has never integrated AI needs their workflow redesigned. Sent to the same session, neither is helped.
Should AI enablement be a training session or coaching? It depends on whether the gap is systemic or individual, and that is a question the measurement answers rather than the calendar. If most of a team shares the same missing capability, a session built around that team's real work is efficient. If the gaps are scattered, a session teaches most people something they did not need, and coaching in the flow of the work is the cheaper route.
What should an AI enablement plan contain? A read per capability rather than one score, scored against what each role needs rather than a company-wide bar. The barrier each person actually named, since unclear policy, fear of being seen using AI and a genuinely wrong tool look identical from the outside and only one is fixed by training. An aggregate view so systemic gaps can be separated from individual ones. And a re-run date, because completion is not evidence of change.