Leadership
Leading AI change: help your team adapt
Lead AI change with clear roles, practical training and honest communication. Plan a bounded pilot, account for review work and define stop conditions.
The organisation buys an AI tool and asks the team to use it. A demonstration looks promising. Two weeks later, one person relies on it for almost everything, another avoids it and the experienced reviewer spends evenings correcting the output.
This is a leadership problem as well as a technology problem. The team needs a shared understanding of the intended use, the limits, the work that changes and the support available. Access to a licence does not provide that understanding.
Leading AI change means organising the conditions under which people can try a use case, question it and decide whether it belongs in their work. Adoption is useful when the workflow improves under acceptable conditions. Tool activity alone is a weaker goal.
Explain the work change in concrete terms
Begin with the task, not a general promise to become “AI-first”. Which part of the work should the system assist? Which part remains a human decision? What is excluded?
A meaningful brief might say: the tool will help prepare an initial summary from approved material; the assigned reviewer will verify the summary against the source; it will not publish or make a customer commitment.
Explain why the use case is being considered and how it will be evaluated. Separate a possible benefit from an established outcome. “We want to investigate whether this reduces drafting effort” is more honest than “This will save everyone hours”.
The leadership guide starts with priorities and decision rights. Those foundations remain necessary when the tool can generate an impressive result before the surrounding process is ready.
Say what is known about roles and what is undecided
People may be asking whether their responsibilities, workload or employment will change. Do not answer with reassurance you cannot substantiate.
Describe the current proposal, any decisions already authorised and the process for unresolved questions. If future role changes are undecided, say so and explain who owns that decision. A manager should not improvise a guarantee about someone’s job.
Give people a route to ask questions outside a public demonstration. A person may feel unable to raise a concern in front of the sponsor who selected the system.
The article on resistance to AI change helps distinguish capability questions, workflow problems and concerns about consequences. Here, the managerial task is to respond with an action or a clear decision route.
Involve the people who perform and review the work
Ask the intended users to map the current task before redesigning it. Include the experienced person who spots errors, the team receiving the output and anyone handling exceptions.
A draft can be quicker to create and harder to verify. A use case can remove work from one role while adding it to another. Participation makes those transfers visible before a benefit is declared.
Use specific questions: which source is authoritative, which mistakes matter, where does checking happen and when should the team use the previous method?
Do not make participation a ceremonial workshop after every material decision has been made. Identify what participants can influence: scope, review criteria, training needs, exception handling or the recommendation about continuation.
If a decision is fixed, explain it. Inviting people to choose something you will not let them change can damage the credibility of the process.
A hypothetical editorial pilot
Imagine a fictional communications team preparing internal briefing notes. The manager wants to test AI-assisted first drafts from an approved source pack. This scenario is hypothetical and makes no claim about an actual client.
The team identifies two work roles: drafting and verification. It finds that checking an unsupported statement can take longer than writing the sentence directly.
The manager therefore narrows the pilot. It covers only a defined type of briefing, uses the agreed source pack and retains human approval. The pilot excludes material with unconfirmed claims and does not automatically publish anything.
The reviewer helps define what counts as usable: statements traceable to the source, no invented facts, correct terminology and an appropriate structure. The manager reserves review time and documents the existing drafting route as a fallback.
The pilot asks whether the complete workflow is useful. It does not assume that a fast first draft means a faster finished briefing.
Train judgement alongside tool operation
Training should cover more than where to click or how to write a prompt. People need to recognise when the output is unsuitable and what to do next.
Give them practice with realistic permitted inputs, a usable result, an error and an ambiguous case. Ask them to explain why they would accept, revise or reject each output.
Amershi and colleagues’ Guidelines for Human-AI Interaction include making capabilities and limitations understandable and supporting correction when a system is wrong. Their research concerns interaction design; it does not establish that one training session will secure adoption or competent use.
Translate the relevant idea into the team’s actual process: where are the approved sources, how is an error reported and who can decide to stop using this output?
The human-in-the-loop workflow guide explains why meaningful review needs criteria, authority and available time.
Give the pilot a manager-owned change plan
Use this original planning worksheet. It is a practical aid, not a validated change model or a compliance assessment.
Swipe or use the arrow keys to see every column.
| Field | Decision to record |
|---|---|
| Purpose | Which task outcome is the pilot intended to improve? |
| Scope | Which people, inputs and use cases are included or excluded? |
| Roles | Who drafts, verifies, approves and resolves exceptions? |
| Capability | What practice and support are needed before use? |
| Workload | Which existing work moves to make room for learning and review? |
| Evidence | What will be observed across the complete workflow? |
| Safeguards | What requires rejection, suspension or specialist escalation? |
| Continuation | Who decides to extend, change or stop the pilot? |
Complete the workload field before asking people to learn during a busy delivery cycle. “Fit it in” is not a resource plan.
Give the pilot an end point. A trial without a review decision can become a permanent arrangement whose limitations nobody consciously accepted.
Make failure reporting a normal part of the process
Tell the team what a useful report contains: the intended task, the relevant input where it can be shared safely, the output problem and its consequence. Use the organisation’s approved reporting channel.
Separate a learning mistake from a deliberate breach of an established rule. Neither should be hidden, but the response and procedure may differ.
Do not praise experimentation publicly while criticising every reported error privately. The team will learn from the response, not the launch presentation.
Avoid a leaderboard that rewards output volume regardless of quality. It can encourage people to produce more drafts while leaving the review burden invisible. Measure the workflow you need, including rejection and rework.
Delegation and accountability helps clarify who can intervene. A reviewer who can flag an error but cannot hold publication has a responsibility without the needed authority.
Separate stop conditions from improvement questions
A stop condition concerns a use that should not continue under the current arrangement. An improvement question concerns whether the workflow could become more useful.
In the hypothetical briefing pilot, an unsupported material claim that reaches the approval stage might require the owner to pause that use case and inspect the control. A preference about paragraph order can belong in the next editorial revision. The appropriate response depends on the agreed exposure and process.
Define these routes before the first serious problem. Otherwise, the team may improvise under deadline pressure.
The NIST AI Risk Management Framework offers a voluntary reference for governing, mapping, measuring and managing AI risks. It does not certify the pilot, establish legal compliance or replace the organisation’s own responsibilities.
For the operational detail, use the AI governance article. For decisions with incomplete evidence, decision-making under uncertainty shows how to record assumptions and review triggers.
Review the whole workload, not just the demonstration
At the pilot review, examine drafting, checking, correction, approval and support. Ask where work disappeared, where it moved and where it became harder to predict.
Compare like-for-like tasks where possible, and record changes in scope or difficulty. A pilot involving only easy examples cannot establish readiness for more complex use cases.
Include the people who disliked the tool and those who found it useful. Their experiences may describe different tasks rather than different levels of enthusiasm.
Avoid converting a few positive comments into a claim about the whole team. The same evidence boundary applies to online consumer psychology: a visible response needs context before it becomes an explanation.
A continuation decision can be limited. You might retain one use case, redesign another and reject a third. The team does not need to defend an all-or-nothing position on AI.
Keep the agreement current after rollout
An approved workflow can change when the system, source material or responsibilities change. Assign an owner to notice and assess those changes.
Maintain a short operating guide: permitted use, review criteria, exception route and fallback. Keep it where the work happens. Update it after a material decision rather than relying on a training recording from the launch.
Check that expertise is still available. If reviewers leave or their workload increases, the original controls may no longer be practical. A process can look stable while the people who made it workable have changed.
Use individual conversations to understand support needs and team reviews to address common process issues. Do not expect every concern to be solved through more prompting practice.
If your AI rollout is creating uncertainty about roles, review work or ownership, tell me about the workflow you are changing. We can clarify the use case, the team support and the conditions for a responsible next step.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
Leadership: how to lead digital teams with clarity
A practical leadership guide for digital teams: clarify decisions, delegate with useful boundaries and support people through feedback and change.
Decision-making under uncertainty: expose assumptions
Make a work decision with incomplete evidence. Separate facts from assumptions, compare options and define a review trigger with a practical record.
Delegation and accountability: clarify who decides
Delegate with a clear outcome, decision authority and review points, so accountability helps the work instead of creating another approval queue.