AI People, Culture & Change

30 MIN READ

AI Upskilling Strategy: Building an AI-Ready Workforce

A skills and upskilling strategy trades training calendars for a taxonomy tracking deepening, redeployment, and adjacent skilling as distinct worker moves.

Most AI transformation programmes don’t fail on the platform; they fail when nobody downstream knows how to run what was built. A skills and upskilling strategy is supposed to close that gap, but most stop at a training calendar instead of a capability system, and the programme plan pays for the difference in months of stalled delivery.

Where this article sits

Journey stage 3 of 7: Roi

readiness → use-cases → roi → pilots → kpis → operationalize → scale

this articlelinkedjourney stagepillar

Your trail so far

The articles you visit light up on this map.

What an AI Upskilling Strategy Is, and Where It Stops Being Training

An AI upskilling strategy is a capability system that records what each role can already do against what the organisation’s AI roadmap requires, using a skills taxonomy rather than a course catalogue; and it stops being training the moment it starts tracking demonstrated capability instead of course attendance. Most organisations skip the taxonomy step and call the course catalogue a strategy, which is why the distinction below carries more weight than it first appears to.

The World Economic Forum’s Future of Jobs Report 2025 puts a number on the disruption underneath that distinction: roughly 39% of core job requirements are expected to shift by 2030. Harvard Business Review’s synthesis of the same body of research puts the more immediate figure at over half the global workforce needing to upskill or reskill just to keep pace with the jobs they already hold (Harvard Business Review). A single figure like that gets treated as one undifferentiated problem, when it actually describes three distinct worker moves.

Josh Bersin draws the sharper distinction at the organisational level: a training organisation procures courses, while a learning organisation owns a taxonomy. That difference in ownership is what separates a skills and upskilling strategy that tracks capability from one that only tracks completion. MIT Sloan Management Review’s reporting on reskilling makes the same point from the individual side; structured capability-building is already replacing old-style, classroom-based training at organisations such as Microsoft, which treated cloud-skills development as a business imperative rather than an HR programme (MIT Sloan Management Review).

Deepening, redeployment, and adjacent capability as three distinct moves

Deepening improves a capability a person already uses, redeployment moves them into a different capability family entirely, and adjacent skilling adds one new capability alongside their existing role; three moves the market habitually compresses into the single word “upskilling.” A data analyst who learns to validate model outputs is deepening. A compliance officer who moves into AI-governance work is being redeployed into a different family of judgment. A product manager who adds prompt-based research to an unchanged core role is adjacent skilling.

The boundary matters because each move carries a different cost and a different time-to-competence. Deepening is fastest because the underlying judgment already exists; redeployment is slowest because it asks someone to build judgment in an unfamiliar domain from a low baseline. Redeployment mapping typically draws on adjacency data such as LinkedIn’s Economic Graph, which models which skill sets sit close enough to a role for a worker to cross into it within a defined training window. Programmes that fund all three moves identically, same budget, same timeline, same success bar, systematically underfund redeployment and overfund deepening, because deepening produces visible completion numbers faster.

What a capability inventory records per role

A capability inventory records the specific skills a role requires, the demonstrated proficiency against each one, and the arithmetic gap to what the AI roadmap needs; the unit of record is a skill profile, never a job title. Two people holding the identical title can carry entirely different AI-capability profiles, and an inventory built at the title level cannot see either of them.

Public taxonomy frameworks such as the OECD Skills Outlook offer a starting structure, skill clusters, proficiency bands, and role-to-skill mappings, that most organisations adapt rather than build from a blank page. General AI literacy, the baseline fluency that lets someone understand what the technology can and cannot do, usually sits as its own taxonomy entry rather than folded into any single role’s skill profile, because it is a prerequisite for every role rather than a differentiator between them. The inventory itself typically records three fields per skill: a proficiency band defined by observable behaviour rather than self-assessment, the roles that require it at each band, and the date the entry was last verified against actual work product. This capability taxonomy is the object the rest of a skills and upskilling strategy operates on; every later calculation in this guide, from the capability-gap arithmetic to the financial case, reads from this same record.

