AI training requests need a diagnosis first

“More AI training” is a request that needs a diagnosis

When managers see disappointing AI adoption, Markus McKay-Fleisch often hears the same proposed remedy: “my team isn’t adopting the new tools like I’d hoped, so we need more training to fix it.” McKay-Fleisch, who directs professional services AI enablement at Smartsheet, has spent twenty years in adult education and the last two focused specifically on AI adoption there. Speaking recently at AI4, he proposed a different starting question: “what outcome are you trying to achieve?”

That outcome matters because companies routinely combine several different measures under adoption. Mandatory courses can produce high completion rates while employees barely use the product. Frequent AI use can create a different problem when employees routinely select the most expensive models until finance asks enablement to reduce consumption. Employees can also rebuild their own workflows successfully while those practices remain isolated and never spread through the organization.

Those examples separate completion, usage, spending and improvement in the work because each can move independently. A request for “More AI training” becomes useful once leaders establish which measure is disappointing and what employees should be able to accomplish as a result. Until that diagnosis exists, excellent learning metrics can coexist with an unchanged business problem.

The evidence points to an application gap

That distinction between learning activity and work outcomes appears in Docebo’s 2026 AI Readiness Gap report. Learning-software company Docebo, which has a commercial interest in organizations investing in learning, fielded the research through Centiment among 2,000 respondents across the US, UK, Canada, France, Germany and Italy. It found that 85% said the training they received did not help them use AI in their role. One in five respondents received no AI training, so some of that 85% were describing absence of instruction; even after conceptually setting that group aside, a majority had received something they could not translate into their work.

The way learning teams use AI helps locate part of that application problem. Among learning leaders in the Docebo research, 79% use AI for tasks including content generation, while only 9% said their organization had used AI to redefine a workflow. Learning functions can become much faster at producing material while the underlying job, its handoffs and its decisions remain much as they were. Faster course production has limited effect when the problem sits in the design of work.

The leadership view adds another measure of the same broad readiness problem. Grant Thornton’s 2026 AI Impact Survey covered 950 business leaders across ten industries plus private equity, with fieldwork running from February 23 through March 18. Only 12% considered their workforce fully ready for AI, another 81% described it as fairly or mostly ready, and 97% acknowledged some form of adoption challenge. Leaders can therefore perceive broad readiness while still reporting obstacles to adoption.

Those leaders also identify training as a genuine constraint, which gives diagnosis a practical purpose. Governance and compliance led their explanations for AI underperformance at 46%, while insufficient training came second at 31%. Around 34% also identified training as their organization’s most underfunded investment area. AI instruction can deserve more investment even when weak results have another primary cause.

Grant Thornton’s interpretation sharpens the distinction: awareness training produces familiarity, while capability requires people to perform the work. Docebo’s findings separately show employees struggling to apply what they receive and workflow redesign remaining uncommon. For L&D, the useful decision is which obstacle a learning investment is expected to remove.

Diagnose the work before prescribing learning

Finding that obstacle starts with the work outcome because generative AI is changing a longstanding reason for software instruction. For roughly thirty years, corporate training devoted substantial effort to platform knowledge: where buttons had moved, which features existed and how navigation worked. Microsoft alone generated a small industry around this kind of instruction. Generative AI increasingly makes language the interface, so users can describe a desired outcome and often direct a “how do I” question to an embedded assistant or a general-purpose model using public help documentation.

As that interface changes, McKay-Fleisch argues that the remaining barriers increasingly concern organizational understanding and human judgment. He distinguishes workflow redesign, which changes how an outcome is achieved, from AI transformation, which includes the structures, roles and skills surrounding that work. Enablement teams can teach skills, but changing a department’s approval chain, assigning ownership and imposing review standards generally require authority elsewhere. Curriculum design consequently starts by identifying which kind of barrier is present.

The first condition is an outcome that was never named. A leader can report that usage has increased or declined while lacking a specific result the team should now be able to achieve. Employees then experiment without a work target, and their activity is eventually interpreted as weak adoption because nobody established a work-level definition of success. McKay-Fleisch’s intervention is a working session with the leader to define one measurable outcome and work backward to the capability required to produce it.

