Your AI Enablement Is a Calendar Problem (Not a License Problem)
Everyone had Copilot. Almost nobody had a reason to open it on a Tuesday afternoon. The gap wasn't enthusiasm — it was structure.
Month two of our AI rollout, I walked into the weekly staff meeting and asked a simple question: who used an agent on real work this week?
Three hands. Same three as last month. The licenses were paid for. The Slack channel existed. Someone had even pinned a "getting started" doc that nobody opened after the first week. The rest of the room wasn't hostile — they were busy, a little embarrassed, and waiting for someone to tell them when AI was supposed to fit into the sprint they'd already committed to.
I spent a while in that pattern myself, early on. I thought my job as the enabler was to cheer louder, share better prompts, and post when a new model dropped. That works on the enthusiasts. It does nothing for the engineer sitting at a 2 who will nod in the meeting and go back to the workflow that already ships their tickets.
That's when it clicked for me: enablement isn't evangelism. It's organizational design with a weekly cadence.
Why the Middle of the Team Stays Stuck
Most programs fail in the same place. The level 5s were going to figure it out regardless — they treat every release note like a hobby. The level 1s who never installed the software stay invisible until you rank the team and realize two people haven't opened Cursor once. Everyone in between — the 2s and 3s who aren't resistant, just under-equipped — gets the worst of both worlds.
Generic training videos don't help them because the examples aren't their codebase. "Figure it out yourself" doesn't help because they don't know what good looks like yet. And a standing invitation to "ask in Slack" quietly selects for people comfortable admitting ignorance in public, which is not most engineers.
The failure mode isn't missing tools. It's missing scheduled, peer-level practice on real work — the kind where you can stumble without performing for a manager.
The Three-Layer System
We stopped treating enablement as a broadcast and built three mechanisms that run every week whether or not anyone feels inspired.
1. Tiered mentorship pairs
Each level 5 is assigned one or two level 1–3 engineers for the week. Not a class. A working session on whatever they're actually stuck on — a story, a bug, a refactor they've been avoiding. The level 5's job is to make the work visible: how they set context, when they switch modes, what they reject from the model without guilt.
Pairing matters because honesty shows up differently peer-to-peer. A junior engineer will tell another engineer "I don't understand why that prompt worked" in a way they won't in a town hall. And the level 5 learns too — teaching forces you to articulate defaults you've been running on autopilot.
2. End-of-week applied session
Friday afternoon, whole team. We pick a real bug or a small feature story — something with a beginning and an end in ninety minutes. A level 5 drives. A level 1–3 sits beside them and co-pilots. Everyone else watches.
The session itself is useful. The debrief is better. We talk about where the agent went wrong, what context was missing, what a reviewer would have caught. Synthetic demos never produce that conversation because nobody cares when the stakes are fake.
Last month we walked through a production bug that had been sitting in the backlog for two weeks. The fix took forty minutes with an agent in the room. The debrief took twenty — mostly about why we'd been afraid to touch the file and what guardrail would have made that fear smaller.
3. AI working group (separate track)
Level 4–5 engineers who actually want to track every model release meet on their own cadence. They read the changelogs, try the tools, argue about what's signal and what's noise. Then they filter — one short write-up for the core team, not a firehose of "you should try this" messages in the main channel.
Separating "learning to use AI on our work" from "keeping up with AI news" was underrated. Most engineers don't want both jobs. They want someone they trust to tell them when the defaults changed enough to care.
What Good Looks Like
You know the system is working when the applied session stops feeling like a special event. When a level 3 volunteer asks to drive the next one. When the working group write-up gets referenced in a retro without anyone prompting it. When the Slack channel goes quiet because practice moved onto the calendar.
You also know when it isn't working — and we've hit this — when mentorship pairs skip a week because "everyone was busy." Busy is the excuse that kills enablement. The calendar block is the whole point. If AI only happens when there's slack, only enthusiasts will ever have slack.
The reframe:
Your AI enablement program is a calendar problem, not a license problem. Tools are table stakes. Recurring peer practice on real work is the program.
What to Do Next
Pick one week. Assign pairs. Schedule the applied session before you announce anything company-wide. Pick a real ticket — something small enough to finish, messy enough to teach from. Let the debrief run long.
If you're the enabler, your first job isn't to convert skeptics. It's to make practice normal for the people who were never going to self-start.
The enthusiasts don't need you. The middle does.
More on building adoption systems that scale in the blog archive.