The AI Adoption Day Playbook

Operating principle: Events are a mechanism. Behavior change is the goal. Every section below exists to produce measurable adoption outcomes, not a good vibe in the room.

This is the facilitation runbook I wrote for running AI-assisted-development adoption days — using Cursor as the reference tool, though the method is the same for any agentic IDE. The single failure mode it is designed against: a great event that changes nothing on Monday.

1. When to run an Adoption Day

Run this when an account shows one or more:

• Contract signed, but fewer than 30% of licensed engineers active in the last 14 days
• Power-user concentration risk — adoption lives in 2–3 champions, not the org
• Stalled expansion — renewal or up-sell needs proof of value
• New team or platform onboarding after the initial rollout
• Post-reorg or post-migration — a fresh mandate to change habits

Confirm with the deployment manager and CSM that the real blocker is adoption (not tooling, seats, or procurement) before booking the room.

2. Account scoping (T-14 to T-7 days)

Input	Why it matters	Owner
Active-user telemetry (last 30d)	Baseline “before” so outcomes are measurable	CSM
Top 3 engineering workflows to target	Gives the build challenge real business context	Deployment Mgr
Cohort: 5 skeptics + 3 champions	Skeptics convert hardest but carry the most signal	Hiring mgr + me
Theme / build challenge (company-specific)	“Ship X for our domain” beats a generic toy	Me, with sponsor
Env readiness: seats, model access, repo + VPN access	Removes day-of friction	IT / Deployment Mgr
Success criteria, signed off by VP Eng	Forces outcome definition up front	Sponsor + me

Selection rule: a cohort of 6–10 engineers with skin in the game beats 40 passive attendees every time.

3. Agenda frameworks

Format A — Half-day developer day (4 hrs)

Time	Segment	Goal
0:00	The 10-minute live ship	I build something real in Cursor, live, in front of them — earns trust before I ask for anything
0:15	“Your workflows, through Cursor”	Map their repo and workflows to capabilities (not a feature tour)
0:45	Challenge brief + team formation	Hand out the company-specific build challenge; self-select teams
1:00	Cohort build (coached)	I circulate, unblock at the point of friction, demo advanced patterns live
3:00	Demos + judging	Each team ships and demos; rubric-scored (see below)
3:45	Retro + commitments	“What changes Monday?” — each engineer names one workflow they will run in Cursor
4:00	Close + 30/60/90 check-ins booked	Lock the follow-up before they leave the room

Format B — Full-day / multi-day cohort build

Same spine, extended: deeper codebase onboarding (AM), longer build with checkpoints (PM1), integration into a real sandboxed repo (PM2), and a sponsor readout at end of day. Multi-day variants add a champions teach-back day — yesterday’s attendees run today’s session. That is how adoption compounds: you stop being the bottleneck.

4. Running the room

1. Ship first, talk second. Credibility is earned by building, not slides. Open Cursor, build the thing, narrate the decisions.
2. Demonstrate at their altitude. Use their stack, their repo, their pain — never a polished demo repo.
3. Unblock at the point of friction. Watch for the moment someone stalls; intervene live. That is where learning sticks.
4. Make the skeptic your best evidence. Convert one skeptic publicly and the room follows.
5. Protect build time. Talking is cheap; shipping in the room is the whole point. Guard the clock.

The 10-minute live ship (credibility opener)

Before asking engineers to change anything, I ship something real in their world in ten minutes: take a small piece of their repo (or a representative one), use Cursor to add a feature end-to-end with tests passing, and demo it. The goal is the room thinking “this person actually builds” — then they will listen.

5. Judging rubric

Score each team 1–5 per criterion; weighted total out of 100.

Criterion	Weight	1 — Avoids	3 — Meets	5 — Exceeds
Real adoption signal (used agentic features, not just autocomplete)	30	Glorified copy-paste	Composer/agent for at least one real change	Multi-file agent edits, agent-written tests
Shipped & demonstrable	25	Slides only	Partial working demo	Working feature, tests green, mergeable
Domain relevance (solves a real workflow for this org)	20	Generic toy	Touched a real pain	Tackles a named top-3 workflow
Quality bar held (review, tests — no slop)	15	Unreviewed output	Reviewed manually	Eval/review loop used, CI green
Teach-back (can they reproduce it Monday?)	10	Can’t explain	Can redo the steps	Can coach a teammate

The rubric is the artifact that turns a hackathon into an adoption program: it defines the behaviour we are trying to make repeatable, and gives champions something to run themselves next time.

6. Post-event retro (capture outcomes, not vibes)

Send within 48 hours; copy CSM, deployment manager, and sponsor.

• What shipped — links to artifacts and repos, not screenshots
• Behaviour change observed — named engineers, named workflows (e.g. “Team B now runs Composer on every PR review”)
• Telemetry delta — active users, accept-rate, agent-invocations vs the T-30 baseline
• Friction found — what blocked adoption (feeds back to Product / Engineering)
• Champions identified — who carries this forward (the multiplier)
• Commitments — one workflow each engineer will run next week
• 30 / 60 / 90 adoption targets agreed with the sponsor

7. Turning outcomes into stories

For each engagement, produce one CS-ready story: Situation to Intervention to Adoption outcome (with a number) to Quote from an engineer. These feed the account team’s renewal and expansion narrative. Adoption outcomes — not event counts — are the metric that matters.

8. Feedback loop

Every three engagements, synthesise patterns (which interventions moved adoption, which flopped) and feed them back into program and content design. The playbook is versioned for exactly this reason — adoption infrastructure improves with every cohort.

---

Living artifact. v0.1 covers half-day and full-day formats; planned: a “champions teach-back” multi-day variant and account-specific cohort templates.