Leading people through AI change: a guide for people leaders

Most AI rollouts do not fail on launch day. Launch day usually goes well. Licences are switched on, a town hall is held, a few enthusiastic people post screenshots in the team chat and the sponsor reports strong early uptake. The trouble starts a week or two later, when the novelty fades and the work goes back to being done the old way.

The people who decide whether that happens are rarely the executives who approved the budget or the technology team that configured the tools. They are the people leaders: team leaders, managers and heads of function who set the week, review the work and decide what counts as done. If a manager still asks for last quarter's template, on last quarter's deadline, the new tool loses. If a manager makes room for the team to try a new way of producing that template, and accepts the result, the tool has a chance.

This guide is written for those people leaders, and for the L&D, HR and transformation teams who support them. It covers why AI change stalls, what a manager can actually do about it, how champions fit in, what to say to a team that is anxious or sceptical, how to measure use without turning it into surveillance and how to keep going once the first burst of enthusiasm has passed. It does not assume any particular tool, and it does not quote prices.

Disclosure: The S Curve is published by Collective Campus, which runs AI training and AI change programs for teams. Where this guide mentions Collective Campus programs, the details come from our own public pages. Other claims are linked to their sources at the end.

Why AI change is a people leader problem

There is a familiar pattern in the public research on AI adoption. Use is widespread and value is uneven. McKinsey's 2025 State of AI survey found that 88 percent of respondents report regular AI use in at least one business function, while only about one third say their organisations have begun to scale it. Most are still experimenting or piloting. The same survey reports that organisations seeing the most value are nearly three times as likely as others to say they have fundamentally redesigned individual workflows.

That last finding matters for people leaders. Redesigning a workflow is not something a central team can do from a distance. A workflow lives inside a team. It includes who starts a task, what inputs they use, who reviews it, what the review looks for and where the output goes next. The person with the most influence over all of that is the team's manager.

In practice this means AI change is less like a software rollout and more like any other change in how work is done. It needs someone close to the work to say "this is how we do it now", to make room for people to practise and to notice when the old way creeps back. Executives can set direction. Technology teams can provide safe tools. Only people leaders can change the week.

There is also a simpler reason managers matter. People take their cues from the person who reviews their work. If a manager never mentions the new tools, never uses them visibly and never asks how a piece of work was produced, the team will reasonably conclude that the tools are optional. If the manager asks, shows and accepts new kinds of output, the team will conclude the opposite.

Why rollouts stall in week two

The stall is predictable enough that it is worth naming its causes. Most of them have nothing to do with the technology.

The review still expects the old output

The most common cause is that the work is still reviewed against the old standard. Someone uses a tool to draft a report in a new structure, and the reviewer marks it up against the old template. Next time, the person skips the tool and builds the old template directly, because that is what gets approved. Within a fortnight, the tool is a tab that stays closed.

People are doing the work twice

A second cause is double handling. Early on, using a new tool well takes longer than doing the task the familiar way. If nobody reduces the load elsewhere, people end up doing the work twice: once to learn and once to meet the deadline. The deadline wins.

Nobody owns peer support

Most teams have a few people who pick up new tools quickly. They try something, it works and they drop a tip into a chat. Then the tip disappears. Nobody's role is to help a colleague apply the tip to their own job, so the learning stays with the early adopters and never becomes the team's way of working.

The rules are unclear

People are understandably cautious when they are not sure what they are allowed to do. Can they paste client material into the tool? Can they use it on personnel matters? Does the output need to be labelled? When the answers are vague, careful people do nothing and less careful people do whatever they like. Both outcomes are bad for the organisation.

Training was a tour, not practice

Finally, many first sessions are demonstrations. A trainer shows what the tool can do on a generic example, the room is impressed and everyone goes back to their desk without having changed a single task they actually own. A tour builds awareness. It rarely builds a habit.

None of these causes is solved by more licences or a bigger launch. Each one is solved, or at least reduced, by a decision a people leader can make.

What people leaders actually need to do

It helps to be concrete. Below are the moves that make the biggest difference, in roughly the order a manager would make them.

Pick one task, not the whole job

Start with one task the team already owes on a regular basis. A weekly status update, a first draft of a client response, meeting notes turned into actions, a research summary or a monthly report are all common starting points. The task should be real, recurring and owned by named people.

Picking one task does two things. It makes the change small enough to try this week. It also gives the team a shared example to talk about, which is far more useful than a general instruction to "use AI more".

Change the review, not just the tool