Why the job title is the wrong unit of record

Job titles bundle multiple unrelated skill sets under one label, so two employees with the identical title can carry entirely different AI-capability profiles, and a strategy built on titles will miss both of them. A “senior analyst” title says nothing about whether the person holding it has ever supervised a model’s output for a confidently wrong answer: a skill some senior analysts have and others do not, regardless of tenure.

Recording at the skill level instead of the title level is what makes redeployment visible in the first place: a title-based inventory cannot show that a compliance analyst and an AI-governance analyst share most of their underlying skill profile, because the title obscures the overlap. Skill-level recording also keeps the inventory current; proficiency bands move as people build capability, while titles change only on promotion cycles that lag capability by months or years.

Why Transformation Programmes Stall at Pilot When Workforce Capability Lags

AI transformation programmes usually stall not because the underlying technology underperforms, but because the operational teams downstream of a successful pilot lack the capability to run what was built, and the programme quietly reverts to the process it was meant to replace. This cluster’s data puts that reversion rate at roughly 63% of AI transformation programmes: a number that gets blamed on the platform far more often than the evidence supports.

PMI’s research on workforce upskilling names the actual mechanism directly: what looks like a skills gap is often an execution gap; unclear ownership and escalation paths that persist no matter how much retraining is delivered (PMI). That reframing is the argument this section makes in full: the failure sits at the operational handover, not at the platform-selection decision that precedes it.

From executive mandate to successful pilot to failed handover

The failure sequence begins with an executive mandate that funds a pilot, the pilot, typically scoped and reported internally as a proof of concept, clears its model-performance bar, and the operational handover to whichever team must run the result day to day is where the sequence actually breaks. Each of those three steps is owned by a different group, and none of them is accountable for the step that follows it.

An executive mandate typically specifies a business outcome and a budget, not a capability requirement; nobody is asked whether the receiving team can operate the thing being funded. The pilot team, usually a small group with direct platform access, optimises for the metric the mandate specified and reports success against it. The operational team that inherits the result was never part of either conversation, has no protected time to build the judgment the tool requires, and defaults to the workflow it already knows how to run. Agile transformations show the identical pattern: a team adopts the ceremonies, the ceremonies clear an audit, and the organisation still ships on the old cadence because nobody redesigned the decision rights underneath them. The handover gap in an AI programme is the same structural failure wearing different vocabulary.

The stall signature: strong model metrics, no production workflow

A stalled AI pilot has a recognisable signature: it reports strong performance against its own model metrics, and it never appears inside a live production workflow six months later. That combination, success on paper, absence in practice, is what the pattern amounts to in the literature as the pilot-to-production gap, and it is more diagnostic than either fact alone.

Model metrics measure what the system does in a controlled evaluation; they say nothing about whether a team can operate the system under real deadline pressure, ambiguous inputs, or an output the model got confidently wrong. A pilot report that leads with accuracy or latency figures and has no adoption metric attached is usually reporting exactly this stage; technically validated, operationally untested. Programme reviewers who want an early warning should ask a narrower question than whether the pilot succeeded. Ask who, specifically, is running it unsupervised next quarter, and whether that person exists yet.

Why the technology-first diagnosis misattributes the cause

The technology-first diagnosis treats a stalled programme as a platform problem and responds by evaluating a different vendor, which fixes nothing because the platform was rarely the constraint in the first place. Re-running procurement against the same operational gap produces the same reversion on a new tool, at the cost of a second procurement cycle.

The diagnostic tell is timing. A platform problem shows up during the pilot, when the tool fails to perform against its own benchmark. A capability problem shows up after the pilot, when a technically successful result meets a team that was never built to receive it. Programme reviews that only examine pilot-phase metrics will never see the second failure mode, because by the time it appears the pilot has already been marked a success and closed out.

one question · 10 seconds

Quick check while the handover argument is fresh: where does your own upskilling plan actually stall?

Which Competencies Each of the Four Stages of AI Workforce Evolution Consumes

