Six months after her agency's AI triage tool went live, Rosalind Okafor pulled the usage report and felt her stomach drop. She was division chief over 140 case managers at a state child welfare and benefits agency. The vendor had declared go-live a success. The tool was running. But eighty percent of her staff had quietly returned to their spreadsheets and paper checklists. Deployment had happened. Adoption had not, and nothing in the project plan had been designed to notice the difference.

Deployment is not adoption

Think of a GPS (Global Positioning System) unit installed in every agency vehicle. The hardware is in every car, the maps are updated, the satellite connection works, and drivers who have run these routes for fifteen years still trust their paper maps. They know the detour around the school zone at 3 p.m. Nobody has shown them the GPS does. The installation is complete and the behavior has not moved an inch.

That is the difference between deployment and adoption. Deployment means the system is live. Adoption means people use it consistently as part of their standard work. Agencies budget on deployment milestones: the contract closes, the inspector general (IG) check is satisfied, and leadership moves on. Nobody builds a budget line for adoption. That gap is where most government AI implementations quietly fail, and it is invisible in every report that measures whether the system is running rather than whether it is used.

Non-use is only the first of three failure modes, and it is the easiest to spot. The second is staff who use the system and override it on every decision, which produces all of the cost and none of the benefit. The third is worse and quietest: staff who use it without understanding what it does, and therefore make bad decisions with confidence. Misuse is a serious risk in its own right. If staff do not understand how a system works, they may apply it to situations it was never designed for, or trust it further than its accuracy justifies.

Change management is what closes all three gaps. Deploying technology is one thing. Getting an organization to use it, and use it well, is something else entirely. Without change management you get underutilization, misuse or outright rejection. With it, you get the adoption that delivers the value the system was built to provide, and you find out early when you are not getting it.

Why resistance is information, not an obstacle

Government agencies are conservative about change. Staff have been doing their jobs a particular way for years, and an AI system asks them to change how they work. Resistance to that is normal and predictable, and it is the single most useful source of information you will get during a rollout. When staff say "this will not work because of X," the correct first response is to find out whether they are right. They frequently are, and the projects that treat resistance as an attitude problem lose the diagnosis along with the goodwill.

Five sources of resistance turn up in nearly every deployment, each with a legitimate core underneath the complaint.

• Fear of job loss. "This AI will replace me." Address it through clear communication about what the system is for, redeployment planning and skills training. Be careful how far the reassurance goes: AI more often changes jobs than eliminates them, but that is a pattern, not a promise, and nobody in the room can guarantee what the next budget cycle does.
• Loss of autonomy. "I will have to follow whatever the AI recommends." Address it by emphasizing human override and positioning the system as support rather than authority. Staff should override the system when they have good reasons, and the training should teach them when override is appropriate rather than treating every override as a failure.
• Skepticism about fairness. "This AI is biased." Address it by showing the fairness analysis and validation results and discussing concerns openly. Some skepticism here is healthy and should be welcomed. Show the evidence that you tested for bias rather than asserting that you did.
• Complexity. "I do not understand how this system works." Address it with clear explanations of what the system does rather than how it does it, plus training and documentation. Staff do not need to understand neural networks. They need to know which inputs matter and what the output means.
• Workflow disruption. "This changes how I do my job." Address it by designing systems that fit existing workflows, introducing them in phases, and involving staff in the design. Change is uncomfortable even when it is welcome. Support people through it rather than waiting it out.

Underneath all five sit the same five practices. Do not ignore resistance. Engage staff early, in design and testing decisions, so they are invested and better understand the system. Communicate clearly about what the system is and is not, how work will change and what is expected. Provide real support, meaning training, documentation, help desk access and peer mentors. And show respect, because dismissing concerns as technophobia guarantees the concerns go underground rather than away.

Government-specific resistance patterns

On top of the general sources, government adds three that private-sector change management frameworks routinely miss. These are not attitudes. They are structural features of public employment, and no amount of enthusiasm from headquarters makes them go away.

