Some teams get it instantly. Others feel lost and barely touch it.
That's the exact quote from an r/elearning thread this week about Microsoft Copilot rollouts. 3,000+ upvotes worth of engineering managers nodding along. And it keeps coming up — same thread, same week, different companies:
"My company made all the mistakes rolling out Copilot because people got so caught up in the AI hype."
"I really don't see many companies doing it right."
"The biggest challenge isn't setup — it's adoption."
If this sounds like your team, here's what's actually happening.
The Invisible Barrier
You bought the licenses. IT provisioned access. You sent the announcement email.
Then... nothing changed.
The reason isn't resistance to AI. It isn't that the tool is bad. It's a specific, fixable problem: your team doesn't know what "good" looks like for their job.
Generic training shows people how to use Copilot or Claude Code. It doesn't show them which task to start with — the one where they'd immediately feel the difference.
Without that anchor, most people open it, try something vague, get mediocre results, and go back to doing things the way they know works.
What Changes Usage in a Day
The teams that flip from low adoption to high adoption fast all do the same thing: they pick one specific, high-frequency task and make that the entry point.
For developers: pre-PR review. Before submitting a PR, run it through Claude Code — "flag anything a senior engineer would ask about in code review." Engineers feel the value in 20 minutes.
For knowledge workers: email triage. The r/Office365 community keeps surfacing this one — Outlook turns out to be "the unexpected hero" for Copilot adoption. Not Excel, not Word. Email.
For engineering managers: meeting summaries to action items. One paste into Copilot, structured follow-ups in 30 seconds.
The specific task matters less than having one. You need a concrete answer to "use it for what, exactly?"
The #1 Thing That Actually Moves Adoption
Straight from the teams that have done this:
"The #1 request we heard: 'Can you show me prompts for my job?' As soon as teams saw real-world examples, usage shot up."
Prompts. Role-specific, workflow-specific prompts.
Not "here are 50 prompts you could use." That's a menu nobody reads.
Here are 3 prompts for your job, for the work you do this week. That gets used.
The fastest way to build this: ask your early adopters — the people already using it well — to write down what they asked that worked. Put it in a shared doc. Share it in Slack. That's your library.
The Day-One Fix
If utilization is low on your team right now, here's the 4-hour plan:
Hour 1: Pick the anchor workflow. (Start with whichever feels most painful/time-consuming right now.)
Hours 2–3: Run a focused session — not a demo, not a lecture. Everyone does the task with the tool. You're there to watch where people get stuck.
Hour 4: Collect what worked. What prompts got good results? What tasks made people go "oh, that's actually useful"? Document it.
By end of day: you have a shared prompt library, an anchor workflow, and at least a few engineers who've seen real results. The rest follows from that.
If You Want a Benchmark
Industry average for teams without structured training: 20–35% utilization at 30 days.
Teams that do one focused session with a specific workflow anchor: 55–65% at 30 days.
The tool is the same. The gap is the hour you spent showing people what to do with it.
We built a free ROI calculator if you want to run the math on your team's current utilization: askpatrick.co/roi-calculator.html
And if you want the first 3 modules of our team adoption playbook — free, no email required: askpatrick.co/playbook-sample.html
Ask Patrick runs co-work sessions for engineering teams deploying Claude Code and Microsoft Copilot. Flat-fee, no per-seat nonsense. askpatrick.co
Top comments (0)