Each of the four stages of AI workforce evolution consumes a different competency, prompt literacy and output supervision in the earliest stages, workflow redesign once tooling is established, and AI-native collaboration once a machine participant is designed directly into the work, and teaching a later-stage skill too early wastes the training budget on capability nobody can use yet. Programme audits that track spend against stage consistently find the waste concentrated in one place: workflow-redesign curriculum delivered to a workforce that has no live workflow yet to redesign.

The stage model itself is defined on the Four Stages of AI Workforce Evolution page. Each stage consumes one dominant competency, and mapping the two together turns a flat competency list into a sequencing tool a programme office can actually schedule against.

Stage one and two: prompt literacy, then output supervision

Stage one consumes prompt literacy and tool familiarity, and stage two consumes output supervision: the judgement to catch a wrong answer the system expresses with total confidence. Both are prerequisite capabilities: neither workflow redesign nor AI-native collaboration is reachable by a workforce that has not built these two first.

Stage One: Prompt Literacy and Tool Familiarity

Prompt literacy is the ability to phrase a request so the system’s output is usable on the first pass, and tool familiarity is knowing which tool in the stack fits a given task. Neither requires technical background; both require repeated, supervised practice against real work rather than a single onboarding session.

Organisations that treat stage one as a one-time onboarding module see the capability decay within weeks, because prompt literacy is a practiced skill, not a fact that can be memorised once. NIST’s cybersecurity workforce research makes a parallel point about technical fields: capability built through applied practice against real tasks holds up under pressure in a way classroom instruction alone does not (NIST).

Stage Two: Output Supervision and Confident Error Detection

Output supervision is the skill of evaluating a system’s answer for correctness before acting on it, and it is harder to teach than prompt literacy because the failure mode it defends against, a wrong answer delivered with the same confidence as a right one, has no visible tell.

Teaching output supervision works best against real error cases pulled from the organisation’s own tool use, not synthetic examples, because synthetic errors are usually obvious in ways real ones are not. A workforce that reaches stage two without practising on real failures tends to trust the system’s tone rather than its content, which is the exact failure output supervision exists to prevent.

Stage three: workflow redesign as process architecture

Stage three consumes workflow redesign, a process-architecture capability: it asks someone to redraw who does which step and in what order. Teams that treat stage three as more advanced training on the same tool never actually reach it, because the tool was never the bottleneck.

Workflow redesign requires the person doing it to hold the entire process in view: which steps a machine now completes reliably, which steps still need human judgement, and where the transfer between the two sits. That is an organisational-design skill borrowed by the capability programme, and the people who are good at it tend to be the same people who were good at process improvement before AI entered the picture. Building this competency means pairing capability-building with someone who already holds process authority over the workflow being redesigned. A training session cannot grant that authority on its own.

Stage four: designing work that assumes a machine participant

Stage four consumes AI-native collaboration: the capability to design work on the assumption that a machine is a persistent participant in it, not a tool invoked at a single step. Anthropic’s research on AI’s economic impact documents this shift already underway; users are increasingly delegating full tasks rather than collaborating with the system step by step, and as models work independently for longer stretches, the design question stops being how to use the tool and becomes how to design work that assumes a persistent machine participant (Anthropic).

This is the stage most competency programmes never reach, because it requires stage three’s process authority plus a further step: designing the escalation path for when the machine participant should hand a decision back to a person. Organisations attempting stage four without having consolidated stage three typically produce workflows where the machine participant has no defined boundary, which reintroduces the confident-wrong-answer risk that output supervision was built to catch, at a scale one supervisor can no longer review.

The mistimed-investment error and how to detect it early

The mistimed-investment error is teaching a later-stage competency, most often workflow redesign, to a workforce still at stage one, and it is the single most common sequencing error a capability programme makes, because stage-three curriculum reads as more sophisticated and gets funded first. The capability ladder makes the error detectable early, before the budget is spent: if only a small share of a cohort can demonstrate stage-two output supervision, stage-three curriculum has no foundation to build on yet.

The detection method is simple and worth running before any workflow-redesign programme is approved: sample ten completed tasks from the workforce due to receive the training, and check whether a supervisor can find evidence of output correction in the sample. If the evidence is not there, the workforce has not consolidated stage two, and stage-three spend will sit unused until it is.