Job security under civil service rules

Civil service protections depend on defined position classifications. When staff see an AI tool handling tasks listed on their position description, they reasonably wonder whether their role is being set up for reclassification or reduction-in-force (RIF) at the next budget cycle. Rosalind's case managers had watched an earlier automation project eliminate twelve data entry positions. Their caution was learned behavior, and telling them that AI changes jobs rather than eliminating them would have been answered with a specific counterexample they had all lived through.

Union contract language

Many government workers are covered by collective bargaining agreements, contracts between the agency and an employee union. These agreements often contain language about how new technology affects job duties and staffing levels. Assigning AI-assisted tasks to a role may trigger a legal obligation to meet and confer, a formal consultation process, with the union before implementation. Rosalind's agency skipped this step. Three months after go-live the union filed a grievance, which gave skeptical supervisors permission to tell staff to wait.

High-stakes decision distrust

When an algorithm recommends whether a child should be removed from a home, or whether a family qualifies for food assistance, the case manager signing the decision carries the accountability. Staff understood that if the outcome was wrong, they and not the algorithm would face the oversight review, the IG audit, or the public records request under Freedom of Information Act (FOIA) law. That asymmetry explains reluctance far better than any training deficit, and it is not resolved by better explaining the model. It is resolved by being explicit about who is answerable for what.

The frozen middle

Between senior leadership and frontline workers sits a layer of supervisors who translate policy into daily operations. In change management this group is sometimes called the "frozen middle." They hold the power to accelerate or stall adoption, and they are often the most skeptical, because they carry accountability for output without having chosen the tool.

A doubting supervisor does not say "do not use that." They say "finish your case notes before you try the new system." The result is invisible from the top and devastating to adoption numbers. Rosalind found four supervisors quietly cooling staff enthusiasm. None were obstructing deliberately. All were uncertain about accountability and about what happened to their own role if the tool worked too well. Winning them over was not a communication task. It was a trust task, and it required answering their questions rather than repeating the message.

This is also where a central-team rollout goes wrong. When a headquarters team designs the change and tells offices what is happening, offices do not feel heard and resist in exactly this quiet way. Involving local leaders, adapting the approach to local context and visibly acting on feedback costs time that a project plan rarely budgets and buys cooperation that no directive can.

Building AI champions at the working level

In every unit, a few workers hold credibility that peers actually trust, earned from track record rather than job title. These are the experienced drivers willing to let the GPS run for a week and then tell colleagues honestly whether it helped. Champions are staff who understand the system, believe it is worth using, and help others adopt it, and they are not necessarily the most technical people in the room.

What a champion needs is a specific and unglamorous list: an understanding of the business problem the system solves, respect from peers, willingness to help others, honesty about the system's limitations, and enough comfort with technology to be unafraid without being an enthusiast. That fourth item is the one selection processes usually get wrong. A champion who will not say what is broken is a marketing asset, not a change agent, and staff can tell the difference within one conversation.

Rosalind identified four such workers per unit through informal conversations with supervisors. She chose people who were respected, skeptical enough to be credible, and not already enthusiastic boosters. She gave them three things before anyone else: access one month before general rollout, four hours of hands-on lab time on their own open cases, and explicit permission to report every problem they found. Those champions became her honest peer sources, able to say "I ran my last eight cases through it and here is what I found," which carries more weight than any executive memo.

Developing champions follows a pattern worth copying. Identify them early, before the system is deployed. Involve them in testing and validation. Give them deep training and direct access to the experts. Make them part of the deployment team rather than recipients of it. Give them authority to help others. And recognize their role publicly, because the time they spend helping peers is time not spent on their own caseload, and pretending otherwise is how champion programs quietly end.

For a large deployment, connect them into a network: a champion in each office or team, meeting monthly for training and sharing, helping with local training, acting as the first line of support for their peers, and feeding problems back to the central team. Support the network deliberately with detailed documentation, training on how to teach others, an escalation path for questions they cannot answer, and acknowledgment of the effort. A champion network without escalation paths turns your best people into a help desk with no backup.

