The directive usually arrives from the CEO or the VP, sometimes from HR with leadership copied in. The wording is confident: every employee will be using AI by some date, adoption metrics will be tracked, training will be provided, this is a transformation.
The training that arrived was a 45-minute LinkedIn Learning module about prompting, which the company is calling AI training for employees. The metrics being tracked are weekly logins to a tool nobody on your team knows what to do with. The people who actually have to figure out what AI means for the work are sitting across from you in your next 1-on-1, waiting to see what you’re going to do about it.
This is what being caught in the middle of an AI mandate looks like. Leadership owns the strategy, your team owns the execution, and you’re holding a sloppy directive on one side and a team of skeptics, early adopters, and people just trying to keep their heads down on the other.
I was quoted in Fast Company’s piece on the middle manager’s AI survival guide back in April, and most of what I shared there was about how I navigated this position from the other side, in a company with no mandate at all. The advice that comes from operating without a mandate looks different from the advice that applies when one lands on your desk, which is what this article is about. Whether you’re enthusiastic about AI or skeptical of it, the job in front of you is the same: figure out how to deliver on a mandate you didn’t design without burning out yourself or burning down your team.
Key Takeaways
- Most resistance to corporate AI mandates isn’t ideological — it’s practical. Your team wants clear answers to three questions: which tools, for what work, with what limits. Answer those and most of the resistance becomes movement.
- Use a 30-60-90 day framework. Days 1-30 build comfort on real work with one or two approved tools. Days 31-60 move from tools to workflows so AI becomes the default step, not a thing people remember to try. Days 61-90 develop internal champions per team pod.
- Your team will split into three groups — early adopters, cautious middle, genuinely resistant. Match your approach to each. Don’t treat them all the same and don’t force uniformity across roles that should move at different speeds.
- When reporting upward, skip activity metrics (attendance, logins, prompt counts). Report which specific workflows now use AI, what observable change happened, where humans still review, and what you need from leadership to keep moving.
- Push back on bad mandates by sounding operational, not ideological. “I can deliver this, and here’s what needs to be in place” lands better than “I don’t think we should do this.” If direct pushback won’t work in your culture, let modest, honest reporting tell the story over time.
Table of Contents
Why Your Team Needs This, Even If Some of Them Aren’t Ready
The mandate from leadership may be poorly designed, but the underlying premise isn’t wrong. AI is becoming part of how work happens, and that pattern doesn’t reverse if your company’s rollout is a mess. Your team will eventually have to work with these tools in some form, whether the specific memo lands well or not.
Forcing AI on people who aren’t ready creates more problems than it solves, but leaving your skeptics alone to figure it out in a year is worse. The longer they go without practical engagement, the wider the gap gets between them and the people who started experimenting earlier. Eventually that gap becomes a career problem, and you’ll be the one having that conversation in a performance review.
Most of the resistance you’re seeing isn’t ideological. According to an Eagle Hill workforce survey, the top blockers employees cite are practical: knowing what tools are available (35%), having ideas for using AI in their roles (32%), and understanding what’s safe to input (27%). Nobody is saying “I refuse to use AI on principle.” They’re saying they don’t know what to use, how to apply it, or what they’re allowed to put into it.
That gives you a real opening as a manager. Your team isn’t asking you to be an AI evangelist. They’re asking for clear answers to three questions: which tools, for what work, with what limits. Answer those well and most of the resistance becomes movement. The handful who genuinely refuse to engage are a separate problem, and we’ll get to them later.
Your own fluency matters here too. You don’t need to be the deepest user of AI on your team, but you need enough familiarity to evaluate team use. Getting comfortable enough yourself is what lets you spot good work from bad and call out shortcuts that hurt the work product.
What AI Training Actually Looks Like (vs. What Corporate Calls Training)
Most corporate AI training is built for compliance, not capability. HR needs to report that the company “rolled out AI training,” a generic e-learning module is the cheapest way to make that claim, and completion percentages get tracked while almost none of it changes how anyone actually works. You’ve probably already received the company version: a 45-minute video about what AI is, a few generic prompts that have nothing to do with your team’s work, a quiz, a certificate. That kind of training is fine as background, but your team becomes competent the same way they become competent at anything else: by using the tools on real work, getting feedback, adjusting, and using them again.
The version that actually works is closer to coaching than instruction. Pick one workflow your team already does every week. Run a session where everyone uses an approved AI tool on that workflow with real inputs from their actual job. Compare outputs. Talk about what worked, what didn’t, what they had to fix. Do it again the next week with the same workflow until people stop needing to ask basic questions, then move to a different workflow.
Two advantages of this approach are worth being explicit about. People retain skills they practice, not skills they watch demonstrations of. And people learn faster when they can see their peers struggling with the same things, instead of feeling like they’re the only one who doesn’t get it.
A useful starting set of workflows looks like this: first drafts of internal documents like status updates and project briefs, summarization of long Slack threads or email chains, turning rough meeting notes into action items, drafting feedback for a 1-on-1 from your own observations. Each is high-frequency, low-stakes, and uses material your team already produces. The skill you’re building is knowing when AI is the right tool and when to set it aside, which is the actual workplace question.
What you want to avoid is the opposite extreme, where AI training becomes its own project that competes with actual work. If your sessions are running long or generating action items nobody has time to do, the training is failing on its own terms. The point is to integrate the tools into work people are already doing, not create a parallel track with its own budget and headcount.
A 30-60-90 Day Framework for Actually Rolling This Out
A 30-60-90 day approach works for AI rollout because it forces you to stop trying to solve adoption, governance, and proof of value all at once. You sequence them. The first month is about building basic comfort. The second is about integrating AI into real workflows. The third is about creating internal depth.
This kind of tiered approach is consistent with what learning platforms like Go1 recommend for AI training: foundational training for everyone, applied workflow training for knowledge workers, and deeper expertise for power users. Most teams need all three layers eventually, but not in the first 30 days and not from everyone at the same pace.
Days 1 to 30: Build Comfort on Real Work
The early planning decisions shape everything that follows. Pick one or two approved tools and one category of work your team already does every week. For most teams that means a general AI assistant like ChatGPT or Claude for writing tasks, plus either a meeting tool like Otter or Microsoft Copilot if you’re already in the Microsoft 365 environment. Don’t try to introduce five tools at once. The goal in month one is repetition in a safe lane.
Run weekly working sessions with your team’s actual work. Bring last week’s status updates, a real meeting transcript, a Slack thread that needs a decision summarized. Have everyone use the tool on the same input and compare outputs together. By the end of 30 days, your team should be able to complete a few recurring tasks with AI assistance and explain how they reviewed the output. If they can’t do that, slow down before adding more tools.
Days 31 to 60: Move From Tools to Workflows
The second month is where AI stops being a thing people open when they remember and starts being part of how the work happens. The shift you’re driving is from “I should try AI on this” to “this is how I do this task now.”
That shift requires you to name the patterns. Three cover most knowledge work: draft then review for written output, summarize then assign for meetings and async coordination, and break down then sequence for projects. Once people see their work in terms of those patterns, the question of “when should I use AI” mostly answers itself. By day 60, you want most of your team using AI as a default step in at least two recurring workflows.
Days 61 to 90: Build Internal Depth
By month three your team will have split into roughly three groups. A few people will be ahead, using AI in ways you didn’t teach them. Most will be in the middle, comfortable with basics and ready for slightly more complex patterns. A small group will still be behind, either needing more support or quietly avoiding the whole thing.
The job in this phase is to use the people who are ahead to support the people in the middle, while you focus your attention on the people still behind. Name peer mentors. Collect the prompts and approaches that are working and document them so they can be reused. Create informal office hours where cautious users can ask questions they don’t want to ask in a group. Start expanding to more complex use cases for the people who are ready: multi-step prompting, light automation, AI-assisted analysis. Not everyone needs to be at this level. A few people becoming genuinely skilled is more valuable than everyone being shallow.
Managing Different Skill Levels on the Same Team
By the time you’re 60 days into a rollout, the spread on your team will be wider than you expected. One person is using Claude to draft three versions of every important email and picking the best one. Another is still asking whether it’s okay to put a meeting transcript into ChatGPT. A third hasn’t logged into the tool at all and is hoping nobody notices. Managing all three the same way is how rollouts fail.
The temptation is to treat the gap as a training problem. Some of that helps. But a lot of the variation isn’t about training, it’s about comfort and what the person believes will happen if they get caught using AI wrong. A Cornerstone report on hidden AI use found that one of the main reasons employees don’t disclose their AI use to their managers is fear of using it wrong. Silence on your team isn’t always refusal. Sometimes it’s self-protection.
Before assuming someone is resisting, consider whether they might be using AI more than you realize and just not telling you, or whether they tried it once, got a result they didn’t trust, and pulled back. Asking directly is better than assuming, and asking in a 1-on-1 is better than asking in a group setting where they have an audience to perform for.
The Early Adopters
Use them as peer mentors, but be careful what you ask them to teach. Some early adopters are genuinely good at the work and good at AI. Others are good at AI and overestimate the quality of their output. Pair them with the cautious users on low-stakes tasks first to see which kind they are. Praise specific contributions, but don’t turn them into the team’s AI mascot. That creates resentment in everyone else and pressure on the early adopters to perform.
The Cautious Middle
This is most of your team. These people aren’t refusing, they’re just being deliberate. They need clear examples tied to their actual work, time to practice without an audience, and explicit permission to make mistakes. The biggest thing you can do for this group is reduce the social cost of trying something and having it not work. If your team culture treats AI errors as evidence the person doesn’t know what they’re doing, the cautious middle will never push past the basics.
The Genuinely Resistant
This group is usually smaller than it looks, because some of the apparent resistance is actually the self-protective silence we just talked about. The truly resistant are the ones who, given clear tools, clear permission, and time to learn, still refuse to engage. Separate two questions with them. Is the resistance about a specific concern that can be addressed, or is it general refusal that’s going to become a performance issue? The first deserves a real conversation. The second deserves the same response you’d give to a refusal to learn any other expected skill.
One thing to actively avoid is forcing uniformity. Some roles should move faster than others. The person who writes a lot of client-facing communication has more to gain from AI drafting than the person doing tightly regulated work where every output needs human review anyway. Unevenness is fine. Pretending everyone should be at the same point on the same date is what creates resentment and bad reporting up the chain.
Reporting Progress Upward Without Overpromising
Leadership is going to ask for evidence early. The pressure to produce something that looks like progress can push you into reporting the wrong things, and the wrong things will come back to haunt you when leadership eventually asks why the rollout didn’t translate into the gains they were promised.
The first bad metric is attendance. People showed up to training, which tells you nothing about behavior change. The second is account creation. People have logins, which tells you they have logins. The third is prompt volume, which can mean people are getting real work done or that they’re flailing around trying to get the tool to give them something useful. These are activity metrics dressed up as progress metrics. The credible alternative is to report business effects tied to specific workflows, consistent with what platforms like iTacit recommend for AI training programs: connect learning to outcomes like time saved and error reduction, not completion data.
What to Stop Reporting
Be suspicious of your own updates. “Everyone completed the module” tells leadership the LMS sent emails. “The team used AI this week” answers no useful question. “Prompt counts are up 200%” could mean better work or more confusion. If your update would be true whether or not your team was actually getting better at anything, it’s not a useful update.
What Leadership Can Actually Use
A useful update is short, concrete, and slightly unspectacular. The unspectacular part is what makes it believable. Leadership has been pitched enough AI transformation slides to know when something is being inflated. The manager who reports modest, real progress in two workflows and admits a third isn’t working sounds more credible than the manager claiming broad adoption everywhere.
Cover four things: which workflow is now using AI (be specific — “weekly status updates are AI-drafted and human-reviewed before sending” is a real claim, “we’re using AI across the team” is not), the observable change (faster turnaround, fewer revision cycles, cleaner handoffs), the quality controls (where humans are still reviewing carefully, where outputs have been unreliable), and what you need from leadership (tools to approve, policy clarification, more time before expanding scope). Leadership often doesn’t realize they’re the blocker, and a short request from you is more useful than a complaint later.
The Posture That Holds Up Over Time
You report progress where there is progress, and the absence of progress where there isn’t. Honest reporting puts you in a position to push back when push back is warranted. The manager who has been quietly inflating adoption numbers for two quarters has no credibility when they need to say “the next phase isn’t ready yet.” The manager who has been reporting modest, real progress has credibility to spend when it matters.
When to Push Back (and How)
Some mandates deserve refinement before execution. If leadership wants broad AI adoption but hasn’t approved tools, clarified what data can go into them, or given the team time to practice, the rollout isn’t underpowered because the team lacks enthusiasm. It’s underpowered because the design is incomplete. No amount of training fixes that. Pushing back is the right answer, and doing it well is part of the job.
The instinct most managers have when a poorly designed mandate lands is to absorb it and try to make it work. That instinct is wrong more often than it’s right. Absorbing a bad design protects leadership from the consequences of their own decision and transfers the cost to your team. You become the buffer in the worst possible sense, eating the friction and reporting smooth sailing while your team grinds. Eventually something breaks, and when it does, the breakage gets attributed to you, not to the original design.
Signs the Mandate Needs Pushback
The mandate needs work when any of these are true. There’s no approved tool, just an instruction to “use AI.” There’s no guidance on what data is safe to put into the tools. There’s no review model, which implies AI output is meant to ship without human checks. The timeline assumes broad adoption before foundational practice has happened. The underlying process being “AI-enabled” was already broken, and AI is being used as a way to avoid fixing it. If two or more of these are true, the right move is to surface the gaps before you commit to a rollout date, not to start anyway and hope they fix themselves.
How to Frame the Pushback
Pushback lands when it sounds operational, not ideological. The version that fails is the manager who says “I don’t think we should be doing this.” That reads as resistance to the strategy and puts leadership in defend mode. The version that works is the manager who says “I can deliver this, and here’s what needs to be in place for it to work.” That reframes you as someone solving a problem leadership didn’t see.
Two framings that tend to work:
“We can move this forward, but the current timeline assumes approved tools and data input rules that the team doesn’t have yet. I’d like to get those resolved before we commit to a public adoption target.”
“The fastest path to credible adoption is a phased rollout in two recurring workflows. Expanding before those are stable is going to create noisy reporting that doesn’t reflect real progress.”
Each of these acknowledges the mandate, takes responsibility for delivering it, and identifies a specific blocker leadership needs to address. That’s the shape of useful pushback. It’s not resistance. It’s management.
The Quiet Version of Pushback
The other form of pushback is quieter and works better in cultures where direct disagreement gets coded as insubordination. The quiet version is the one I usually default to. You don’t object to the mandate. You execute on the parts that make sense, hold the parts that don’t, and let your reporting tell the story. Modest, honest updates with specific limitations noted will eventually communicate what you couldn’t say directly. If you’ve spent the last quarter telling leadership exactly what’s working and what isn’t, you don’t need to make a formal pushback at all. The information is already in front of them. You just have to be patient while it sinks in.
The Manager in the Middle
The reason the middle manager position is so hard during an AI rollout is that nobody else in the organization is being asked to do what you’re being asked to do. Leadership sets direction, the team executes, and you translate one into the other while protecting both sides from each other’s worst instincts. The version of this job that works isn’t the one where you become your company’s AI evangelist. That version burns you out and damages your credibility with the team. The version that works is the one where you stay honest with leadership, stay practical with your team, and treat the rollout as an operational problem to solve rather than a transformation to believe in.
You won’t get this perfectly right, and that’s the job. Most AI rollouts that fail don’t fail because the technology wasn’t good enough. They fail because someone in the middle of the org chart tried to please everyone, lost the ability to push back, and got steamrolled by a mandate that was never going to work. Don’t be that manager. The buffer role you’re being asked to play is genuinely valuable, but only if you play it honestly.
Frequently Asked Questions
How long should AI training for employees take to show real results?
Plan for a full quarter before you have meaningful evidence of behavior change. The first 30 days are mostly about building basic comfort with the tools on real work, the second 30 are about integrating AI into recurring workflows, and the third are about creating internal depth on your team so the rollout isn’t dependent entirely on you. Anyone promising you measurable productivity gains in the first month is selling you something. Real adoption shows up around day 60 to 90, and it shows up as small, specific improvements in workflows the team already does, not as dramatic transformation.
What should I do if my team is openly resistant to using AI?
Separate the kinds of resistance first. Some of it is fear of using AI wrong, which goes away once you give clear examples and explicit permission to make mistakes in low-stakes contexts. Some of it is legitimate concern about data security, accuracy, or ethics, which deserves an actual response rather than dismissal. A smaller portion is general refusal to engage with an expected skill, which becomes a performance conversation if it persists past the practice and support phase. Most of what looks like resistance is actually one of the first two, not the third, and treating all three the same way makes the situation worse.
Do I need to be an AI expert to train my team on AI?
No, and trying to be one will hurt you. You need enough fluency to evaluate the work your team produces with AI assistance, spot good output from bad, and recognize when someone is using AI to skip thinking rather than to support it. That’s a different bar than being the deepest user of these tools on your team. Your job is to set the conditions for the team to develop skill, not to be the person with the most skill yourself. The early adopters on your team will pass you quickly on technical proficiency, and that’s fine.
How do I report AI training progress to leadership without overpromising?
Report business effects tied to specific workflows, not activity metrics. “Weekly status updates are now AI-drafted and human-reviewed before sending, and the team reports about 20 minutes saved per person per week” is a useful update. “The team has 100% completion on AI training modules” is not. Be specific about which workflows have stuck, which ones haven’t, where you’re still cautious about output quality, and what you need from leadership to keep moving. Modest, honest updates build the credibility you need when you eventually have to push back on something. Inflated updates burn that credibility before you have a chance to use it.
