ai:and:people
How do I get my employees to actually use AI?
By Loan Laux · May 11, 2026 · 6 min read
Employees use AI when it's the easiest way to do their actual job: when leadership visibly uses it, when it's built into the workflow as the default, and when training happens on live work instead of demos. Mandates, dashboards, and one-off workshops don't move usage. Defaults and permission do.
We help agencies through this shift, and the pattern is consistent enough to write down. Here's what blocks usage, the nine tactics that reliably raise it, and the mistakes that set adoption back by months.
Why your team isn't using it.
Start with the honest diagnosis. In the agencies we work with, low usage almost never comes from lack of interest. It comes from four quieter blockers.
- No explicit permission. Nobody has said, in writing, what's allowed. So careful people abstain and bold people use personal accounts in private.
- Fear of looking replaceable. Getting visibly good at AI can feel like writing the case for your own redundancy. Nobody says this in a meeting.
- Fear of looking incompetent. Senior people especially. They're experts at the old way, beginners at the new one, and being a beginner in front of juniors is uncomfortable.
- Tools outside the flow of work. If using AI means leaving the PM tool, the IDE, or the doc to visit a separate chat window and paste context in, most people won't. Friction beats intention.
The nine tactics that raise usage.
01:
Use it visibly at the top
The single strongest signal is the founder or leads using AI openly: sharing prompts in Slack, showing drafts in reviews, admitting what didn't work. Usage is social before it's technical.
02:
Put permission in writing
One page: which tools are sanctioned and paid for, what data can and can't go in, what disclosure clients get. Ambiguity reads as prohibition to careful employees.
03:
Change the workflow default, not the person
Don't ask people to remember to use AI. Rebuild the workflow so the AI step is how it's done: proposals start from the generator, tickets start from the transcript, QA starts with the sweep.
04:
Train on live client work
Run sessions on this week's actual deliverables, in role-specific groups: a PM track, a design track, a dev track. Generic prompting workshops evaporate within a week.
05:
Pair champions with skeptics
Your enthusiast's job is not to be impressive. It's to sit with the skeptic on a real task until the skeptic wins an hour back. Converted skeptics are the best advocates you'll get.
06:
Measure in deliverables, not logins
Seat activity tells you nothing. Look at where AI shows up in output: proposals shipped from the new process, tickets drafted from transcripts, PRs with assisted tests. That's adoption.
07:
Make failure shareable
A weekly 'what I tried' thread where botched outputs are as welcome as wins. If only successes get shared, everyone quietly concludes it doesn't work for their tasks.
08:
Put it in existing rituals
Five minutes in the weekly all-hands for one workflow demo, by a different person each time. No new meetings. Rituals you already have are free distribution.
09:
Remove every ounce of friction
Paid seats for everyone on the sanctioned tools, SSO, shared prompt libraries or Claude Skills, integrations installed. Every personal-account workaround you prevent is risk removed and signal gained.
What not to do.
- Don't mandate usage quotas. 'Everyone must use AI daily' produces performative usage and resentment, not changed workflows.
- Don't turn dashboards into surveillance. The moment usage metrics feel like monitoring, people optimize for the metric and hide the real behavior.
- Don't outsource it to a trainer with no agency context. Someone who doesn't understand agency delivery will teach party tricks, and your team will notice within ten minutes.
- Don't lead with a ban. Bans don't stop usage; they stop visibility. You inherit the risk without the learning.
Say the quiet part about jobs.
Every adoption push happens against a background question nobody asks out loud: am I training my replacement? You can't out-communicate a fear you refuse to name.
The honest answer for most agencies is that AI changes the shape of roles faster than it removes them: production hours shrink while judgment, client-facing, and review hours grow. Say what you can actually commit to. If the goal is doing more work with the same team rather than the same work with fewer people, put that in writing. And if restructuring is genuinely on the table, don't promise otherwise. People can tell.
One commitment that costs little and buys a lot: nobody gets penalized for time spent learning during the transition, and efficiency gains get reinvested in better work before they get harvested as cuts.
How long it takes.
With defaults changed and training on live work, expect visible movement in the first month and durable habits by the end of a quarter. The curve isn't smooth: usage spikes after each training, sags after each client crunch, and stabilizes wherever the workflow defaults hold.
That's why the defaults matter more than enthusiasm. Enthusiasm decays. A proposal process that starts from a draft doesn't.
If you want the training part handled, our team AI training runs on your live client projects, with follow-up office hours while the habits form.
Frequently asked questions.
Should AI use be mandatory for employees?
Mandating 'use AI' fails because it's vague and unenforceable. Mandating the workflow works: proposals start from the drafting process, tickets come from the transcript pipeline. People can still edit everything; the default just includes the AI step.
Should we pay for everyone or run a pilot first?
Pay for everyone on the core assistant. Rationing the main tool recreates the personal-account problem you're trying to end. Pilots make sense for expensive role-specific tools, like a coding assistant or a video suite, not for the thing you want to become ambient.
What if the most resistant people are senior?
That's the norm, not the exception. Give seniors private ramp time (1-on-1 coaching rather than group sessions), and start on tasks they dislike rather than tasks they take pride in. A senior developer rarely wants AI writing the architecture. They're often happy for it to write the tests.
How do we measure AI adoption without spying on people?
Count outcomes, not activity: proposals shipped through the new flow, meetings with distributed action items, PRs with assisted tests, production hours trending down in timesheet categories. All of it is visible in work artifacts. None of it requires reading anyone's chat history.