AI Training for Non-Technical Teams That Actually Sticks
Most AI training teaches people what AI is. Almost nobody needed that. Here is what they did need.
Erin Moore
Fractional Chief AI Officer
Train people on their own work, not on AI. A ninety-minute session using the team's real documents, real tickets and real constraints changes behaviour; a generic course on how large language models function does not, however well produced it is.
That is the whole finding, and almost every failed enablement programme violates it.
Why generic training fails
It teaches a vocabulary rather than a capability. People leave able to define a token and unable to draft next week's report any faster. There is no transfer, because the examples were not theirs.
It is also pitched at the wrong problem. Non-technical staff are rarely blocked by not understanding AI. They are blocked by not knowing which of their tasks is a candidate, by not trusting the output, and by not knowing what they are allowed to do — which is a policy failure wearing a training costume, and a large part of why employees hide AI use.
The four things they actually need
Which of my tasks is this for. Not a taxonomy — a list, generated by the team from their own week. The single most valuable exercise in any session is people naming their own candidate tasks out loud, because it produces both the curriculum and the adoption list at the same time.
How to tell when the output is wrong. This is the skill that matters most and is taught least. It is domain-specific: what a bad contract summary looks like differs entirely from what a bad support reply looks like. Teach it by showing three plausible-but-wrong outputs from their own domain and asking the team to find the problem.
What I'm allowed to do. Concretely. Which tools, which data, what needs review, who to ask. If this is vague, cautious people do nothing and confident people do whatever they like. Your acceptable use policy should be short enough to cover in five minutes.
How to ask for what I want. The practical craft — context, constraints, examples, iteration. Fifteen minutes on their own tasks beats a prompt-engineering course, and the skill transfers on its own once people see it work.
How to structure it
Ninety minutes, by team, with their material open. Not a company-wide session — the whole value is in the specificity, and it evaporates the moment the examples become generic.
Run it as: ten minutes on what is permitted, twenty on the team listing candidate tasks from last week, forty actually doing two of them live with the tool, twenty on spotting bad output. People leave having done the thing once, which is the only reliable predictor of doing it again.
Then follow up at two weeks. Adoption dies in the second week, when the novelty is gone and the old habit is still faster. A short session on what worked and what did not is worth more than doubling the original training — the pattern in AI change management and how to get your team to use AI.
What to measure
Not completion rates or satisfaction scores. Measure whether the tasks the team named are being done differently a month later, and ask the manager, not the tool's dashboard. Licence telemetry tells you about logins; it does not tell you whether anyone's work changed. The metrics worth tracking are in AI adoption metrics.
Who should deliver it
Someone from the team who has already done it, supported by whoever owns the policy. Externally delivered training generalises by necessity, which is exactly the failure mode. The most effective structure is usually to train two people per team properly and let them run the sessions.
NIST's AI Risk Management Framework treats workforce capability as a govern function rather than a training line item, and the distinction is practical: this is about who is competent to make judgements, not about who attended.
Frequently asked questions
Why does AI training usually fail? Because it teaches what AI is rather than how to do the participants' own work with it. Without their real documents and tasks in the room, there is no transfer.
What should non-technical teams actually learn? Which of their tasks are candidates, how to recognise a wrong output in their own domain, what they are permitted to do with which data, and the practical craft of asking for what they want.
How long should a session be? About ninety minutes per team, with their own material open, most of it spent doing real tasks live. Then a short follow-up at two weeks, when adoption typically dies.
How do we measure whether it worked? Ask whether the tasks the team named are being done differently a month later. Completion rates and licence logins measure attendance and access, not behaviour change.
Further reading
Tagged with:
Ready to Automate Your Business?
Let's discuss how AI automation can deliver measurable ROI for your organization in 90 days or sooner.