Once a task is chosen, decide with the team how the new version will be reviewed. What does a good AI assisted draft look like? Which parts must a person still check? What source material is allowed? Write this down in a few lines and agree it with whoever reviews the work.

Then make sure the review actually accepts the new output. If the manager is the reviewer, this is easy. If the reviewer sits elsewhere, bring them into the conversation early. A new workflow that is rejected at review will be abandoned.

Make time to practise

People need time to get the new way of working to the point where it is faster than the old way. That time has to come from somewhere. A manager can protect it by moving a deadline, removing a lower value task for a few weeks or setting aside a short block each week for the team to practise on real work.

This does not need to be elaborate. A regular half hour where the team brings one piece of work, tries the new approach together and compares results is often enough to carry people past the awkward early stage.

Use the tools visibly

Managers who use the tools themselves, and say so, send a clear signal. This does not mean performing enthusiasm. It means mentioning that a draft started with a tool, showing how it was checked and being honest about where it fell short. That honesty matters as much as the use. It shows the team that judgement still counts.

Ask how work was produced

A simple question changes behaviour over time: "how did you put this together?" Asked with curiosity rather than suspicion, it invites people to share what worked, what did not and what they would change. It also surfaces good practice the manager can pass on to the rest of the team.

Close the loop with the team

Every few weeks, look back with the team. Which tasks have changed? Which have drifted back? What got in the way? What should be tried next? This short review keeps the change visible and gives people a regular place to raise concerns.

Champions: what they are and what they are not

Most successful AI changes rely on a small group of internal champions. Champions are people the team already trusts, who are willing to practise on their own work and help colleagues do the same. They are not a replacement for managers, and they are not an unofficial help desk.

Give champions a named role

Microsoft's adoption guidance on defining an AI champion role and charter makes a useful point. A champion needs a named purpose, a clear list of what they are responsible for and a boundary around what they hand back to IT, risk or the people who own the policy. Without that, champions either burn out answering every question or quietly stop.

A one-page charter is usually enough. It should say who the champion supports, how much of their week the role takes, what they do (for example, run a short practice session each fortnight and maintain a set of worked examples) and what they do not do (for example, approve new tools or answer legal questions).

Choose people for trust, not just enthusiasm

The keenest early adopter is not always the best champion. A good champion is someone colleagues already go to for help, who explains things patiently and who is honest about limits. Enthusiasm helps, but credibility matters more.

Make the manager part of the deal

A champion without a supportive manager will struggle. Their manager has to agree to the time the role takes and back the champion when they suggest a change to how the team works. When a champion program is set up, it is worth asking each champion's manager to sign off the charter.

Turn tips into worked examples

The most valuable thing a champion can produce is a worked example: a written description of how a specific task is now done, with the inputs, the steps, the checks and a sample output. A colleague should be able to follow it without the champion sitting beside them. Tips in a chat are easily lost. A worked example can be reused across teams.

Keep a monthly rhythm

Champion networks tend to fade after the first few months unless something keeps them going. A regular monthly meeting, where champions share what worked, what failed and what their teams need next, is a simple way to keep the network alive. Someone has to own that meeting and keep it on the calendar.

What to say to the team

Managers often ask what to actually say. The words matter less than the honesty behind them, but a few scripts can help.

When launching

"We are going to try a new way of doing one task, starting with the weekly update. Here is what we are trying, here is what you are allowed to use and here is what still needs a person to check. It will feel slower at first. That is expected. We will look at how it is going in three weeks."

When people are anxious about their jobs

Anxiety about AI and job security is real and should not be dismissed. A manager cannot make promises the organisation has not made. They can be clear about what they know.

"Nobody here has every answer about where this goes over the next few years. What we do know is what the team is doing now and why. These tools are being used to take the grind out of specific tasks so the team has more time for the work that needs judgement. If anything changes about roles, the team will hear it directly from its manager, not through a rumour."

When people are sceptical

Sceptics are useful. They often spot real weaknesses that enthusiasts miss.

"You may be right that it doesn't help with this task. Let's test it properly on two or three real examples and compare. If it doesn't save time or improve quality, we will drop it for this task and try somewhere else."

When something goes wrong

Mistakes will happen. A tool will produce an inaccurate summary, or someone will paste material they should not have.

"Thanks for raising this. Let's work out what happened, fix the immediate problem and update the checklist so it doesn't happen again. Nobody is in trouble for raising it. The bigger risk is people hiding problems."

That last point connects to a broader idea in team research.

Psychological safety and AI change

Google's re

