Your AI Training Request Is a Diagnosis Problem
Wrong Diagnosis: AI training requests often mask unclear outcomes, broken workflows, stranded expertise, or weak review discipline.
Limited Impact: 85 percent of employees say AI training does not help them apply tools effectively in their roles.
Workflow Ownership: Successful AI adoption requires redesigning processes and assigning ownership beyond enablement teams.
Hidden Costs: Unreviewed AI output shifts evaluation work downstream, wasting recipient time and reducing trust across teams.
Strategic Role: HR should lead AI workflow redesign because technology changes reshape roles, skills, budgets, and career paths.
A manager knocks on the enablement director's door. The message is always some version of “my team isn't adopting the new tools like I’d hoped, so we need more training to fix it.”
Markus McKay-Fleisch has spent twenty years in adult education and the last two focused specifically on AI adoption at Smartsheet, where he directs professional services AI enablement.
Speaking at AI4 recently, he described the request as the most common request he fields and the one most likely to be misread. His response is a question rather than a course catalog: what outcome are you trying to achieve?
Create a Free Account to Keep Reading—and Keep Leading Smarter
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
A training request is a symptom. It arrives already carrying a diagnosis, and the diagnosis is usually wrong.
The tell is in the data that enablement teams already have. Completion rates look strong, often because the training is mandatory. Usage tells a different story.
In some organizations people barely touch the tools. In others they touch them constantly, default to the most expensive models available, and finance shows up asking for training that will pull consumption back down. Both patterns generate the same request. Neither one is a knowledge problem.
There are bright spots but they’re often isolated. The people rebuilding their own workflows and getting genuinely transformative results? Too often, that knowledge sits where it was created and does not travel.
The Training is Landing and It Isn't Working
Docebo's 2026 AI Readiness Gap report, fielded by Centiment across 2,000 respondents in the US, UK, Canada, France, Germany, and Italy, found that 85% of employees say the training they receive does not help them use AI in their role.
Docebo sells learning software, which is worth noting given the direction the finding cuts, but for the sake of this discussion, let’s presume that number holds, because based on the mood in the room at McKay-Fleisch’s talk, I’d say that it doesn’t feel too far afield from reality.
One in five of those respondents received no AI training at all, which means a portion of that 85% is describing an absence rather than a failure. Set that group aside and the number still describes a majority of employees who sat through something and came out unable to apply it.
The more revealing figure is on the other side of the survey. Among learning leaders, 79% report using AI for tasks like content generation. Only 9% say their organization has used AI to redefine a workflow.
Learning functions have absorbed AI as a production accelerator. They are making the same courses faster. The work of rethinking how the job itself gets done sits almost entirely undone, which is a reasonable description of why the courses aren't landing.
Language is the Interface
For thirty years, corporate training existed largely to solve platform knowledge. Software vendors moved buttons, added features, changed navigation, and someone had to teach people where things went. Microsoft alone generated a small industry of this.
Generative AI removed the barrier that justified most of that curriculum. The interface is language. A user describes the outcome they want and the system assembles the steps. The "how do I" question, which was the spine of enablement, can now be asked directly of the tool, inside the application or through a general-purpose model pointed at public help documentation.
What remains as the actual barrier, in McKay-Fleisch's reading, is organizational understanding and human judgment.
The organizational understanding problem has a clean illustration in his own company's usage data. Digging through Smartsheet's Claude Projects data, he counted more than fifty separate projects built by employees across finance, customer support, sales, and HR, all of them attempting to generate on-brand materials. Presentations, collateral, the usual.
What’s notable is that not one of those projects came from the marketing team. The function that owns the brand had built nothing, and the fifty-plus people solving around it had not thought to ask.
Each of those employees identified a real problem and used a capable tool to address it. What none of them did was recognize the problem sat inside someone else's domain, where the expertise, the source materials, and the ability to maintain the thing over time already lived. That is not a prompting deficiency. No course on writing better instructions produces the instinct to go find the owner.
Human judgment is the larger category, and McKay-Fleisch narrows it to the failure mode most organizations are living with right now. He calls it the “slop cannon.” People generate output at close to zero cost and send it out without reviewing it, which relocates the work of evaluation onto whoever receives it.
The discernment task of understanding the output you’re getting, making sure it’s accurate, making sure it’s valuable. What’s happened with this slop cannon mentality is that that task falls on the people who it’s being sent to, and that’s not appropriate.
BetterUp Labs and Stanford's Social Media Lab put numbers on that transfer in research published in Harvard Business Review last September. Forty percent of employees reported receiving what the researchers termed “workslop” in the previous month. Each incident consumed roughly two hours of the recipient's time, which the researchers valued at about $186 per employee per month.
The review step did not disappear. It moved downstream to someone who did not choose it, cannot see the original intent, and has no way to send it back.
Redesign and Transformation are Different Budgets
McKay-Fleisch draws a distinction most enablement funding ignores. Workflow redesign is how you get to an outcome. AI transformation is everything that has to change around it, meaning the organizational structures, the roles, and the skills people need to hold those roles.
Most AI enablement is funded as if it is neither. It's funded as tool training, which was the correct answer to a barrier that no longer exists.
Grant Thornton's 2026 AI Impact Survey, covering 950 business leaders across ten industries plus private equity and fielded between February 23 and March 18 of this year, found that only 12% of leaders consider their workforce fully ready for AI. Another 81% land somewhere in fairly or mostly ready, and 97% acknowledge adoption challenges of some kind.
Asked why AI initiatives underperform, those leaders put governance and compliance issues first at 46%. Insufficient training comes second at 31%. Around 34% name training as the organization's most underfunded investment area.
So the diagnosis executives are making, at scale, is the same one arriving at the enablement director's door. Not enough training. Fund more of it.
Grant Thornton's own read on that is worth holding onto. Awareness training produces familiarity rather than capability. Familiarity is exactly what most AI curricula are built to deliver, and it is what 85% of Docebo's surveyed employees are describing when they say the training didn't help them do the job. The money is going somewhere. It is going to the intervention that requires the least structural change from the people approving it.
Docebo's 9% is the same finding from the other direction. Learning functions have adopted AI enthusiastically for making content and have barely touched the redesign of work. I would translate that as both budgets are being spent on the redesign side of nothing.
Four Things the Request Means
When a leader asks for training, one of four conditions is usually underneath it. Each has a signal that identifies it and a response that is not a course.
The outcome was never named
The signal is that the leader cannot answer the question about what success looks like without describing activity. Usage is up, or usage is down, but nobody can say what the team is supposed to be able to do that it couldn't before. People experiment toward nothing in particular and the experimentation reads as failure to adopt.
The intervention is a working session with the leader to define one measurable outcome, then working backward to the capability that serves it.
The workflow was never redesigned
The signal is AI bolted onto a process that was built around a constraint the AI removed. Approval chains sized for the time drafting used to take. Handoffs that existed because two people had different tools. Review cycles calibrated to human error patterns rather than model error patterns.
People use the tool inside a process that punishes them for the speed it creates. The intervention is process mapping with the function that owns the workflow, and it is not your enablement function’s to do alone.
The expertise exists and is stranded
The signal is a wide performance spread within the same team using the same tools. Power users have solved the problem already. Their solutions live in personal project files and browser tabs.
The intervention is extraction and distribution, which McKay-Fleisch frames as embedding power-user knowledge directly into whatever enablement produces rather than running more sessions past people who have already figured it out.
Review discipline collapsed
The signal is the “workslop” pattern, complaints about output quality that come from recipients rather than producers. The producing team's metrics look excellent. Volume is up, cycle time is down, and the cost has been pushed onto the next desk.
The intervention is a standard for what gets reviewed before it moves, enforced by managers, plus the uncomfortable work of telling high-volume producers their numbers are partly someone else's problem.
None of the four is solved by a curriculum. Three of them are not enablement's problem to own alone, which is exactly why they keep arriving at enablement's door.
Same Prompt, Two Answers, and a Training Program That Can't Fix It
There is a technical layer under all of this that most people leaders have been encouraged to ignore, and ignoring it produces bad enablement.
Employees encounter AI on multiple surfaces. There is the assistant built into an application, trained on that platform's documentation and operating inside the user's actual data.
There is the general-purpose model, reaching the same platform through a connection protocol. McKay-Fleisch's example is a request to build a dashboard showing which projects are on track, at risk, or overdue, grouped by portfolio and owner.
His position is that the result should be identical no matter where the user types it. On many platforms it currently isn't.
That difference is system architecture and prompt training cannot close it. What enablement can do is know which surface produces which outcome and tell people plainly: for this task, go here.
Skip that and you teach employees that the tools are unreliable, which is a lesson they will apply broadly and remember longer than anything in the curriculum.
The second technical variable is how much context the platform supplies on the user's behalf. A general-purpose model connected to business data does not inherently understand what that data means, how it is structured, or what the application does with it. The better platforms are loading that understanding server-side, packaged as reusable instruction sets that every connected user benefits from without knowing they exist. Smartsheet does this with what McKay-Fleisch calls "native skills".
The enablement consequence is direct and budgetary. Where the platform carries the context, the amount of prompt instruction users need drops sharply. Where it doesn't, prompt and context engineering are load-bearing skills and the training has to cover them properly.
Enablement leaders should be asking vendors which of those two worlds they are in. The answer determines a meaningful share of the curriculum.
Two Readings of the Same Organization
That 12% fully-ready figure conceals a split. Among CIOs and CTOs, 39% describe their workforce as fully ready. Among COOs, the figure is 7%.
Technology leaders are measuring system-level adoption. Licenses deployed, integrations live, usage logged. Operations leaders are measuring whether the work got better. The thirty-two point spread represents significant work to be done in answering those two questions.
The distribution of where support is needed sharpens it. Frontline employees account for 37% of where leaders say support is most needed. Middle managers account for 30%. Senior leadership accounts for 8%.
The people making decisions about AI feel supported. The two-thirds of the organization living with those decisions do not.
That is the pattern underneath the training request. A leader who feels adequately equipped observes a team that is not, and reaches for the intervention that requires nothing of the leader. More training is a request that can be granted without the requester changing anything about how the work is structured, who owns which decision, or what the team is being asked to produce.
Almost nobody in that sample disputes that something is wrong. The disagreement is about where it lives.
HR Should Claim This Before It Defaults
McKay-Fleisch's closing recommendation to the room was to go back and identify who in the organization owns AI workflow redesign. He noted it was him for a stretch, until Smartsheet hired someone into the role.
In most companies, the honest answer is nobody. And when nobody owns it, the work does not disappear. It flows to whoever is closest, which is usually L&D or enablement, arriving one training request at a time with no mandate and no authority over the processes actually in need of redesign.
Inheriting it that way is the worst version of owning it. HR should claim workflow redesign deliberately, with the budget and the authority attached, because the alternative is holding the accountability without either.
The case for HR holding it is not sentimental. Workflow redesign determines which roles exist in three years, what those roles require, and who inside the company has a path into them. Those are people decisions being made as a byproduct of technology decisions. Leaving them to be settled by whoever happens to be configuring the tools is a choice, and it is the choice most organizations are currently making by default.
The function that understands how work is structured, how capability gets built, and what happens to people when both change is the function that should be at the front of this. That claim has to be made before the org chart hardens around someone else.
What to Ask
When the next team leader knocks, do not open the course catalog. Ask two questions.
- What outcome are you trying to achieve? Not more adoption, not higher usage. Something you could measure in the work itself.
- Which workflow does that outcome live in, and who owns it?
If the leader can answer both, you have something to build. If they can't, the training was never going to work, and the most useful thing a person in an enablement function can do is say so out loud.