Training for different audiences

One training session for all audiences is a common and expensive mistake. The GPS matters differently to a fleet manager reviewing routes, to a driver navigating them, and to a mechanic verifying the hardware. AI training also differs from ordinary software training in one specific way: people need to learn both how to use the system and what it does and does not do. The second half is what prevents misuse, and it is the half that gets cut when the schedule slips.

Executives need enough to defend the program and to override AI output when policy demands it, not to use the tool daily. Frontline case managers and benefit specialists need hands-on labs using their actual cases, so they see where the tool helps, such as flagging incomplete documentation or surfacing eligibility factors that volume makes easy to miss, and where it falls short. They also need a written protocol for disagreeing with an AI recommendation and confirmation that exercising professional judgment is protected. Put that protection in writing, because a verbal assurance evaporates the first time an override is questioned.

IT and data staff need their own track: how the AI tool connects to legacy systems, what happens when data feeds fail, and what the security architecture requires. Legacy integration is typically the most fragile part of a government AI deployment, and IT staff take the 2 a.m. call when something breaks. Training them last, or not at all, is how a recoverable outage becomes an adoption-ending one.

Format matters as much as content. Classroom sessions build community and allow real questions. Online modules give reach and let people work at their own pace. Hands-on practice is essential, because nobody learns a system by watching one. Job aids and documentation are critical, since people forget training and need something to reach for. Peer mentoring is the most effective single lever for actual behavior change. And a simulation or sandbox environment lets staff make their first mistakes somewhere those mistakes cost nothing.

Phased rollout instead of big-bang go-live

Rosalind's original implementation was a big-bang go-live: every unit, every worker, one date. When eighty percent of staff quietly stopped using the tool, there was no controlled comparison to learn from and no small success to point to. A phased rollout would have cost eight additional weeks up front and saved six months of lost adoption. Deploying everywhere at once also means that when problems emerge they emerge everywhere at once, across every office, faster than any support team can respond.

Her corrected sequence starts small: select one volunteer unit of eight to fifteen people, run for eight weeks while measuring adoption metrics, adjust training and support, then expand. The volunteer unit becomes the credibility base. When staff in later units ask whether the tool works, you have colleagues at the same agency doing the same job who can answer. You also collect real override rate data, meaning how often staff accept or reject the AI's recommendations, which tells you whether the tool fits your actual caseload. A model trained on national data may perform differently in your county.

For a larger organization the same logic extends into four phases with widening scope and loosening oversight.

• Phase 1, pilot, weeks 1 to 4. Deploy to one or two offices, or to two or three champion users. Monitor very closely with daily check-ins and make quick adjustments. The question being answered is whether the system works and whether people use it.
• Phase 2, early adoption, weeks 5 to 12. Expand to three to five offices with weekly check-ins and more independent operation. The question is whether it scales and what training people actually need.
• Phase 3, broader rollout, weeks 13 to 20. Expand to half the organization with biweekly check-ins. The question is what the adoption rates look like at scale.
• Phase 4, full rollout, weeks 21 onward. Expand to the entire organization with monthly check-ins, ongoing support and continuous improvement.

Each phase ends in an explicit decision rather than a date. Are we proceeding, proceeding with conditions, or stopping to redesign? What did we learn, and what changes does it imply? What support do users need in training, documentation or tooling? What system changes are needed for performance, usability or features? The rule that makes the whole structure worth having is the unpopular one: do not move to the next phase if the pilot has issues. Fix the problems before expanding them.

Measuring adoption, not deployment

Rosalind's agency measured go-live as the success milestone. After that, nobody measured anything. She built a simple adoption dashboard tracking four metrics from system logs.