research on team effectiveness, often called Project Aristotle, found that psychological safety was the most important of five dynamics that set effective teams apart. The other four were dependability, structure and clarity, meaning and impact. Psychological safety, in this sense, is the shared belief that it is safe to take interpersonal risks: to ask a question, admit a mistake or suggest an idea without being embarrassed or punished.

AI change depends heavily on it. People need to admit they do not know how to use a tool well. They need to share drafts that are not perfect. They need to report when something went wrong, especially where data or accuracy is involved. In a team where mistakes are punished, people will either avoid the tools or use them quietly and hide the results. Neither is good for quality or risk.

Managers build psychological safety through small, repeated behaviours. They ask questions rather than handing down answers. They respond to bad news with interest rather than blame. They admit their own uncertainty. They thank people for raising problems. Harvard Business Review has published practical guidance on building psychological safety in high-performing teams, and much of it applies directly to the early weeks of an AI rollout.

There is a balance to strike. Psychological safety does not mean low standards. A team can be both safe to speak up in and demanding about quality. In fact, that combination is what makes it possible to adopt new tools without letting accuracy slip.

Guardrails without fear

Clear rules make adoption easier, not harder. People are more willing to try a tool when they know what is allowed.

Know the organisation's policy

Before launching anything, a manager should know the organisation's policy on AI use: which tools are approved, what data can be used with them and what must be disclosed. If there is no policy, that is a conversation to have with IT, risk or legal before the team starts.

Translate the policy into team terms

Policies are usually written for the whole organisation. A manager's job is to translate them into the team's work. "Do not enter personal information into unapproved tools" becomes "do not paste customer names, account numbers or case notes into the tool; use the anonymised template instead".

Use public guidance

In Australia, the Office of the Australian Information Commissioner publishes guidance on privacy and the use of commercially available AI products. The National AI Centre publishes guidance for AI adoption, including material on bringing people along and managing unapproved use. Both are useful reference points for managers who want to understand the issues without becoming specialists.

Keep a human check in the workflow

For most tasks, the safest pattern is that a tool produces a draft and a person checks it before it goes anywhere that matters. The check should be specific. "Review the output" is too vague. "Confirm every figure against the source spreadsheet and every quote against the original document" is clear enough to follow.

Make reporting easy

When something goes wrong, people should know exactly who to tell and how. A short line in the team's working notes is enough. The aim is to catch problems early, while they are small.

A simple change model for managers

There are many change models, and most people leaders do not need to master any of them. One that many managers find useful is Prosci's ADKAR model, which describes five building blocks of individual change: Awareness, Desire, Knowledge, Ability and Reinforcement. It is a helpful lens for diagnosing where a team is stuck.

Awareness

Does the team understand why the change is happening? If people think AI is being introduced only to cut costs, or for no clear reason, they will be wary. A manager can explain the specific problem the change is meant to solve, in the team's own terms.

Desire

Do people want to take part? Desire is shaped by what people expect to gain or lose. A manager can connect the change to things the team already cares about, such as less repetitive work, faster turnaround or more time for the parts of the job people enjoy.

Knowledge

Do people know how to use the tools on their own work? This is where training sits. Good training is hands on, uses the team's real tasks and covers guardrails as well as features.

Ability

Can people actually do it under normal working conditions? Knowing how to do something in a workshop is different from doing it under deadline pressure. This is where protected practice time, champions and worked examples matter most.

Reinforcement

Is the new way of working being sustained? Reinforcement comes from reviews that accept the new output, managers who notice and acknowledge good practice and regular check-ins that catch drift early.

When a rollout stalls, it is usually possible to see which of these blocks is missing. A team with plenty of knowledge but no reinforcement will slide back. A team with desire but no ability will get frustrated. Naming the gap helps a manager choose the right response.

Measuring use without surveillance

Leaders want to know whether a change is working. The temptation is to count logins or prompts. Those numbers are easy to collect and say very little about whether work has changed. They can also make people feel watched, which undermines the psychological safety the change depends on.

Measure tasks, not clicks

A better question is: which tasks are now done differently, and what difference has it made? A manager can track this with a short list. For each task the team has chosen, note whether the new way is now standard, sometimes used or not used, and what the team has observed about time, quality and effort.

Ask the team

The simplest measurement is a conversation. Every few weeks, ask the team which tasks have changed, which have not and why. Record the answers. Over a few months, this gives a clear picture of progress and the obstacles that remain.

Look at the output

Where it makes sense, compare outputs before and after. Is the weekly report clearer? Are client responses going out faster? Are fewer errors reaching review? These observations are more meaningful than usage counts.

Share results openly