Turning a Capability Gap Into a Date the Programme Plan Must Respect

Turning a capability gap into a date means calculating time-to-competence, the elapsed weeks from a role’s current proficiency to the proficiency the AI roadmap requires, at a realistic weekly learning allocation, so the programme plan inherits a scheduling dependency instead of an unresolved complaint. Most workforce planning stops at naming the gap, which hands the programme office an opinion it can argue with rather than a number it has to schedule around.

MIT Sloan Management Review’s reporting on skills-first talent strategy underscores why the target side of this calculation increasingly has to be roadmap-derived rather than benchmark-derived: mentions of skills-first hiring roughly doubled across professional networks in a single year, and external proficiency benchmarks age faster than an internal roadmap does (MIT Sloan Management Review).

Four inputs and how to source each

The calculation needs four inputs: current proficiency, target proficiency, the arithmetic distance between them, and time-to-competence: the elapsed weeks to close that distance at a realistic weekly learning allocation. Each input has a specific, correct source, and substituting a convenient source for the correct one is where the calculation usually goes wrong.

Current Proficiency, Read From Demonstrated Work Product

Current proficiency should be read from demonstrated work product, actual output the person has produced using the capability in question, rather than from a self-assessment survey. Work product is observable and dated; a self-rating is neither.

Reading proficiency this way takes longer than distributing a survey, which is precisely why most organisations skip it, but the survey route produces a baseline that is wrong in a predictable direction: upward. A baseline set too high understates the real gap, and every later scheduling decision inherits that understatement.

Target Proficiency and the Arithmetic Distance Between Them

Target proficiency is the specific proficiency level the next roadmap milestone depends on, set from the committed AI roadmap rather than from an aspirational ceiling. The arithmetic distance is simply the gap between the two proficiency bands, expressed in the same units the inventory already uses.

Setting the target too high, by borrowing an industry benchmark instead of reading the roadmap, inflates every time-to-competence figure downstream and makes the whole exercise look less credible to the finance function reviewing it than a tighter, roadmap-derived target would.

Why self-reported proficiency inflates the baseline

Self-reported proficiency inflates the baseline because people rate their own capability against their intent rather than their demonstrated output, and the gap between the two widens specifically in fast-moving domains like AI tool use, where yesterday’s proficiency claim is already outdated. This is a well-documented pattern in skills-assessment research generally, not a quirk specific to AI capability.

The practical fix is cheap relative to the distortion it prevents: pull three recent, dated examples of the work product in question and score proficiency against those examples using a fixed rubric, rather than asking the person to rate themselves. This produces a baseline the programme can defend to a sceptical finance function, because it points to specific artefacts rather than a self-reported number.

Time-to-competence as a dated schedule dependency

Time-to-competence is the elapsed number of weeks from current proficiency to target proficiency at a realistic weekly learning allocation, and it is the term routine workforce planning omits; without it, a capability gap is an opinion; with it, the gap is a date the programme plan has to respect. A gap stated in proficiency-band terms alone gives a scheduler nothing to put on a Gantt chart; a gap stated in weeks gives them a dependency.

Realistic weekly learning allocation is the variable that most inflates or deflates this number, and it should be set from actual completed hours in a comparable prior cohort, not from the number stated in a course catalogue. A role with a two-band gap and four protected hours a week reaches target proficiency in a materially different number of weeks than the same gap resourced at ninety minutes a week, and the programme plan needs the real number, not the aspirational one.

Confining the calculation to critical-path roles

The calculation should run only against critical-path roles, the roles the AI roadmap’s next milestone actually depends on, because extending it across every role in the organisation is how the exercise collapses under its own administrative weight before it produces anything useful. A critical-path role is identifiable by a direct test: does the next roadmap milestone slip if this role’s capability gap is not closed on schedule.

Revisit the numbers when the roadmap changes, not on a fixed calendar: a quarterly refresh cycle recalculates gaps that have not moved and misses gaps that opened the week the roadmap shifted. Tying the recalculation trigger to the roadmap rather than to the calendar keeps the exercise proportional to the small set of roles it was designed for.