Once an outcome exists, the second condition is an unchanged workflow. AI may enter a process whose structure reflects constraints that AI has removed, such as approval chains sized around old drafting times, handoffs created because two people once worked in different tools, or review cycles built around human error patterns instead of the errors models make. The process can then penalize employees for the speed the new system creates. McKay-Fleisch recommends process mapping with the function that owns the workflow because enablement lacks unilateral authority to redesign it.

Where the workflow itself works, a third condition appears when useful expertise already exists but does not travel. A wide performance spread among colleagues using identical tools signals that power users may have developed effective methods while those methods remain in personal project files and browser tabs. Another broad session then spends learning time on people who have already solved the problem. McKay-Fleisch instead recommends extracting those practices, distributing them and embedding power-user knowledge into what enablement produces.

Smartsheet’s own use of Claude Projects shows how those isolated solutions can expose an ownership problem as well. McKay-Fleisch examined more than 50 separate employee projects across finance, customer support, sales and HR, all trying to produce on-brand presentations and collateral. None of those 50-plus projects came from marketing. Employees had recognized a genuine need and independently built solutions without recognizing that the expertise, source material and capacity to maintain the solution already belonged elsewhere in the organization.

That duplication goes beyond prompt quality because the missing capability is organizational knowledge. Better instructions to a model do not teach an employee to identify the organizational owner of a problem before creating another local solution. Employees also need to understand where authority and durable expertise sit, then connect a useful local experiment to them. Once that knowledge is identified, training can distribute it; ownership itself remains an organizational decision.

The fourth condition is a breakdown in review discipline. McKay-Fleisch calls unchecked, inexpensive generation a “slop cannon”: people can create large amounts of material at minimal cost and send it onward without evaluating it themselves. Producer metrics can improve because volume rises and cycle time falls, but the cost of checking the output then moves to its recipients. Complaints from those recipients can therefore reveal a problem hidden by the producing team’s productivity measures.

Research from BetterUp Labs and Stanford’s Social Media Lab, published in Harvard Business Review last September, measured a related phenomenon the researchers called “workslop.” Forty percent of employees said they had received workslop during the preceding month. Each incident took the recipient roughly two hours to deal with, valued by the researchers at about $186 per employee per month. Cheap generation changes the economics of review by shifting some of its cost to the recipient.

That cost transfer can also weaken review quality because recipients did not choose the work, cannot necessarily see its original intent and may lack a route for returning it. McKay-Fleisch’s intervention is a pre-handoff review standard enforced by managers. He also recommends confronting high-volume producers with the downstream cost embedded in their apparently strong metrics. The management decision is then explicit: determine where accountability for quality sits.

These four conditions give the initial training request a more precise meaning. Weak usage can begin with an undefined outcome; AI inserted into old processes calls for workflow work; isolated power users and dozens of overlapping personal projects expose knowledge and ownership problems; unreviewed output shifts costs downstream. Excessive use of costly models can likewise require guidance tied to the specific behavior finance wants changed. The intervention follows from the operational state rather than the generic label of weak adoption.

Some “skills gaps” come from architecture

The diagnosis also has to reach technical architecture because identical user behavior can produce different results depending on where an employee uses AI. One employee might work through an assistant built into an application, trained on that platform’s documentation and operating with the user’s actual data. Another might use a general-purpose model that reaches the same platform through a connection protocol, meaning a standard way for systems to exchange requests and information. Differences between those environments can appear to the employee as a “skills gap” problem even when the underlying system is driving the result.

McKay-Fleisch uses a concrete task to expose that distinction: ask AI to build a dashboard identifying projects that are on track, at risk or overdue, grouped by portfolio and owner. His position is that the result should be identical regardless of which AI surface, or user-facing AI interface, receives the request. On many platforms today, it is not. Prompt instruction cannot correct an outcome difference created by the underlying architecture.

When architecture creates the difference, enablement can still guide use without treating instruction as the primary remedy. Its team can establish which AI surface reliably produces which work outcome and direct employees to that surface for the corresponding task. Sending people indiscriminately toward inconsistent interfaces teaches a different lesson because repeated failures can lead employees to conclude that AI tools as a category are unreliable. Another surface may have completed the same task successfully.

The next technical variable is the context the platform supplies for the user. Giving a general-purpose model access to business data gives it the data, while meaning, structure and application-specific behavior may still have to be supplied separately. Some platforms provide that understanding server-side through reusable instruction sets shared by connected users. Smartsheet calls its implementation “native skills,” according to McKay-Fleisch.

