Change Management Still Works for Your AI Initiative. Just Not at This Pace.

The frameworks for managing change were not built for this.

Kotter published his 8-step model in 1996. Prosci's ADKAR model came shortly after. William Bridges' Transitions framework, which mapped the psychological arc people travel through change, predates both. All three were designed for organizations moving at the pace of multi-year initiatives, where a plan could be written, approved, and executed in relative sequence.

AI disruption does not move in sequence. Your team is navigating new tools, shifting expectations about what expertise is worth, and pressure to produce at speeds that were not possible eighteen months ago. All at once, with no clear finish line in sight.

But here is what holds. The mechanics those frameworks identified have not changed. People do not resist change itself. They resist the feeling of losing ground, of not knowing where they stand. The gap between who they were before and who the situation now demands. It is what Kotter, Bridges, and Prosci were all trying to close. That gap is everywhere right now, and the core steps for closing it are still the right ones.

The challenge is knowing which ones to prioritize, and running them faster than they were designed to move.

Name what is ending, not just what is beginning.

Every major change management model starts here. Kotter calls it establishing urgency, specifically urgency that is honest about what is genuinely at stake. Bridges calls this territory "the ending," arguing that people cannot commit to something new until they have acknowledged what they are leaving behind. ADKAR positions Awareness at the front of its entire model on the same logic.

In AI adoption, this step gets skipped most often. Leaders move, or are pressured to move, directly to tooling decisions, process automation, and efficiency targets. It is easy for the team to come away with the message that what they were doing before does not matter anymore.

Your job as a manager is to name the actual loss before you name the opportunity. Skills that took years to develop are now table stakes. The identity of being the go-to person for a particular process is under pressure. You do not have to solve it. You have to name it. A short conversation that acknowledges what is genuinely hard earns more trust than any kickoff meeting. It also opens the door for your team to tell you where they actually are, instead of performing confidence they do not feel.

Create one small win, fast.

Step six of Kotter's model is generate short-term wins. It is the most skipped step because it does not happen automatically. It requires a manager who is actively looking for it.

In periods of significant disruption, a team's willingness to change is often proportional to whether they have personally seen the new approach succeed. Not in a case study. Not in a vendor demo. In their own work, last week.

Whether you are just starting or feeling like your initiative is stalling, find the person on your team most willing to experiment. Give them a specific opportunity to try something with AI on real work, with low stakes attached to the outcome. Ask them to walk through what they tried and what happened. Let them be honest about the experience, and use what they share to decide what to try next. This is Kotter's mechanism operating exactly as designed. A visible, proximate win reduces the psychological barrier for everyone watching. You do not need a pilot program. You need one early adopter and a meeting where they get to talk about it.

Rebuild your regular rhythms around learning, not just delivery.

Ten minutes per week, per direct report, spent on AI workflow conversations is not overhead. It is the mechanism that makes the change hold.

The last step in ADKAR is Reinforcement. Kotter's final step is to anchor changes in the culture. Both models point at the same reality. The new behavior has to become the expected behavior, not the experimental one. Without this step, most change efforts revert. People slide back to familiar patterns the moment attention on the initiative fades.

For a manager, reinforcement happens in small recurring moments. If AI-assisted work never comes up in your 1:1s, your team will read that as it not being a priority. If your reviews only evaluate what shipped and not how it was built, you are reinforcing the old model without intending to.

The question is what to actually ask. A few that have worked well, and what each one is doing:

What have you seen consistently improve your results lately? The goal is to help them notice their own pattern. People underestimate the workflows that are already saving them time because the savings feel ordinary. Naming the pattern out loud is what turns a one-off experiment into a habit.

Where has the output looked right but turned out to be wrong? This one matters more than it sounds. The failure mode of AI is confident output, and the only way a team gets better at spotting it is by talking about the times they almost missed it. Asking the question directly, and treating the answer as useful information rather than a mistake, is what makes people willing to tell you the next time.

What have you been hesitant to try AI on? This surfaces the adoption barriers that retrospective questions miss. Sometimes the answer is a reasonable boundary, like client-facing communication or production code. Sometimes it is a hesitation worth working through together. You will not know which until you ask.

When you tried [the workflow they mentioned last time], did it change anything for someone else downstream? If you can remember a specific reference, use it. If not, the general version works too: have you noticed your AI-assisted work changing how anyone else on the team approaches theirs? This question teaches direct reports to think past their own output and recognize that their adoption habits ripple outward. It also gives you a read on whether their experiments are reaching the team or staying isolated.

You do not need all four every week. One question, asked with genuine curiosity, will move the conversation farther than a checklist. Their creativity might surprise you if you give them the space to share it.

The job has not changed. The pace has.

These frameworks were not designed for this pace. But they were designed for people. And people have not changed. They still need to understand what is ending before they can commit to what is coming. They still need consistent evidence that the new approach is worth the discomfort. They still need to know the new behavior is the expected behavior, not a temporary experiment.

That is still the job. You are just running it faster now.

There is one thing the old frameworks did not anticipate, though. They were built for change initiatives where the new way of working, once adopted, was relatively stable. AI is not stable. The tools change weekly. The vendors change their pricing without warning. And the work itself produces a kind of failure the old quality controls were never designed to catch.

Next week, I want to write about the two things old change management never had to handle, and what they mean for the manager running point on an AI initiative.