Running the Programme: Cohorts, Line Managers, and Protected Learning Time

Running an AI upskilling programme well depends less on curriculum quality than on four operational choices: how cohorts are composed, whether line managers are equipped before delivery starts, whether protected learning time is a calendar commitment with a named backfill, and whether practice happens against real organisational data. Completion collapses from unsupported line managers far more often than from weak content, and no course catalogue withstands an unsupported manager quietly deprioritising it the moment delivery pressure arrives.

The University of Phoenix’s research on AI-assisted training design notes that AI-supported programmes can tailor content to what each employee already knows and how they learn best, cutting the hours spent on material a participant has already mastered University (University of Phoenix). That personalisation only pays off if the four operational choices that follow are made correctly first: a well-personalised curriculum delivered into an unsupported cohort fails the same way a generic one does.

Cohort sizing and why mixed-function beats role-homogeneous

Mixed-function cohorts outperform role-homogeneous ones because the workflow being redesigned is itself cross-functional, and a cohort composed of a single function cannot practise the handoffs the redesigned workflow will actually require. A cohort of only data analysts learning workflow redesign in isolation from the operations staff who will run the redesigned process is training half a workflow.

Cohort size matters less than composition, but a practical range holds up across most programme designs: cohorts small enough that every participant gets direct facilitator attention during practice, and large enough to include at least one person from each function the target workflow touches. Cohort composition decisions made purely on headcount, without checking function coverage, are the most common design error at this stage.

The manager enablement package, shipped before cohort one

The manager enablement package, a short, direct briefing on what the programme expects, how to protect the time it requires, and how to recognise the specific behaviours it is trying to build, has to ship before cohort one starts, not after the first completion numbers come in. A manager who first hears about the programme’s expectations from a completion report has already had multiple opportunities to deprioritise it.

Line manager enablement done well is brief by design: managers do not need to understand the curriculum in depth, they need to know the three or four observable behaviours that indicate the training is landing, so they can notice and reinforce them in the flow of normal work. Skipping this step is the single highest-leverage cut a resource-constrained programme can make, and it is also the one most likely to produce the completion collapse the programme is trying to avoid.

Protected time and the backfill plan that makes it real

Protected learning time only functions as a real commitment when it appears on a calendar with a named backfill plan attached, rather than as a general encouragement to make time for training. An encouragement with no named backfill is the first thing sacrificed when delivery pressure returns, and delivery pressure always returns.

A backfill plan does not need to be elaborate: it needs to name, specifically, who absorbs a participant’s regular workload during their protected hours, and that name needs to be someone other than the participant working late to compensate. Programmes that protect time on paper but leave the backfill question unanswered see the same completion collapse as programmes with no protected time at all, because the participant experiences both conditions identically: nobody actually freed up the hours.

Practice environments on real data, and the transfer-failure diagnostic

A practice environment built on real organisational data produces skills that transfer to the job; a practice environment built on synthetic examples produces skills that transfer only to the practice environment, a transfer failure that shows up only after the programme has already reported a strong completion number. Synthetic data is easier to source and easier to sanitise for a training environment, which is exactly why it gets used even though it undermines the goal.

The diagnostic for this failure mode is specific: if completion is high and application on the job is absent, the problem sits in the practice environment, not participant motivation. Platforms such as Coursera for Business and Degreed provide the delivery infrastructure for a programme like this, but neither substitutes for connecting that infrastructure to the organisation’s own data: the platform is procurement context, not the programme itself.

The Financial Case: Replacement Cost, Development Cost, and Internal Mobility

The financial case for developing AI capability internally rests on comparing fully loaded replacement cost against development cost for the same role, and the comparison usually favours development once every hidden hiring cost is priced in: the omission that most reverses this answer is the ramp time an external hire needs before reaching full contribution. Hiring looks cheaper on a spreadsheet than it is in a delivery plan precisely because that term goes unpriced.