• Logins per week per eligible user. The baseline signal of whether people are engaging at all.
• Tasks completed with AI assistance. Cases where a worker used AI output at any point, not just logged in.
• Override rate. How often staff accepted or rejected the AI's recommendation. Above 40 percent suggests the tool does not fit your caseload. Below five percent may mean workers are rubber-stamping outputs without review.
• Staff satisfaction survey score. A ten-question quarterly survey on whether the tool saves time and whether people feel supported when something goes wrong.

These four metrics take about three hours per month to compile, and they give an early signal before adoption quietly collapses. That override band deserves particular attention, because it is the only metric on the list that fails in both directions. A high rate says the model does not match your work. A very low rate says nobody is really checking, which looks like success on every other measure you have.

A fuller program separates three families of measure. Adoption metrics ask who is using it: usage rate as a percentage of staff, with a common target of 80 percent or more within two months; frequency, whether daily, weekly or monthly; coverage, meaning what percentage of applicable cases actually go through the system rather than around it; and consistency, whether offices use it the same way or vary widely. Rosalind's usage report was the mirror image of that target, which is precisely why it read as a shock rather than a trend.

Engagement metrics ask whether people are with you: confidence, surveyed rather than assumed; understanding, tested rather than surveyed; adoption pace against the phase schedule; and training completion rates. Operational metrics ask whether the thing works: override rate, error rate, actual time saved against what was promised, and how quickly reported problems get resolved. Share a monthly view with leadership covering usage by office, overall accuracy and fairness, issues reported and resolved and outstanding, training completion, and whether the adoption trajectory is on track. That last line is what turns a surprise into a manageable problem.

Union engagement before announcement

The most consistent pattern across failed government AI rollouts is that leadership announced before briefing the union. The union found out the same day as line staff, filed a grievance, and gave skeptics permission to wait indefinitely. The grievance itself is rarely the fatal part. The permission is.

Brief union stewards, the elected worker representatives who handle grievances, at least four to six weeks before any announcement. Identify contract provisions that might be triggered and explain how you plan to address them. Rosalind renegotiated one paragraph of contract language governing AI-assisted recommendations before her corrected rollout. It took eleven weeks and one formal meet-and-confer session, and it removed the grievance threat before it could stall adoption again. Eleven weeks is a long time in a project schedule and a short time compared with the six months she lost the first way.

The drivers who know these roads are not the enemy of the GPS. They are the test of it. If you cannot show them the tool is worth trusting, you have achieved installation, not adoption.

Anti-Patterns to Avoid

Each of these has been the cause of death on a real government rollout, and most of them look like competence at the time.

• Build it and they will come. The system is technically ready, so you deploy it and assume that if it is good, people will use it. Nobody uses it because nobody knows about it or understands it. Build change management into the project plan from the start, with its own resources and its own time, rather than treating adoption as the phase after the work is finished.
• Training as the entire change plan. You run a short training session and expect adoption to follow. Adoption requires ongoing support, reinforcement and community. Training is one component alongside communication, champions, support structures and a genuine cultural shift, and none of the others are optional because the training went well.
• Headquarters designs, offices comply. A central team designs the change and tells offices what is happening. Offices do not feel heard and resist, usually silently. Involve local leaders and champions, adapt the approach to local context, and act visibly on the feedback you asked for.
• Big-bang deployment. You go live everywhere simultaneously and problems emerge across every office at once, faster than any team can respond. Phase the rollout and learn from each phase before expanding it.
• Working around the resisters. Some staff resist, so you route around them and hope. They quietly continue the old process, and because they are often the most experienced people, others follow. Engage them, understand the concern, and give them room to adapt at their own pace within reason.
• Promising job security you cannot guarantee. "This will not cost anyone their job" is the most tempting sentence in the rollout and the one most likely to be remembered against you. Staff who have watched positions disappear before will weigh your assurance against their own experience. Say what you actually control, such as redeployment planning and skills training, and do not stake your credibility on a budget decision that is not yours.
• Treating training as misuse prevention. Training reduces misuse. It does not prevent it, and a full training completion rate tells you people attended, not that they understand the system's limits. Pair training with monitoring that would actually catch misuse if it happened.
• Celebrating a low override rate. A rate near zero looks like trust and often means staff have stopped reading the output. If overrides fall sharply, investigate before you report it as an adoption win.
• Announcing before consulting. Telling the workforce and the union at the same moment converts a manageable contract question into a grievance, and hands every undecided supervisor a reason to wait.

