The ADKAR Model Explained for Tech Leaders

Contributor
May 17
6 min read

You can ship a perfect technical migration and have it fail in production not because the code broke but because the people who were supposed to use it didn't. The ADKAR model from Prosci is the most widely cited framework for understanding why this happens and what to do about it.

ADKAR stands for Awareness, Desire, Knowledge, Ability, and Reinforcement. It's a sequential model — each stage builds on the previous one — and it focuses on individual change, which is what the team-level numbers eventually roll up from. If the people in your org aren't moving through these five stages, no amount of process or tooling will land the change.

This guide walks through each stage, what it looks like in engineering work, and the specific failure mode that happens when you skip it.

Why Individual Change Matters for Engineering

Organizational change is the aggregate of individual changes. When you announce "we're moving to Kubernetes" or "we're adopting a new on-call rotation," nothing actually changes until the individual engineers, operators, and managers in the org adopt the new behavior.

ADKAR is useful because it forces you to think one engineer at a time. What does Alice need to know? What does Bob need to be able to do? Where is Carol stuck?

Generic change rollouts ("we'll send a memo and run a training") fail because they assume everyone is at the same stage. They aren't.

A — Awareness

Awareness is knowing that a change is coming and why.

This sounds trivial. It is not. In most organizations, the engineering team finds out about a major change either too late (the migration is already happening and they need to learn the new system on a deadline) or in a form they can't act on (an exec announcement with no detail).

What awareness looks like done well:

People know what's changing in plain language
They know roughly when it's happening
They know why — what business or technical reason drove the decision
They have a place to ask questions and get answers

The failure mode: rumor. When the official communication is thin, rumors fill the gap. The rumor version is usually worse than reality (a re-org rumor sounds like layoffs; a migration rumor sounds like everyone's pet project is being killed). By the time you announce the real plan, the team is already in defensive crouch.

The practical fix: announce changes earlier than feels comfortable, even if the details aren't final. "We're considering moving away from X. We don't have a plan yet. Here's why we're looking at this. We'll share more by Y." Honest uncertainty beats silence.

D — Desire

Desire is wanting to participate in the change. Awareness without desire produces compliance at best and active resistance at worst.

This is the stage that technical leaders most often skip. They assume that because the change is rational, people will support it. They won't, automatically. Adults don't change behavior because a slide deck told them to.

What desire looks like done well:

People can articulate, in their own words, why this change benefits them or the org
They have specific incentives aligned with the new state, not the old one
Their concerns have been heard and responded to (not necessarily granted)
Influential individuals on the team are visibly bought in

The failure mode: quiet resistance. Engineers nod in the all-hands and continue using the old system. They drag their feet on adoption. They pattern-match the new tool to "another mandate from leadership" and wait it out.

The practical fix: find what's in it for them. Faster local builds. Less on-call pain. Cleaner deploys. If you can't articulate a real benefit to the individual engineer doing the work, the change is being imposed for someone else's benefit — that's fine, but you have to acknowledge it and provide adequate incentive in some other form.

K — Knowledge

Knowledge is understanding how to operate in the new state. Documentation, training, runbooks, examples.

This is the stage engineering orgs are best at — sort of. We tend to over-invest in reference documentation (an exhaustive wiki page) and under-invest in the things people actually use (a five-line "common tasks" cheat sheet, a worked example, a pair-programming session).

What knowledge looks like done well:

The first-day-on-new-system experience is documented and tested
Common tasks have worked examples
Edge cases are documented but not the entry point
There's a clear escalation path when the docs don't cover something

The failure mode: the wiki page that everyone agrees is comprehensive and nobody reads. Engineers fall back to asking the migration lead in DMs, the migration lead becomes a bottleneck, and the new system feels harder than it actually is.

The practical fix: write the docs in the order people will use them. Start with "what am I trying to do" pages, not "how the system is architected" pages. Test the docs by giving them to someone unfamiliar and watching them get stuck.

A — Ability

Ability is the actual capacity to do the new thing. This is different from knowledge. Knowing how to write Rust and being able to ship Rust to production are different. The gap between them is practice.

What ability looks like done well:

People have done the new thing at least once with support
The tooling actually works in the way the docs say it does
The environment supports the new pattern (permissions, infrastructure, integrations)
There's time allocated for the learning curve, not just an expectation that it happens on top of normal work

The failure mode: the rollout that assumes "they read the docs, so they can do it." They can't, yet. A first attempt at any new system is slow and full of mistakes. If the rollout schedule doesn't budget for that, the schedule is fiction.

The practical fix: structured first-use opportunities. A hands-on workshop. A "buddy" period where the migration lead is on call. A grace period where the old system is still available so people can learn without pressure.

R — Reinforcement

Reinforcement is making the new state stick. Without it, the org reverts.

This is the stage that's least visible and most important. The team adopts the new tool, the change manager declares victory, and six months later half the team is back to the old tool, the runbooks are stale, and the new system has bit-rotted because no one's responsible for it.

What reinforcement looks like done well:

The new state has owners — specific people whose job includes maintaining it
Metrics show the new pattern is being used, and someone watches them
Backsliding gets detected and addressed (gently — find the friction, don't punish the person)
Wins from the new state get recognized publicly

The failure mode: the change is celebrated and then abandoned. Six months later, "we moved to X" is technically true but practically meaningless.

The practical fix: plan reinforcement at the start, not at the end. Decide upfront how you'll know in three months whether the change actually stuck, and who owns making sure it does.

Using ADKAR as a Diagnostic

The most useful thing about ADKAR isn't as a planning framework. It's as a diagnostic.

When a rollout is going badly, ask: which stage is broken?

People are surprised by the change? → Awareness.
People know about it but don't care? → Desire.
People want to use it but don't know how? → Knowledge.
People know how but can't actually do it? → Ability.
People did it and now they've stopped? → Reinforcement.

Each failure has different fixes. Sending more documentation won't fix a desire problem. Holding more all-hands won't fix an ability problem. Matching the intervention to the actual stage is what makes ADKAR useful.

A Common Mistake

The mistake is treating ADKAR as a sequence you complete once and then move on. It isn't.

Different people are at different stages at the same time. The early adopters are at Reinforcement while half the team is still at Awareness. Your communication and support have to span all the stages simultaneously, with the resources weighted toward where the most people are stuck.

A monthly check-in that asks each affected team "which stage are you at" tells you more than any rollout metric.

When ADKAR Doesn't Apply

ADKAR is a model for adopted change — changes where people have to actively do something different. It's overkill for changes that are invisible to the user (a backend rewrite that preserves the API). It's underkill for changes that involve power, identity, or compensation (a reorg, a comp restructure) — those need conversation and trust, not a framework.

Use ADKAR when the success of the change depends on individual behavior change. Use other tools when it doesn't.

Key Takeaway

ADKAR is a sequential model for individual change adoption: Awareness, Desire, Knowledge, Ability, Reinforcement. Use it as both a planning tool (have we addressed each stage?) and a diagnostic (which stage is the rollout stuck at?). The most common failure is skipping Desire — assuming rational decisions adopt themselves. The second most common is skipping Reinforcement — declaring victory before the change has stuck. Both are fixable if you know to look for them.

ShiftQuality