When something works, share it with the team and with other managers. When something does not, share that too. Openness about results builds trust in the process and helps other teams avoid the same mistakes.

Be careful with individual tracking

Tracking individual usage can feel like surveillance and may raise privacy and workplace relations questions. If an organisation does collect individual data, people should know what is collected and why. For most people leaders, team level observations are enough to steer the change.

The first 90 days

A rough timeline helps managers plan. Every team is different, but the shape is often similar.

Weeks one and two: choose and agree

Choose one or two tasks. Agree the new way of doing them, the checks and the guardrails. Make sure the reviewer is on board. Identify who on the team will act as a champion, if anyone. Protect some time for practice.

Weeks three to six: practise and adjust

The team tries the new approach on real work. Hold a short weekly practice session. Collect worked examples. Expect friction and adjust as you go. This is the period where the week-two stall is most likely, so pay close attention to whether the review is accepting the new output and whether people have the time they need.

Weeks seven to ten: standardise

Once a task is working well, write it down as the standard way of doing it. Update templates, checklists and onboarding material. Share the worked example with other teams.

Weeks eleven to thirteen: review and extend

Look back with the team. What has changed? What has not? What should be tried next? Choose the next task and repeat. By now, the team should have a rhythm it can sustain without much outside help.

Common mistakes people leaders make

A few patterns come up again and again. Most are easy to avoid once they are named.

Starting too big

Trying to change every task at once overwhelms people and makes it hard to see what is working. Start with one task and expand.

Delegating the change entirely

Handing the whole thing to a champion or the L&D team, and stepping back, sends the message that the change is optional. Champions help. They cannot replace the manager's influence over how work is reviewed.

Treating training as the finish line

A training session is a start. Without practice time, changed reviews and regular check-ins, most of what was learned will fade.

Ignoring the sceptics

Sceptics often have good reasons. Dismissing them loses useful information and hardens resistance. Inviting them to test the change properly is usually more productive.

Over-promising

Telling a team that a tool will save hours every day sets them up for disappointment. It is better to say that the team will test it on specific tasks and keep what works.

Measuring the wrong things

Counting logins or prompts can create the illusion of progress. Focus on tasks that have changed and the difference it has made.

What senior leaders can do to help managers

People leaders can only change the week if the organisation above them allows it. Senior leaders shape that in a few practical ways.

They can set realistic expectations. Announcing that AI will transform productivity by next quarter puts managers in a bind, because the first weeks of any change are slower. A message that says the organisation expects teams to test, learn and keep what works gives managers room to do the job properly.

They can make time legitimate. If managers are measured only on short-term output, protecting practice time will always lose. Senior leaders can make it clear that time spent changing how work is done is part of the job, not a distraction from it.

They can model the behaviour. Executives who use the tools in their own work, and talk openly about what helped and what did not, make it easier for everyone below them to do the same.

They can fix the obstacles managers cannot. Slow tool approvals, unclear policies and reporting templates that demand the old format are often outside a manager's control. Senior leaders can clear them.

And they can ask good questions. Instead of asking how many people are using a tool, they can ask which tasks have changed and what difference it has made. The question shapes the answer managers bring back.

How L&D and HR can support people leaders

People leaders carry much of the weight of AI change, but they should not carry it alone. L&D, HR and transformation teams can help in several ways.

Equip managers before their teams

Managers need to understand the tools, the guardrails and the change approach before they are asked to lead it. A short session for managers, ahead of team training, gives them the confidence to answer questions and model the behaviour.

Provide templates

A one-page task brief, a champion charter template, a simple measurement sheet and a few manager scripts save every manager from reinventing them. Consistency also makes it easier to compare progress across teams.

Connect managers with each other

Managers learn a lot from each other. A regular forum where people leaders share what is working, and where they are stuck, spreads good practice faster than any central communication.

Align policy, tools and training

Nothing undermines a change faster than training on a tool people are not allowed to use, or a policy that contradicts what was taught. L&D, IT and risk need to stay aligned.

Keep the long view

AI tools will keep changing. The organisations that do well are likely to be the ones that build a lasting capability to adopt new ways of working, not the ones that run a single successful rollout. That capability lives in people leaders, champions and teams that are used to trying, reviewing and improving.

AI change in hybrid and distributed teams

Many Australian teams now work across offices, homes and time zones. That changes how AI adoption spreads. In an office, people pick up new habits by looking over a colleague's shoulder. In a distributed team, that informal learning has to be designed.