Harvard Business Review’s coverage of workforce strategy, sponsored by SHRM, reports that 58% of the workforce needs new skill sets to do their current jobs, and that 83% of industry economists say employers are finding roles harder to fill than they were five years earlier (Harvard Business Review); both figures that raise the replacement side of the comparison directly, since a harder-to-fill role carries a longer, costlier vacancy.

Fully loaded replacement cost and the forgotten ramp-time term

Fully loaded replacement cost has three components: recruitment fees, vacancy productivity loss over the open period, and ramp time to full contribution; and it is the third term people forget, which is why hiring looks cheaper on a spreadsheet than it is in an actual delivery plan. Recruitment fees are the easiest to quote and the smallest of the three for most AI-critical roles.

Vacancy productivity loss compounds for every week a critical-path role sits open, because the work either does not happen or gets absorbed by someone else at the cost of their own output. Ramp time to full contribution is the least visible cost of the three because it appears after the hire is made and rarely gets tracked against the original business case: a new hire in an AI-critical role commonly needs a comparable ramp period to an internally developed employee closing the same capability gap, which erases much of the apparent cost advantage of hiring externally.

Stating development cost honestly

Development cost should include the direct cost of the programme and the productivity cost of the protected learning time itself, stated honestly rather than treated as free because it does not appear on an external invoice. Protected time that a participant is not spending on billable or productive work is a real cost, and a financial case that omits it will not persist scrutiny from a finance function that already knows to look for it.

Development cost stated this way is usually still lower than fully loaded replacement cost for critical-path roles, but the margin is narrower than an advocate expecting a free win might hope. Presenting it honestly, including the cost most programmes prefer to leave out, is what makes the comparison credible enough to withstand a finance review rather than being waved through and later challenged.

Four tracked measures and what each is for

Four measures carry the programme’s ongoing case once it is running: capability uplift against the recorded baseline, internal mobility rate, retention differential between participants and non-participants, and application rate: the share of trained capability actually showing up in completed work. Each measure answers a different sceptical question, and a programme that reports only one of the four leaves the others unanswered.

Internal Mobility Rate as the Payback Signal

Internal mobility rate, the share of critical-path role openings filled from inside the organisation rather than externally, is the payback signal executives accept most readily, because it converts directly into avoided replacement cost using the same fully loaded figure calculated earlier. A rising internal mobility rate on critical-path roles is the clearest evidence the programme is producing the outcome the financial case promised.

Retention Differential Between Participants and Non-Participants

Retention differential compares the retention rate of programme participants against a matched group of non-participants over the same period, and a positive differential is one of the few programme metrics that also functions as a recruiting signal, because prospective hires increasingly ask about development investment before accepting an offer.

Measuring retention differential honestly requires a matched comparison group, not simply everyone else in the organisation; comparing participants against non-participants in dissimilar roles or tenure bands produces a differential that looks favourable for reasons that have nothing to do with the programme.

Designing measurement before launch

Measurement designed before launch is what makes all four measures usable, because a retrofitted measurement approach cannot establish the baseline every one of them depends on. A programme that starts collecting proficiency data only after cohort one has already lost the pre-programme baseline permanently.

The Kirkpatrick Model gives a useful frame for what “before launch” actually means in practice: reaction, learning, behaviour, and results are four distinct levels of evidence, and most programmes report reaction, attendance and satisfaction, while informally claiming results. Deciding which of the four levels the programme will actually measure, and building the collection method for that level before cohort one starts, is the single design decision most responsible for whether the financial case can be defended a year later.

Named Enterprise Commitments and What They Actually Reported

Amazon’s Upskilling 2025 commitment of roughly $700 million across about 100,000 employees, AT&T’s Future Ready programme at roughly $1 billion, IBM SkillsBuild, and Google Career Certificates represent the largest public capability commitments in this space. Separating what each organisation announced from what it later reported is more useful to a reader building an internal business case than any single headline figure, and that gap between announcement and outcome is itself the finding this section exists to emerge.