Practice Prompts

Work these against a system your agency has actually deployed or is about to.

• Design a full change plan. For deploying an AI benefits eligibility system across 50 field offices, work out how you would manage resistance, who you would engage as champions, what training you would provide to each audience, how you would structure the phased rollout, and which metrics you would track.
• Answer the hardest objection. Write your specific response to this concern: "This system will let us deny benefits to people who deserve them because the AI is wrong." Answer it as you would to a room of case managers, not in a memo.
• Build a champion network. Work out how you would identify champions, develop them, support them, connect them to each other, and measure whether they are actually making a difference.
• Find your frozen middle. List the supervisors between you and the frontline. For each, write down what they are accountable for and what the new system changes about that, then decide which conversation you owe them first.
• Audit your own metrics. Look at what your agency currently reports about an AI system. Separate the deployment measures from the adoption measures, and note which of the adoption metrics in this lesson you could produce from existing logs this week.

Reflection

Reflect on an organizational change you have been part of, whether a new process, system or policy. What helped adoption? What hindered it? How would better change management have improved the outcome? Then apply that experience to these.

• If eighty percent of my staff quietly stopped using a system tomorrow, how long would it take me to find out?
• Which of my supervisors would tell me they think this is a bad idea, and which would simply not mention it?
• Have I ever promised staff something about job security that I did not actually control?
• When someone on my team overrides an AI recommendation, does anything good happen to them, or only paperwork?
• Who in my agency has to be consulted before an announcement, and have I confirmed that rather than assumed it?

Glossary

• Change management. A systematic approach to managing an organizational transition from a current state to a desired future state, covering communication, training and cultural change.
• Adoption rate. The percentage of the target population actually using a system as intended, measured over time.
• Champion. A staff member who understands the system deeply, is respected by peers, and helps others learn and adopt it.
• Resistance. Opposition or reluctance to change, stemming from sources such as fear, skepticism or workflow disruption, and usually containing information about a real problem.
• Phased rollout. Gradual deployment across an organization in planned stages, starting with a pilot and expanding based on what each stage teaches.
• Frozen middle. The supervisory layer between leadership and frontline staff, which can accelerate or stall adoption without ever issuing a directive.
• Override rate. How often staff accept or reject an AI recommendation. Diagnostic in both directions, since too many overrides suggest poor fit and too few suggest rubber-stamping.
• Meet and confer. A formal consultation process with an employee union that may be legally required before new technology changes job duties.

Related Lessons

Change management sits inside a project, and these lessons cover the phases on either side of it.

• How AI Projects Differ from Traditional IT explains why an AI deployment needs an adoption phase that a traditional system rollout does not.
• Requirements Gathering for AI covers the early staff involvement that prevents much of the resistance described here.
• Working with AI Vendors and Contractors addresses the vendor relationship behind the go-live declaration that Rosalind's agency accepted at face value.
• AI Pilot Program Design goes deeper on structuring the first phase so that it produces usable evidence rather than just an early launch.
• Measuring AI Impact takes the metrics discipline further, into whether the deployed system delivered the value it promised.
• Human-in-the-Loop: Design and Implementation covers the override protocol and the professional judgment protection that frontline staff need in writing.

Closing

Change management turns a technology deployment from a one-time event into an organizational journey. Done well, systems get adopted and deliver value. Skipped, they sit on shelves while the usage report tells a story nobody reads until six months in. The most effective approach treats adoption as shared responsibility: the central team provides strategy and support, local leaders and champions drive adoption in their own context, staff get training and help when they need it, and leadership stays engaged and responsive rather than declaring victory at go-live.

