Measuring AI Adoption: A Leading and Lagging Indicator Set — Capabilities illustration

Measuring AI Adoption: A Leading and Lagging Indicator Set

Executive summary

Most AI adoption programmes are cancelled one quarter before they would have worked, because the board asked for lagging numbers that never move that fast and nobody was tracking the leading ones that do. The full indicator set, where each metric actually comes from, how to avoid the vanity-metric trap, and the reporting cadence that buys a slow-moving programme the time it needs to pay off.

The conversation that ends most AI adoption programmes happens at roughly the two-quarter mark and goes like this. An executive asks what the return has been on the AI investment. The programme owner, who has been running challenges and standing up communities and protecting learning time, does not have a number that moves the executive, because the numbers that move executives are cycle-time and cost and revenue per head, and those have not shifted yet. There is an uncomfortable silence, and then the programme becomes a candidate for the next round of cuts. It is cancelled, in my experience, about one quarter before the leading indicators it was not tracking would have converted into the lagging ones the executive was asking for.

The workforce-readiness framework names measurement as the move that determines whether a programme survives long enough to work, and puts a leading-to-lagging ledger at the centre of it. This is that ledger built out: the full indicator set, where each number actually comes from, how to keep the activity metrics honest, and the reporting cadence that prevents the two-quarter cancellation. Measurement here is not a reporting chore. It is the thing that keeps the programme alive during the period when it is working but cannot yet prove it in the currency the board trusts.

The two kinds of indicator

Everything in adoption measurement resolves to a distinction between two kinds of number, and getting the relationship between them right is most of the discipline.

Leading indicators are cheap, fast, and available weekly. They tell you the machine is running before the machine has produced any output the board can see. Lagging indicators are the outcomes the board actually wants, and they move on a scale of quarters because they sit at the end of a chain of behaviour change that takes time to propagate. The relationship is causal and sequential: the leading indicators move first, and if they are genuine, the lagging ones follow a quarter or two later. The whole failure mode this prevents is flying on the lagging instruments alone, seeing nothing for two quarters because nothing moves that fast, and losing your nerve.

Leading (weekly, cheap, operational)Lagging (quarterly, what the board wants)Source
Mini-challenges completedCycle-time reduction on a named workflowCommunity platform / workflow system
Prompts contributed to the shared libraryTicket or request deflection ratePrompt library / ticketing system
Active members in the community of practiceOutput or revenue per headCommunity platform / finance
% of team using a sanctioned tool this weekError, rework, or quality rateAI gateway logs / quality system
Workflows attempted or redesignedRetention of high-AI-capability staffTeam records / HR

Name the source or the metric is aspirational

The difference between a programme that is measured and one that merely intends to be is whether each number has a named source. A metric without a source is a hope, and hopes do not survive the first quarter under pressure.

Tool usage and the weekly-active percentage come from the sanctioned AI gateway’s logs, which is one of the underrated reasons to route usage through a gateway in the first place: you cannot measure adoption across a sprawl of personal consumer accounts, but you can measure it precisely across a gateway that sees every call. Challenges completed, prompts contributed, and community activity come from the community platform and the shared library, which are cheap to read because the community was designed to generate exactly this signal. The lagging outcomes come from the systems that already run the work: the ticketing system holds deflection, the deployment pipeline holds cycle-time, the support desk holds quality.

The instrumentation discipline that matters most is to resist measuring everything. Pick one named workflow per function and measure that one properly, end to end, rather than assembling a broad dashboard of shallow numbers nobody trusts. One well-instrumented workflow where you can show cycle-time falling is worth more to a board than twenty metrics with unclear provenance. Depth beats breadth, because a single trusted number survives scrutiny and a wall of untrusted ones does not.

Keep the activity metrics honest

Leading indicators are activity counts, and activity counts are gameable, which means the moment you make one a target you invite Goodhart’s law: the measure stops measuring what it measured once people optimise for it directly. Set challenges completed as the goal and people will complete challenges mechanically to hit the number, producing motion without proficiency, which is the exact theatre the whole programme exists to avoid.

The correction is a rule: never report an activity metric on its own. Every activity count is paired with a quality or outcome check that keeps it honest. Challenges completed is reported next to a sampled read of whether the shared results were any good. Tool usage is reported next to whether it is attached to real workflows rather than idle experimentation. Prompt-library growth is reported next to whether the new prompts are actually being reused by anyone. The activity number earns its place because it moves early and tells you the machine is running; the paired check ensures that a rising number means rising capability and not rising box-ticking. Measure the activity, but never trust it naked.

The measurement gap is the market’s, not just yours

It is worth knowing that most of the market is not measuring even the systems, let alone the people. Gartner projects that only around forty percent of organisations deploying AI will have adopted dedicated AI-observability tooling to monitor model performance by 2028, which means a majority are not yet instrumenting the accuracy of the models themselves. If the systems are largely unmeasured, the human capability layer on top of them is measured essentially nowhere. That is a bleak fact about the state of practice and a genuine opportunity: a programme that can actually show its leading indicators climbing and tie them to a named workflow’s improving outcome is operating with evidence in a field that is mostly operating on faith. The measurement is the moat, because so few have bothered to build it.

The reporting cadence that buys time

The metrics only prevent the two-quarter cancellation if they are reported on the right clock to the right audience. That means two cadences, not one.