Programme	Announced Commitment	Stated Population	Reported Outcome
Amazon Upskilling 2025	~$700M	~100,000 employees	Partial, completion and role-transition figures published; long-run productivity outcome not published
AT&T Future Ready	~$1B	Company-wide, multi-year	Partial, decade-long reskilling narrative published; no independently verified ROI figure
IBM SkillsBuild	Not publicly itemised	External learners plus employees	Reach figures published; role-level outcome data not published
Google Career Certificates	Not publicly itemised	External job-seekers, primarily	Completion and hiring-partner figures published; internal workforce outcome not applicable

Amazon Upskilling 2025: commitment, population, reported outcome

Amazon’s Upskilling 2025 initiative committed roughly $700 million to train approximately 100,000 employees, and the reported outcome is partial: completion and internal role-transition figures have been published, but a long-run productivity or retention outcome tied specifically to the programme has not. Coursera’s enterprise research notes the broader scale of Amazon’s employee development activity, reporting that the company has helped more than 425,000 employees gain new skills since 2019 across several distinct programmes, including a technical apprenticeship track and a pre-paid tuition benefit (Coursera).

The distinction between the $700 million, 100,000-employee commitment and the broader 425,000-employee figure matters for anyone citing Amazon as a benchmark: the two numbers describe different programmes with different scopes, and conflating them overstates what either one alone has demonstrated.

AT&T Future Ready and the decade-long view

AT&T’s Future Ready programme, reported at roughly $1 billion, is presented as a decade-long reskilling commitment rather than a single initiative with a defined end date, and the public record reflects that perspective: a sustained narrative of internal mobility and role transition, without an independently verified return-on-investment figure attached to the total spend.

The absence of a single ROI figure is not unusual for a commitment of this duration and scale, attributing a decade of business outcomes to one workforce programme is methodologically difficult even for the organisation running it, but a reader citing AT&T as evidence should represent that absence accurately rather than implying a number exists where the public record does not supply one.

IBM SkillsBuild and Google Career Certificates

IBM SkillsBuild

IBM SkillsBuild combines an external-facing learning platform with an internal employee capability track, and IBM has published reach figures, learners served, more consistently than it has published role-level outcome data for the internal employee population specifically. The externally-facing scale of the programme is well documented; the internal capability-uplift figure a business case needs is not.

Google Career Certificates

Google Career Certificates is primarily an external-facing programme aimed at job-seekers rather than an internal upskilling initiative, and Google has published completion numbers and hiring-partner relationships for that external population. It is not a directly comparable data point for an internal AI upskilling business case, and citing it as one, a common error in vendor comparisons, misapplies external job-preparedness data to an internal capability question.

Reading an announcement: per-head investment and the publication gap

Per-head investment, total commitment divided by stated population, is the comparable unit across these four programmes, not headline spend, because headline figures span wildly different population sizes and cannot be compared directly against each other. A $700 million commitment across 100,000 people and a $1 billion commitment company-wide describe very different per-head bets once the division is done.

A programme with no published outcome is not evidence of anything, in either direction: it is simply unverified. NIST’s own convening on the cybersecurity workforce takes the same evidentiary posture: bringing government, industry, and academic voices together specifically to compare what is actually known about AI’s effect on workforce capability, rather than what has merely been announced (NIST).

Sequencing Capability Building Inside the Change Programme

Capability building belongs inside the change programme’s sequencing, not inside a standalone L&D calendar, because awareness and desire have to be established in the workforce before curriculum can land; ADKAR’s knowledge stage is not reachable by a population that has not passed through the two stages that precede it. A technically excellent curriculum delivered into a population that has not built awareness or desire produces attendance without adoption.

Kotter’s eight-step process maps onto the identical constraint from a different angle: establishing urgency and forming a guiding coalition, Kotter’s first two steps, have to precede any specific skill-building activity, because a workforce that has not accepted the need for change has no reason to retain what a curriculum teaches it. The wider change-management discipline behind this sequencing lives under Change Management for AI Transformation; this guide’s contribution is only the sequencing join between the two disciplines. Harvard Business Review’s sponsored coverage of workforce strategy captures the accountability side of the same pressure, noting that HR functions face substantial change in their own accountability over a twelve-to-eighteen-month window as organisations respond to the same disruption driving the AI capability agenda (Harvard Business Review).

