ADKAR in the Age of AI

Change management frameworks were built for a world where the destination was known. ADKAR - Awareness, Desire, Knowledge, Ability, Reinforcement - assumes you are moving people from a defined current state to a defined future state. That works for an ERP rollout. It breaks when the thing you are changing to keeps changing.

A system optimized for predictable change

I wrote previously that systems optimize for what they are designed to optimize for. ADKAR is a system. It optimizes for phased, sequential adoption: build awareness before desire, desire before knowledge, knowledge before ability, ability before reinforcement. Each stage gates the next. The model is clean, widely adopted, and genuinely useful - Prosci's research shows that 63% of AI implementation challenges stem from human factors, not technical limitations. The people problem is real.

But sequential gating assumes a stable target - and something deeper. It assumes understanding precedes practice. You learn, then you do. Daniel Lemire makes the case that this gets innovation backwards: "We see something that works, and then we understand it." The pendulum clock was built in 1656; Newton formalized the physics a decade later. Both the linear theory of innovation and the waterfall model in software are forms of what Kevin Kelly calls thinkism - the belief that enough upfront thinking solves problems, setting aside practice and experience.

ADKAR is thinkism applied to change management. Awareness before Desire. Knowledge before Ability. Understand the change, want it, learn it, then do it. But that is not how most people actually adopt AI. They tinker. They stumble into something useful. They understand what they did after they did it. The framework's sequence does not just assume a stable target - it assumes a direction of learning that real adoption often reverses.

The linear model

Each stage gates the next. There is a finish line.

The loop model

No finish line. Knowledge and Ability run in parallel - practice feeds understanding, not the reverse. Reinforcement cycles back to Awareness as the technology evolves.

Three ways AI adoption breaks the sequence

There is no stable end-state. Traditional change has a go-live date. You migrate from the old CRM to the new CRM, and eventually the old one gets decommissioned. AI capabilities evolve continuously - new models, new interaction patterns, shifting best practices. You cannot "complete" Knowledge when knowledge has a half-life of months. You cannot "complete" Reinforcement when the behavior you reinforced last quarter may no longer be the right behavior.

The threat is identity, not workflow. ADKAR's Desire stage asks: what is in it for me? For a new expense system, the answer is straightforward - less paperwork, faster reimbursement. For AI, the question cuts deeper. People are not just learning a new tool; they are renegotiating their relationship with expertise itself. "I spent fifteen years becoming the person who knows how to do this" is not a training problem. It is an identity problem. Desire cannot be manufactured with a lunch-and-learn.

The technology changes mid-adoption. You might build Knowledge and Ability around one generation of tools, then a new model arrives and capabilities shift materially. ADKAR has no mechanism for "the thing we trained on just changed." The Reinforcement stage assumes you are reinforcing a stable practice. But when the practice needs to evolve, reinforcement becomes resistance - the very thing the framework was designed to overcome.

From sequence to loop

The instinct is to discard the framework. I think the better move is to reshape it. The five elements remain useful as a diagnostic, not as a sequence. Instead of gating each stage linearly, you cycle through all five continuously - for each workflow that matters.

Awareness becomes a recurring question, not a launch announcement: what changed since last month? What new capabilities exist? What assumptions no longer hold? Rethinking Assumptions explored this at the tooling level - the same discipline applies at the organizational level.

Desire becomes an ongoing conversation about identity and purpose, not a one-time motivation exercise. The teams I have seen navigate this well are the ones where leaders model the shift themselves - using AI visibly, sharing what worked and what did not, demonstrating that expertise evolves rather than evaporates.

Knowledge and Ability stop being sequential stages and start running in parallel. Lemire's point applies directly: people learn AI by doing, not by studying. The most effective teams I have seen do not gate practice behind training. They let people tinker first - and then formalize what worked into shared knowledge. Not "we trained 200 people in Q2" but "every team has a way to surface what someone discovered this week." This is where progressive disclosure matters: the interface should meet people where they are, not where the training manual assumes they are.

Reinforcement becomes feedback loops, not compliance checks. The Feedback Loop Is the Thing argued that learning routes back into ownership and scope decisions. That is what reinforcement should look like in an AI context - not "did they use the tool?" but "did what they learned change how they decide?"

Readiness over adoption

This reframing connects to the distinction this site has been building between capability and readiness. ADKAR is fundamentally an adoption framework - it asks how to move people from not-using to using. But adoption is a low bar. The harder question is readiness: can the organization absorb the scope of what AI enables without fooling itself?

Shaping, Not Just Shipping named four readiness components - ownership clarity, failure-mode awareness, confidence calibration, and recovery design. These are not ADKAR stages. They are the content that should fill each stage when the change is AI. Awareness without ownership clarity is just noise. Desire without failure-mode awareness is wishful thinking. Knowledge without calibration produces overconfidence. Ability without recovery design produces fragility.

Milestones without endpoints

The obvious objection: if there is no finish line, how do you manage stakeholders and customers? People who fund change programs want to know when the change is "done." Boards want completion dates. Customers want stability.

The answer is not to fabricate an endpoint. It is to change what you report on. Instead of phase completion — "we finished Awareness, now entering Desire" — you report on readiness thresholds crossed. "This workflow can now run with confidence level X under conditions Y, owned by Z." That is a concrete, demonstrable milestone. It just is not a final one.

This is the same distinction between shipping and shaping. Shipping promises a date. Shaping promises a capability with a named owner and a known failure envelope. Stakeholders can track progress through readiness thresholds the same way they track revenue through quarterly results — not because the work is ever finished, but because measurable positions are reported at regular intervals.

The practical shift: replace your change management Gantt chart with a readiness dashboard. For each AI-assisted workflow that matters, track four things — who owns it, what failure modes have been tested, how calibrated the team's confidence is, and what the recovery path looks like when something goes wrong. Those four dimensions move. Report on the movement. That is what "progress" means when there is no go-live date.

The test

When I evaluate an organization's AI change program, I ask three questions:

1. Is your change plan linear or looping? If it has a defined end-state and a go-live date, it is probably built on assumptions that will not hold. Look for continuous cycles instead.

2. Does your Desire stage address identity? If the answer to "what is in it for me?" is only about productivity gains, you have not gone deep enough. People need to see how their expertise transforms, not just how their tasks get automated.

3. When the technology changed last, how long did your training take to catch up? If the answer is "it did not" or "we have not updated it," your Knowledge and Reinforcement stages are already stale.

ADKAR is not wrong. It is designed for a world that moves more slowly than this one - and a world where understanding precedes practice. The framework's contribution - that organizations do not change, individuals do - remains true. The fix is not to abandon the individual focus. It is to stop treating individual change as a phase-gated project and start treating it as a discipline. A loop, not a line. Practice before theory. Observation before formalization.

That is the same conclusion the readiness series reached from a different starting point: the organizations that navigate this well will not be the ones with the most sophisticated adoption playbook. They will be the ones that let people tinker, watch what works, and then build the understanding around it - long after the rollout deck gets archived.