Your managers will make or break AI adoption.

Most AI plans are announced at the top and carried out somewhere in the middle. The director sends the memo, the licenses arrive, and then a team lead with nine direct reports and a full calendar has to work out what any of it means for Tuesday morning. Whether the plan turns into new habits depends mostly on what that person does next.
Strategy reaches the team through one person.
People rarely change how they work because of an all-staff email. They change when the person who assigns their work, reviews it and approves their time off asks them to try something and then follows up a week later. In a school district that person is the department chair more often than the superintendent. In a clinic it is the practice manager, and on a factory floor it is the shift supervisor.
That is why AI plans so often stall at the manager level. When a manager treats the new tool as optional, the team does too. When a manager privately distrusts it, people notice within days and stop experimenting where anyone can see. We run into this often enough in our work with teams that we now ask about the managers before we ask about the software.
The middle is where people are most stretched.
Managers are being asked to lead a change they haven't learned yet. They carry the same unease about AI as their staff, plus a few worries of their own: what it means for the size of their team, whether their judgment still counts, and how it will look if a direct report gets better at it than they are. Most of them already have more work than hours.
So when AI shows up as one more initiative to roll out, it reads as a second job. It goes down more easily as part of the job they already have. Managers have always coached people and decided what good work looks like. Sitting with someone to find a faster way to draft the weekly report is that same coaching, pointed at a new tool, and it is worth saying so out loud when you hand the work over.

Give them room to be beginners in front of their teams, too. A manager who shows what they tried and where they got stuck teaches more than one who waits until they feel expert, and the wait can last a long time when the tools change every few months.
Hand them the standards along with the tools.
A common setup has one person or a small group choose the tools, write the prompts and pass everything down. Managers receive it the way they receive a new expense system, as something to comply with. They had no say in what counts as good output, so they have little reason to stand up for it when someone on the team pushes back.
Turn that around. The finance manager should decide what an acceptable AI-drafted variance note looks like and which figures a person must always check by hand. The intake lead at a nonprofit should decide what the assistant may summarize from a client's form and what it must leave alone. A central owner can still keep the list of tools and the rules about data. Judgment about quality stays with the people who know the work, and the rest of the organization gets faster answers because of it.
A manager who wrote the standard for good output will defend it in front of the team.
Ask each manager for two processes.
Open-ended requests produce long lists. Ask a room of managers where AI could help and you will get thirty ideas and no starting point. A smaller assignment works better: each manager names two processes that are slow, error-prone or dreaded, and records a few minutes of screen video showing how each one runs today.
If the manager is too far from the work to record it, they sit with the person who does it. That conversation is useful in itself. The recording also gives you a rough baseline, how many steps, how many hands and how many hours a week, so that six months later there is something to compare against besides a feeling.
Keep the work visible and expect to repeat it.
Ask every team to post what it is trying in one shared place, a channel or a running document, including the attempts that went nowhere. Managers can see across teams without calling a status meeting, and they can spot when someone is building something heavier than the problem needs. Other teams pick up ideas just by reading along.
Then plan on repetition. One demo almost never changes a habit. Say two people on a team of eight start drafting proposals a new way. Point to their results in front of the team, then ask the other six, one at a time, what is getting in the way. The answers are usually plain: no login, unsure what is allowed with client data, no time to practice. A manager can fix every one of those.
A quarterly brief for each manager
Hand this to every manager at the start of a quarter, and review it with them at the end.
- Two processes, named and recorded as they run today, with a rough count of the hours they take each week.
- A written quality standard for each: what good output looks like, what a person must always check, and what the tool must not touch.
- One shared place where the team posts what it tried, including what didn't work.
- Ten minutes in the regular team meeting for a short demo by someone on the team, rotating each time.
- One question added to every one-on-one: what did you try with AI this month, and what got in the way?
- A short monthly note to their own director covering what changed, what is stuck and what they need.
- An hour a week of protected time for their own practice, with a named task moved off their plate to pay for it.