Because McKay-Fleisch works inside Smartsheet, his description of “native skills” is also a vendor’s account of its own implementation and its value. Server-supplied context reduces how much application knowledge employees must express themselves. Where a platform leaves that work to the user, prompt and context engineering become load-bearing skills; context engineering means supplying the information and instructions a model needs to interpret and complete a task reliably. In that environment, substantial training is a technical requirement tied to the system design.

That architecture decision feeds directly back into curriculum design. L&D and enablement leaders need to establish how each vendor supplies application and data context because the answer determines how much knowledge employees must provide themselves and which AI surface fits a particular outcome. The Grant Thornton finding that training is underfunded remains relevant here: additional funding can target cases where the architecture leaves critical context work to employees.

The organizational mismatch lands hardest below senior leadership

Technical deployment also helps explain why executives can disagree sharply about whether the same workforce is prepared. Grant Thornton found that 39% of CIOs and CTOs described their workforce as fully ready for AI, compared with 7% of COOs, a 32-point gap. Technology leadership often sees deployment, functioning integrations and logged usage. Operations is more likely to judge readiness by whether the work itself improved.

That difference in perspective continues when leaders identify who most needs support. Grant Thornton reported the following distribution:

The support pattern matters because the people making organizational decisions report considerably less need for help among senior leadership than among the groups living with those decisions in daily workflows. Framing readiness primarily as an employee capability deficit then directs remediation toward frontline staff and middle managers. The outcome, workflow, ownership, review practice and technical setup can remain unchanged while employees receive another program.

That response also fits the way AI enablement is commonly funded as tool training even though the historical platform-knowledge barrier is changing. When L&D receives a request generated by a process, architecture or management problem, its available mechanism can shape the diagnosis. Problems that sit with operations, technology or management can consequently arrive as requests to teach employees something. Ownership has to be established before that request can become a useful intervention.

Give workflow redesign an owner, then decide what to teach

The ownership question becomes concrete with AI workflow redesign. McKay-Fleisch recommends explicitly identifying who owns that work; at Smartsheet, he held that responsibility for a period before the company hired someone into the role. Many organizations have no such explicit owner. When redesign belongs to nobody, requests migrate toward nearby L&D and enablement teams even though those functions may lack authority over the processes that need to change.

From that ownership problem, McKay-Fleisch makes a specific organizational prescription: HR should claim workflow redesign deliberately, together with the required budget and authority. His case rests on what redesign determines: which roles will exist, what those roles will require and which employees have routes into them. Technology decisions can create role consequences, turning workflow design into a people decision. In his view, HR should act before organizational ownership settles elsewhere and leaves the function accountable for capability without corresponding control over work design.

For an enablement team, that prescription translates into a narrower operating rule for the next request. First ask for a measurable work outcome; then identify the workflow containing that outcome and the person or function that owns it. Those answers establish whether the intervention belongs with learning, process design, management or technology. When they point to learning, the team can finally specify what employees need to be able to do and design targeted instruction around that work.

Main highlights

• Diagnose AI training requests: L&D teams can start with the measurable work outcome a manager wants to improve. Completion, usage, spending and business performance can move independently, so the target determines whether training is the right intervention.
• Close the application gap: AI training often fails to translate into employees’ daily work, while workflow redesign remains uncommon. Learning teams can tie instruction to specific job capabilities and measure whether employees perform the work differently afterward.
• Diagnose the work first: Undefined outcomes, outdated workflows, isolated expertise and weak review practices can all appear as adoption problems. The function that owns the affected workflow can identify the constraint before L&D commits resources to another program.
• Account for AI architecture: AI interfaces can produce different results from the same request because platforms supply different data, context and application knowledge. Technology and enablement teams can test AI surfaces against specific work outcomes and train employees on the context they actually need to provide.
• Reconcile readiness across leadership: Technology leaders may see successful deployment while operations sees work that has barely improved. CIOs, CTOs and COOs can align readiness measures around workflow outcomes and employee performance rather than relying primarily on availability or usage.
• Assign workflow redesign explicitly: AI workflow redesign needs an owner with the authority to change processes, roles and responsibilities. HR can claim that role where appropriate, while L&D focuses its investment on capability gaps that instruction can actually address.