The leading indicators go to the programme owner weekly. They are the operational instrument, the thing that shows which teams are catching and which are stalling while there is still time to intervene, and weekly is the resolution at which intervention is possible. The lagging indicators go to the board or executive sponsor quarterly, because that is the scale on which they move and reporting them monthly just broadcasts noise dressed as signal.

The load-bearing act is how the gap is narrated in the early quarters. When the board asks for the return before the lagging numbers have moved, you do not present a flat outcome and hope, and you do not apologise for the absence. You show the leading indicators climbing and you name them as the leading edge of the lagging ones, with the timeline stated: activity moves now, outcomes trail it by a couple of quarters, here is the activity moving. Better still, you set that expectation before the programme starts, so that when the two-quarter conversation arrives everyone has already agreed that the leading indicators are the interim evidence. A programme that framed the timeline up front survives the conversation that kills the programme that did not.

The verdict

Adoption measurement is not about proving ROI on demand; it is about surviving the interval between when a programme starts working and when it can prove it in the board’s currency. Track the full spectrum, leading and lagging, with a named source behind every number and a quality check beside every activity count. Report the leading indicators weekly to run the programme and the lagging ones quarterly to inform the board, and narrate the gap between them so the slow-moving outcomes get the time they need to arrive. The programmes that die are the ones flying on lagging instruments alone. The ones that survive are the ones that could show the leading edge climbing and had the evidence to buy the quarter that made the difference.

Where this connects: the leading indicators are generated by the mini-challenges, the community of practice, and the protected learning time that make up the rest of the programme, and the whole measurement discipline is the fourth move in the workforce-readiness framework that decides whether the other three survive long enough to work.

Thomas Prommer
CIO / CTO · 20 years · Practitioner, not consultant

Tom Prommer writes The AI Strategy Guide from the operator's seat — every tool covered, tested with real money before forming a view. Connect on LinkedIn · prommer.net · X

Frequently asked questions

What are the leading and lagging indicators for AI adoption?
Leading indicators are the cheap, fast, weekly signals that the adoption machine is running: mini-challenges completed, prompts contributed to the shared library, active members in the community of practice, the percentage of a team that used a sanctioned tool this week, and the number of workflows anyone has attempted to change. Lagging indicators are the slow, quarterly outcomes the board actually cares about: cycle-time reduction on a named workflow, ticket or request deflection, output or revenue per head, error and rework rates, and retention of high-AI-capability staff. The relationship is causal and sequential. The leading indicators move first and, if they are real, the lagging ones follow a quarter or two later. Tracking only the lagging set is the most common way good programmes die, because it leaves you blind during exactly the period when you most need evidence that the thing is working.
Where do these metrics actually come from?
Each has a specific source, and naming the source is what separates a measurable programme from an aspirational one. Tool usage and the percentage of a team active this week come from the sanctioned AI gateway's logs, which is one of several reasons to route usage through a gateway rather than let it sprawl across consumer accounts. Challenges completed, prompts contributed, and community activity come from the community platform and the shared prompt library. Cycle-time, deflection, and error rates come from the systems that already run those workflows: the ticketing system, the CRM, the deployment pipeline, the support desk. The instrumentation discipline is to pick one named workflow per function and measure it properly rather than trying to measure everything and measuring nothing, because a single well-instrumented workflow is worth more evidence than a dashboard of numbers nobody trusts.
How do you avoid vanity metrics in AI adoption?
By pairing every activity metric with a quality or outcome check, so that the number cannot be improved by gaming it alone. Challenges completed is a useful leading indicator and a dangerous target, because if completion becomes the goal people will complete challenges mechanically to hit it, which is Goodhart's law arriving on schedule. The correction is to never report an activity count on its own: challenges completed sits next to a sampled look at whether the shared results are any good, tool usage sits next to whether it is attached to a real workflow, prompt-library growth sits next to whether the new prompts are being reused. Measure the activity because it moves early and tells you the machine is running, but hold it honest with an outcome check so that a rising number means rising capability rather than rising theatre.
How often should you report AI adoption metrics, and to whom?
On two different clocks to two different audiences. The leading indicators go to the programme owner weekly, because they are the operational instrument that tells you which teams are catching and which are stalling in time to intervene. The lagging indicators go to the board or executive sponsor quarterly, because that is the scale on which they actually move and reporting them more often just shows noise. The critical piece is how you narrate the gap in the early quarters: you show the board the leading indicators climbing as the evidence that the lagging ones are coming, rather than presenting flat lagging numbers with no context and inviting the cancellation. The reporting cadence is not administrative. It is the mechanism that buys a slow-moving programme the time it needs to reach the outcomes.
When should you expect the lagging numbers to move?
Realistically two to three quarters after the leading indicators start climbing, and the mismatch between that timeline and a typical two-quarter patience window is the single biggest structural risk to an adoption programme. Behaviour change compounds slowly: people complete challenges, build habits, redesign a workflow, and only then does cycle-time on that workflow measurably fall. If the board expects the lagging outcome at the two-quarter mark and sees nothing, the programme is cancelled roughly one quarter before it would have paid off. The way to manage this is to set the expectation up front, before the programme starts, that lagging outcomes trail leading activity by a couple of quarters, and to agree that the leading indicators are the interim evidence everyone will judge progress by until the lagging ones arrive.