Why ADKAR’s knowledge stage cannot be reached first

ADKAR’s knowledge stage, the point at which a person can absorb specific skill content, sits behind awareness and desire in the model’s own sequence, and no amount of curriculum quality substitutes for skipping the two stages that come first. A workforce pushed straight to a knowledge-stage curriculum without awareness or desire attends the sessions and retains almost none of the content.

Attendance without adoption is the visible symptom of this sequencing error, and it is frequently misdiagnosed as a curriculum problem when the actual defect sits two stages earlier in the model. Fixing the symptom by redesigning the curriculum a second time, without addressing awareness and desire first, produces the identical outcome on the second attempt.

Communication leading the learning calendar by one phase

The communication plan needs to lead the learning calendar by roughly one full phase, and both plans should be authored by the same owner rather than negotiated separately between HR and the programme office, because a negotiated transfer between two owners is where the sequencing gap usually opens. If communication and curriculum are planned independently, curriculum tends to arrive on its own schedule regardless of where the workforce actually sits on awareness and desire.

A single owner authoring both plans can hold the sequencing constraint directly: curriculum for a given cohort does not get scheduled until that cohort’s communication milestones are established complete, not merely started. This is a scheduling discipline more than a content decision, and it is the specific discipline a split-ownership structure tends to lose first under delivery pressure.

Change saturation across concurrent programmes

Change saturation describes a workforce’s finite capacity to absorb concurrent change programmes, and capability building competes for that same finite capacity alongside every other transformation initiative running at the same time: it does not get a protected lane just because it is framed as training rather than change. A workforce already absorbing three concurrent initiatives has materially less capacity for a fourth, regardless of how well that fourth one is sequenced internally.

Programme offices that track saturation typically do it by counting concurrent initiatives touching the same population, because saturation is a property of the workforce’s total change load rather than of any one programme’s design. A capability programme sequenced correctly on its own terms can still fail if the wider change portfolio around it saturates the same people at the same time; the two questions, is this programme sequenced correctly, and is the surrounding portfolio saturating this population, have to be asked separately, because a correct answer to the first does not imply a correct answer to the second.

Summary

A skills and upskilling strategy earns its name the moment it stops tracking course completion and starts tracking demonstrated capability against a dated roadmap requirement; everything from the stage-to-competency mapping to the financial case is that single shift worked out in different parts of the programme.

The capability system, not the training calendar, is what closes the gap

The taxonomy record from the opening definition, the stage-matched competency map, the time-to-competence calculation, and the delivery mechanics all feed one system: a record of what each critical-path role can demonstrably do, set against what the roadmap requires next. A training calendar can run in parallel to this system and still fail the organisation, because a calendar measures attendance while the system measures capability, and only one of those two numbers predicts whether the next roadmap milestone actually ships on time.

The decision rule that falls out of this is specific rather than general: before approving spend on any capability activity, ask which roadmap milestone it closes the gap for, and at which evolution stage. An activity that cannot answer both questions is a training-calendar item wearing a capability-system label, and it should be scheduled with that understanding rather than budgeted as if it carries the same weight as an activity that answers both.

Handover failure and mistimed investment are the same class of error, arriving at different points

The transformation-stall pattern and the mistimed-investment error described separately in this guide are the same underlying mistake, spending capability effort at the wrong point in a sequence, showing up at two different points in the programme’s life. One arrives at handover, when a technically successful pilot meets a team nobody prepared to receive it; the other arrives earlier, when workflow-redesign curriculum is funded for a workforce still building prompt literacy.

Both failures share the same fix: check the sequence before funding the next step, rather than after the spend has already gone out the door and the completion numbers have already been reported as a success. A programme that runs this check consistently, at handover, at each stage transition, and at every funding decision in between, closes the gap the financial case exists to defend, and it closes it on the schedule the capability-gap calculation already gave the plan to work against.

Anonymous. Counted, not tracked.

Where is your organisation with this right now?

What is the hardest part where you are?

agility at scale