Expect it to take time. Full organizational adoption is generally a matter of months rather than weeks, so plan on the order of three to six months and resist the temptation to read week-one numbers as a verdict. Rosalind's second rollout worked not because the tool changed but because the people affected were consulted before the announcement, trained on their own cases, represented by champions who were free to say what was broken, and measured on something more honest than whether the system was switched on.

Key Takeaways

• Deployment and adoption are different milestones. A live system staff do not use is a deployment. Build separate accountability, metrics and budget for the adoption phase after go-live.
• There are three failure modes, not one. Nobody using it, everybody overriding it, and people using it without understanding it. The third is the quietest and produces confident bad decisions.
• Resistance carries information. Job-loss fear, loss of autonomy, fairness skepticism, complexity and workflow disruption each have a legitimate core. Listen for the real problem before answering the objection.
• Government resistance is specific and structural. Civil service classification fears, union obligations and FOIA accountability explain reluctance better than generic change fatigue. Address each directly rather than through messaging.
• The frozen middle controls daily adoption. Skeptical supervisors who quietly cool enthusiasm can stall a rollout without issuing any directive. Engage them on trust and accountability, not compliance.
• Champions must be free to say what is broken. Pick respected, skeptical frontline workers, train them first on real cases, and give them explicit permission to report every problem. A champion who only says good things convinces nobody.
• Phase the rollout: pilot, measure, course-correct, expand. Four phases with widening scope and loosening check-in cadence, and a hard rule that you do not advance a phase while the previous one has unresolved issues.
• Train each audience for its actual job. Executives, supervisors, end users, auditors and monitoring staff need different content and different amounts of time, and end users need hands-on practice on their own cases.
• Override rate is diagnostic in both directions. Above 40 percent suggests the model does not fit your caseload. Below five percent suggests rubber-stamping. Both warrant investigation, and only one of them looks like a problem.
• Brief union stewards four to six weeks before any public announcement. Proactive engagement on contract language removes the grievance as an adoption obstacle before it becomes one.

Frequently Asked Questions

How do I answer "will this take my job?" honestly? Say what you actually control and no more. You can speak to redeployment planning, the skills training on offer, and what the tool is designed to take off their desk. You cannot promise what the next budget cycle decides, and staff who have watched positions eliminated before will test any promise against that memory. An honest limited answer survives contact with reality. A generous one becomes the sentence they quote back to you, and it costs you every other assurance you have made.

Our usage numbers look good. Are we done? Check coverage and override rate before you celebrate. High logins with low coverage means staff open the system and then do the work elsewhere, which is non-adoption wearing a costume. A very low override rate is the other trap: it can mean the system is excellent, and it can mean nobody is reading the output before accepting it. Sample some accepted recommendations and see whether a human would have reached the same conclusion. Usage tells you people are present, not that the work is better.

What if the pilot unit says the tool is not good enough? Then the pilot did its job and you have saved the cost of finding out at scale. Do not advance the phase. Work out whether the gap is training, workflow fit or the model itself, because the fix is different for each, and a model that does not fit your caseload will not be fixed by more enthusiasm. This is also the moment to check your override data, since a high rate in the pilot is exactly the signal that the tool does not match the actual work.

We already announced. Is the union conversation still worth having? Yes, and quickly. Late engagement is worse than early engagement and much better than none, because the outstanding question is not only whether a contract provision was triggered but whether supervisors believe the process was legitimate. Identify the provisions that may apply, ask for the meeting, and be straightforward that the sequencing was wrong. Agencies are judged on how they respond as much as on what happened.

How do I keep champions from becoming an unpaid help desk? Budget the time and cap the load. Their peer support is real work, so it should be visible in their assignment rather than absorbed on top of a full caseload, and their contribution should be recognized publicly. Give them an escalation path for questions they cannot answer, so that a hard problem goes to the central team rather than to a champion improvising. Champion programs usually fail from exhaustion rather than from disagreement.