A few practices help. Run practice sessions online with screens shared, so people can see exactly how a colleague used a tool on a real task. Keep worked examples in one shared place that everyone can find, rather than scattered across chats. Record short walkthroughs of a task being done the new way, so people in other time zones can catch up. And make sure quieter team members, who may not speak up on a video call, have another way to share what they have tried, such as a short written note before each session.

Managers of distributed teams also need to be more deliberate about asking how work was produced. Without the casual conversations of an office, the question has to be built into regular one-on-ones and team meetings.

Questions to ask before choosing outside support

Some organisations run AI change entirely in-house. Others bring in outside help for manager training, champion programs or team workshops. If outside support is on the table, a few questions help separate useful partners from generic ones.

Will the sessions use the team's real tasks, or generic examples? Does the provider work with managers as well as staff? What happens in the weeks after the first session? How does the provider handle data, privacy and approved tools? Who will actually deliver the work, and what do they need from the team beforehand? Can the provider show how a previous program changed a specific task, using only public or permitted examples?

A partner who answers these clearly, and adapts the plan to the team's situation, is more likely to leave a lasting change than one with the most polished presentation.

Where Collective Campus fits

Collective Campus builds capability for teams. Our innovation and capability work goes back to 2015 and our AI work began in 2022. AI is one part of what we do, alongside design thinking, customer experience, lean startup, productivity, agile, psychological safety and critical thinking.

For AI change led by people leaders, three of our public program pages are most relevant. Our AI training workshops are hands on and built around a team's real tasks, with guardrails for data and accuracy. Our AI Champions Program trains internal champions with a one-page charter and a monthly community to keep peer support going. Our 90-Day AI Adoption Sprint follows a team through the weeks after training. Because psychological safety matters so much in this kind of change, our psychological safety workshop is often a useful companion.

We have also written about the week-two problem in more detail on our training blog, in your AI rollout stalls in week two.

There are many other good options in Australia, including universities, professional institutes and AI specialist firms. The S Curve's guide to AI training providers in Australia sets out how they differ.

Frequently asked questions

Who should lead AI change in a team?

The team's manager is usually best placed, because they set priorities and review the work. Champions, L&D and technology teams play important supporting roles, but the manager's influence over how work is done is hard to replace.

Why do AI rollouts stall after a strong start?

Common causes include reviews that still expect the old output, people doing work twice, nobody owning peer support, unclear rules and training that demonstrated tools without changing real tasks.

What does an AI champion do?

An AI champion helps colleagues apply new tools to their own work, maintains worked examples and brings questions and problems back to a wider network. A good champion has a named role, protected time and a clear boundary around what they hand back to IT, risk or policy owners.

How many champions does a team need?

There is no fixed rule. Many organisations start with one champion for each team or group of teams, chosen for trust and credibility rather than enthusiasm alone. What matters more than the number is that each champion has time and manager support.

How should managers talk about job security?

Honestly and within the limits of what the organisation has decided. Managers should not make promises they cannot keep. They can explain what is changing now, why and how the team will be kept informed.

How do you measure AI adoption in a team?

Focus on which tasks are now done differently and the difference it has made to time, quality and effort. Team conversations and before and after comparisons of output are usually more useful than counting logins.

Is psychological safety relevant to AI change?

Yes. People need to admit what they do not know, share imperfect drafts and report problems. That is much easier in a team where it is safe to speak up.

How long does it take for a new way of working to stick?

It varies. Many teams find that a single task can become standard within a couple of months if the review accepts it and people have time to practise. Building a broader habit of adopting new tools takes longer and benefits from a regular rhythm of review.

Does this apply to public sector and regulated teams?

Yes, with extra attention to policy, privacy and approval of tools. Public guidance from the OAIC and the National AI Centre is a useful starting point, alongside the organisation's own policies.

A closing word

AI change is often described as a technology project. For most teams it is closer to a management one. The tools matter, but what decides whether they stick is whether the person who sets the week makes room for a new way of working, reviews it fairly and keeps coming back to it. That is ordinary management, done with care. It is also where the value is.

Disclosure: The S Curve is published by Collective Campus, which is mentioned in this guide. Details of Collective Campus programs come from our public pages as at November 2026. Other facts are linked below.

Sources:

• McKinsey, The state of AI in 2025
• Microsoft, define your AI champion role and charter
• Prosci, the ADKAR model
• Google re
  , understanding team effectiveness
• Harvard Business Review, high-performing teams need psychological safety
• OAIC, guidance on privacy and the use of commercially available AI products
• National AI Centre, guidance for AI adoption
• Collective Campus, AI Champions Program
• Collective Campus, your AI rollout stalls in week two