Most organizations didn't decide to adopt AI. Their people started using it, a few at a time, and now leadership is asking what the policy is, where the savings are and whether anyone is checking the output. If that sounds familiar, you don't have a technology problem. You have a change management problem, and it has to be led from the top of the engineering organization.
This post sets out a five-step approach to AI change management for directors and heads of engineering: what to decide first, what to put in place before you scale, how to change work rather than just tools, and how to tell whether any of it is working.
What AI change management actually is
AI change management is the work of helping an organization change how it works because AI tools are available: which tasks people do, who reviews what, which skills matter and who is accountable when something goes wrong. Buying licenses is procurement. Running a training session is enablement. Change management is everything that decides whether the new way of working holds after the novelty fades.
It borrows from the classics. Kotter's Leading Change (1996) stresses urgency and short-term wins; the Prosci ADKAR model breaks individual change into awareness, desire, knowledge, ability and reinforcement. You don't need to adopt a framework wholesale. Remember only that each treats change as something people go through, not something a rollout delivers.
Why AI change is different from other transformations
Most transformation playbooks assume a change that leadership designs, announces and rolls out. AI usually arrives the other way round.
| Usual transformation | AI adoption |
|---|---|
| Starts at the top, then cascades | Starts with individuals, often unsanctioned |
| One defined end state | The tools and their limits change every few months |
| Risk is mostly delivery risk | Risk includes data leaving the company, wrong output that looks right, and unclear accountability |
| Resistance is visible | Enthusiasm and quiet distrust sit in the same team |
| Success is "everyone is on the new process" | Success is "the work is better", and that is harder to see |
Two consequences follow. You are not starting from zero, so your first job is to find out what is already happening, not to announce a launch. And because the tools keep changing, design a standing capability to adapt, not a one-off migration.
Step 1: Start with problems, not tools
"We need an AI strategy" is a weak starting point because it makes the tool the goal. Richard Rumelt's Good Strategy / Bad Strategy makes the general point: a strategy begins with a diagnosis of the real challenge, then a guiding policy, then coherent actions. Apply the same order here. For the structure of a short strategy document, see a one-page technical strategy.
Do this in three moves:
- Survey what exists. Ask each team lead which AI tools their people use, for what, and what happened. If it feels like an audit, you'll get silence.
- List candidate workflows. Look for work that is high-volume, text-heavy and reviewable: code review preparation, test drafting, incident summaries, support triage, documentation, ticket grooming.
- Pick two or three and write a hypothesis for each.
A hypothesis is specific. Say a platform team spends a large share of its week answering the same internal questions. The hypothesis might read: "If we give the team an assistant grounded in our runbooks, repeat questions drop and the answers stay correct. We'll know in six weeks by comparing question volume and the rate of corrected answers." That is a bet you can win or lose. It is also the same discipline as a research bet with kill criteria: decide in advance what would make you stop.
Step 2: Set guardrails before you scale
Guardrails are what let people move fast without asking permission each time. Without them, careful people stop using the tools and careless people don't.
Start with a simple data classification that engineers can apply in seconds:
| Category | Examples | Rule |
|---|---|---|
| Green | Public documentation, open-source code, your own non-sensitive drafts | Any approved tool |
| Amber | Internal code, internal designs, anonymized incident data | Only tools with approved contractual terms on data retention and training use |
| Red | Customer personal data, credentials, unreleased financials, security vulnerabilities | Not allowed in external tools without a specific, documented approval |
Then add three rules that matter more than the details of the table:
- A named human is accountable for every output. Generated code, analysis or text carries the name of the person who shipped it. "The tool wrote it" is not an answer in a review or an incident.
- One page, not twenty. If your policy needs a lawyer to read it, engineers will read a forum thread instead. Involve security and legal, and ask them for a policy a new hire can follow.
- A way to ask for exceptions. People will hit cases the rules didn't foresee. A lightweight process that expires exceptions instead of letting them pile up keeps you informed and keeps the rules honest.
Legal and regulatory requirements vary by industry and region, so confirm them with counsel.
Step 3: Change the workflow and the roles, not just the tools
A tool dropped into an unchanged process mostly moves the bottleneck. If drafting code or documents gets faster, the queue forms at review, testing or decision-making. Walk through one pilot workflow end to end and ask four questions:
- Where does the time go now? The constraint has probably moved.
- Who checks the output, and do they have the capacity? Reviewing generated work well is real work.
- What skill is now more valuable? Judgment, precise specifications and spotting a plausible mistake.
- What do people learn by doing this task? If juniors used to build skill through exactly the work you've automated, you need another route to that skill, such as pairing, structured review or rotations. Otherwise you save effort this year and run short of senior engineers later.
Roles and team boundaries may need to move too. If one team becomes the de facto owner of AI tooling, decide deliberately whether it is a platform team that serves others or an enabling team that coaches and then steps back. The tools in drawing team boundaries before a reorg apply here: check cognitive load and dependencies before you create a new team that everyone must go through.
Step 4: Bring people with you
People's reactions to AI at work range from excitement to real worry about their jobs. Treating the worry as "resistance to be managed" is the fastest way to confirm it.
What works better:
- Be honest about what you know. If you can't promise how roles will look in three years, don't. Say what you do know: what you're trying, what you'll never do (for example, using AI output to rank individuals), and when you'll update people.
- Find the credible early adopters, not the loudest. Everett Rogers' work on the diffusion of innovations describes how new practices spread through people others trust. Ask each team who they'd copy, and give those people time to experiment and share what failed, not only what worked.
- Make it safe to report problems. Amy Edmondson's research on psychological safety shows that teams learn faster when members can admit mistakes without being punished. An engineer who found that a tool produced a subtle bug needs to feel free to say so in the open.
- Teach the skill, not the product. Giving context, checking output and knowing when not to use a tool outlast any feature list. Managers can start with using an AI assistant in their own work.
- Reinforce what you want. In ADKAR terms, the last step is the one most often skipped. If your performance and promotion criteria reward only speed, people will skip the checking you asked for.
Step 5: Measure outcomes, not usage
Counting active users or prompts tells you who logged in, not whether the work improved. Measures that are easy to collect are also easy to game, and Goodhart's law applies: once a measure becomes a target, it stops being a good measure.
Pair every adoption measure with an outcome and a quality check:
| Question | Example measure | Watch out for |
|---|---|---|
| Are people using it? | Share of a team using an approved tool weekly | Usage that is performative |
| Is work flowing faster? | Lead time for a change, cycle time on the pilot workflow | Speed gained by pushing effort into review |
| Is quality holding? | Change failure rate, defects found after release, rework | Quality that slips quietly for a quarter |
| Do people think it helps? | Short quarterly survey, with free text | Only hearing from the enthusiasts |
| Are we safe? | Policy exceptions requested, incidents involving data or generated output | Low numbers because people stopped reporting |
The research behind Accelerate (Forsgren, Humble and Kim) and the DORA program found that software delivery performance has to be read as throughput and stability together. That is the right lens for AI as well: faster output that breaks more often isn't progress. Decide your baseline before the pilot starts. If you didn't measure before, you cannot claim an improvement after.
Mistakes that stall AI adoption
- Mandating usage targets. "Everyone uses it daily" produces activity, not value.
- Treating it as an IT rollout. Licenses get bought, workflows stay the same.
- Banning first, thinking later. A blanket ban moves usage onto personal accounts, where you have no visibility at all.
- Skipping the build-or-buy question. Run vendor choices through a build-or-buy framework, including the cost of switching later.
- Declaring victory after the pilot. Pilots run on enthusiasm and attention. Check again at six months, when both have faded.
Frequently asked questions
Who should own AI change in an organization?
One accountable executive sponsor, with a small cross-functional group: engineering, security, legal, HR and a few team leads. The sponsor owns outcomes. The group owns the guardrails and shares learning. Avoid handing it to a single enthusiast with no authority.
How long does AI adoption take?
Weeks for a pilot, several quarters for habits and roles to settle. Review on a fixed cadence, such as quarterly.
How do you handle people who don't want to use AI?
Find out why first. Some have good reasons: quality problems in their domain, data concerns, or a workflow where it doesn't help. Be firm on outcomes and policy, flexible on method.
A 90-day starting plan
- Weeks 1–2: survey current tool use in every team, with a promise that nobody is being audited.
- Weeks 2–4: publish a one-page data and accountability policy with security and legal, plus an exception route.
- Weeks 3–6: choose two or three workflows, write a hypothesis and baseline for each, and name an owner.
- Weeks 6–10: run the pilots, and review the surrounding process (review, testing, handoffs) along with the tool.
- Week 10: hold a retrospective with the pilot teams and decide what to scale, change or stop.
- Week 12: update role expectations, onboarding and promotion criteria to match what you learned, and tell the organization what changed and why.
If you take one step this week, make it the first: ask your team leads what people are already using. What you learn will shape every decision after it. The Expert study guide covers the wider skills of leading change like this: strategy, stakeholders and organizational design.