# Run an AI Workshop With Your Team A reusable template for a manager who wants their team to stop reading about AI and actually build something with it. Total commitment: one 1-hour prep meeting, one and a half days of workshop, and about three hours of your own planning time. Everything in brackets — `[TOOL]`, `[DATE]`, `[SPONSOR]` — is meant to be replaced. Cut any section that doesn't apply to your team. Two notes before you start: - **Tools.** This template says "your team's approved AI assistant" rather than naming one. Substitute whatever your company has approved (Claude, ChatGPT, Copilot, Gemini). If nothing is approved yet, that is your first task — see [Before you commit to a date](#before-you-commit-to-a-date). - **Technical vs. non-technical teams.** The shape of the workshop is identical either way. Where the guidance forks, you'll see a **Non-technical team** / **Technical team** pair. Mixed team? Run the non-technical version and let the engineers pick harder projects. --- ## What you're actually trying to accomplish The workshop is not a training course. Nobody learns to use AI from a slide deck. The goal is that every person on your team ships one small, real thing they built themselves, and leaves with the confidence that they could do it again on Monday. Pick two or three outcomes and write them down before you plan anything else. Good ones: - Every participant demos something they built. - Every participant has the tool installed, configured, and used it on real work at least once. - The team produces a shared list of prompts and patterns that worked. - Measurable lift in self-reported comfort with AI (you'll survey for this — see [Measure whether it worked](#measure-whether-it-worked)). Bad ones, which sound good and aren't: "the team learns about AI," "we evaluate AI tools," "we identify AI opportunities." Those produce a document. You want working artifacts. --- ## Roles | Role | Who | What they do | | --- | --- | --- | | Sponsor | `[SPONSOR]` — your manager or a senior leader | Approves the time, opens Day 1 for five minutes, attends the showcase. Their presence is what signals this isn't optional busywork. | | Facilitators | 1 per 5–6 participants | Run check-ins, unblock people, keep scope honest. At least one should be comfortable with the tool. | | Participants | Your team | Build. | | Showcase guests | Peer teams, adjacent leaders, `[SPONSOR]` | Attend the Day 2 demos. Nothing else. | If you're a team of six or fewer, you can facilitate alone — but you will not get to build anything yourself. Plan for that; a manager who disappears into their own project is the most common way check-ins get skipped. --- ## Before you commit to a date Work through this three or more weeks out. Items 1 and 2 are the ones that actually slip. 1. **Tool access.** Do you have licenses for everyone, or a path to get them? Procurement and security review can take weeks. Confirm this before you send a calendar invite. 2. **Data rules.** Get a written answer from security/legal/IT on what participants may and may not paste into the tool: customer data, employee data, source code, unreleased financials, PII. One sentence each is enough. You will restate this on Day 1, and you want to be quoting someone, not guessing. [ai-policy-template.md](./ai-policy-template.md) is the one-page version to publish once you have the answers, and [getting-approval.md](./getting-approval.md) is how to actually get them — including what to do when the request goes unanswered, which is the usual reason this item is the one that slips. 3. **Time.** Book the day and a half as blocked, no-meeting time. Get the sponsor to say out loud that participants are excused from their normal queue. Half-attending a workshop produces nothing. **If you're not confident you can hold it,** don't book it and hope — run the three-hour session in [compressed-rollout.md](./compressed-rollout.md) instead. A short workshop that happens beats a long one that keeps moving. 4. **Space.** One room the whole team can occupy for the duration — people learn a surprising amount by overhearing each other. Fully remote teams: use a persistent open video room, not scheduled calls, so "wander over and ask" still works. 5. **Facilitators.** Recruit them and walk them through this doc. 6. **Showcase audience.** Invite guests now, while calendars are open. --- ## Timeline at a glance | When | What | | --- | --- | | T-3 weeks | Licenses, data rules, sponsor sign-off, dates held | | T-2 weeks | Draft the project list, recruit facilitators, invite showcase guests | | T-1 week | **Kickoff meeting** (1 hour) + baseline survey | | T-1 week → T | Participants install tools, play, pick a project | | T-2 days | You confirm every participant has working access and an approved project | | Day 1 | Intro, project review, build, wrap-up | | Day 2 (half) | Build, showcase, retro, post survey | | T+1 week | Publish notes and the prompt library; schedule office hours | | T+4 weeks | Check what's still in use; report to the sponsor | --- ## Kickoff meeting (1 hour, one week out) One week is deliberate. Enough runway to install things and get curious; not so much that the details evaporate. The meeting has one non-negotiable job: **everyone leaves with the chosen AI tools installed, logged in, and working**, so the workshop itself is spent building — not spent watching people create accounts and fight logins. **Agenda** | Time | Item | | --- | --- | | 0:00 | Why we're doing this, and what "done" looks like (see outcomes above) | | 0:10 | Ground rules: what data may and may not go into the tool | | 0:20 | Live install and login, everyone at once | | 0:30 | Hand out the [starter project](./workshop-starter/README.md); fill in the team context files together | | 0:40 | Walk through the suggested project list | | 0:50 | Homework, logistics, questions | **The starter project.** Don't send people away with an empty window. [`workshop-starter/`](./workshop-starter/README.md) is a folder you copy and hand out: a `CLAUDE.md` with working guidelines, four ready-made skills (meeting notes, recurring report, reply drafts, document briefs), three slash commands, and context files for your team's specifics. **It needs Claude.** If your company approved Copilot, Gemini, ChatGPT, or anything else — which is the common case, since Copilot and Gemini come bundled with Microsoft 365 and Google Workspace — hand out [prompt-recipes.md](./prompt-recipes.md) instead. Same jobs, plain copy-paste prompts, works anywhere. Everything else in this workshop is identical either way; only the handout changes. Fill in `context/data-rules.md` before the meeting, and fill in `context/team.md` *during* it, as a group, on the projector — five minutes, and it's the difference between generic output and output that uses your team's names and terminology. That live fill-in is also the clearest possible demonstration of why context files matter, which is the main idea people need to leave with. **Decide before the meeting which way your team will use the tool** — in an editor like VS Code, in the desktop/web app, or at a terminal. The starter project works in all three, but the setup steps differ, and you don't want to discover that live. The starter's README has instructions for each; skim the one that applies and send it out with the invite. **Do the install live, in the meeting.** This is the single highest-value thing in the hour, and the reason to hold the meeting a week out at all: you want every person walking into the workshop already set up, so Day 1 is building instead of setup. "Install it before the workshop" reliably produces three people on Day 1 morning fighting SSO while everyone waits. Do it together, here, and have a facilitator handle stragglers afterward. **Non-technical team** — installation means: account created, logged in, on the right plan/workspace, one successful prompt sent, and (if you use them) any file-upload or connector permissions granted. **Technical team** — add: CLI or IDE extension installed and authenticated, repo access confirmed, any API keys issued, and one successful run against a real repo. **Homework, stated explicitly:** - Use the tool at least three times on real work this week. Anything counts. - Come to Day 1 with a project chosen, or two candidates. - Send the baseline survey (below) back before Day 1. --- ## Choosing projects Give people a list to react to. A blank page produces either paralysis or a project three times too big. Team members can propose their own, subject to your approval — approval exists to catch scope, not to gatekeep enthusiasm. **What makes a good workshop project** - **Small enough to demo in five minutes.** If they can't show it working, it didn't happen. - **Real work they personally do.** Not a hypothetical, not someone else's job. Motivation comes from the annoyance being their own. - **Repetitive.** Something done weekly beats something done once. - **Safe.** No customer data, nothing that touches production, nothing that sends email to real humans without a person reading it first. - **Buildable in about six hours by one person.** That's the real budget once you subtract check-ins and lunch. **Sizing tip:** ask "what's the version of this you could finish by lunch?" Then have them build that first and expand if there's time. A finished small thing demos far better than an unfinished ambitious one. ### Suggested projects — non-technical teams - Turn recurring meeting notes into a consistent set of action items with owners and dates. - Build a reusable prompt (or saved project/custom assistant) that drafts a recurring report from raw numbers you paste in. - Draft first-pass replies for a common support or internal question, in your team's voice. - Summarize a long document type you read often — RFPs, vendor contracts, research reports — into a one-page brief with a fixed structure. - Turn a messy spreadsheet export into a clean summary or chart with a written interpretation. - Build an onboarding guide for your team's most confusing process by interviewing the tool about your own draft. - Convert a manual checklist into a step-by-step assistant that asks the questions in order. ### Suggested projects — technical teams - Write tests for a module nobody wants to touch. - A CLI or script that automates a manual release/ops chore. - Draft documentation for an undocumented internal service, generated from the code and reviewed by the owner. - A repo-aware assistant configured with your team's conventions (context file, custom commands, house style). - Migrate a small legacy file to the current framework or language version, with the diff reviewed by a human. - A local agent that triages incoming issues or alerts and drafts a first response. - Instrument something you've been meaning to add logging or metrics to for a year. --- ## Day 1 (full day) | Time | Item | | --- | --- | | 9:00 | **Intro.** Sponsor opens (5 min). Goals, what success looks like, data rules restated. | | 9:20 | **Project round-robin.** Each person: 60 seconds on what they're building and what "done by tomorrow" means. Facilitators flag anything too big — right here, out loud. | | 10:00 | **Build.** | | 12:00 | Lunch (eat together if you can — the hallway conversation is half the value) | | 13:00 | **Build.** | | 16:30 | **Wrap-up (30 min).** Round the room: what you got working, what's blocking you, what you'll finish tomorrow morning. | **Facilitator check-ins.** Circulate about every 90 minutes. Don't ask "how's it going" — you'll get "fine" from exactly the people who are stuck. Ask: - Show me what you have working right now. - What did you last try that didn't work? - What will you have running by the end of the day? Two failure modes to watch for and correct immediately: someone silently stuck for an hour, and someone who has quietly redesigned their project into a quarter-long initiative. **Keep a running blockers list** visible to the room — a whiteboard or a shared doc. Half the entries get solved by someone else on the team reading it. --- ## Day 2 (half day) | Time | Item | | --- | --- | | 9:00 | **Build.** Last stretch — the brief is "make it demoable," not "add features." | | 10:15 | **Demo prep (15 min).** Everyone writes three sentences: the problem, what they built, what surprised them. | | 10:30 | **Showcase.** 5 minutes each, hard-stopped. Guests attend. | | 12:00 | **Retro + survey (30 min).** | **Showcase format.** Five minutes, timed, and enforce it — this is the part that makes the workshop visible to the rest of the company, and it falls apart if the first three demos run twelve minutes each. Each person covers: 1. The problem, in one sentence. 2. Live demo of the thing working. Not slides. 3. How they built it — which prompts, what they'd tell someone starting today. 4. What didn't work. Point 4 is not optional. A showcase where everything worked teaches the audience nothing and quietly implies that the people who struggled did something wrong. Have someone take notes, and record it if your team is comfortable with that — remote colleagues and future participants will watch it. Budget: 5 minutes each plus questions, so 10 people ≈ 75 minutes. Split into two rooms if you're larger than about 12. --- ## Capture what you learned Do this in the room, at the retro, while it's fresh. A doc you promise to write later doesn't get written. For each project, one short entry: ``` Project: Who built it: What it does: Prompts / setup that worked: What didn't work, and what we tried instead: What I'd do differently: Is this something I'll keep using? (yes / no / needs work) Would someone else on the team benefit from this? ``` Then, as a team: - **What went well.** - **What we'd change about the workshop itself.** - **The prompt library.** Pull the reusable prompts out of the entries above into one shared document. This is the most durable artifact the workshop produces — it outlives every individual project. --- ## Measure whether it worked Run the same five questions before the kickoff meeting and again at the end of Day 2. Same wording both times, 1–5 scale, anonymous. 1. I understand what AI tools can and can't do for my job. 2. I feel confident using an AI assistant on real work. 3. I know what data I'm allowed to put into these tools. 4. I could teach a colleague to do what I do with AI. 5. I expect to use AI in my work next week. Add two open-ended questions at the end only: - What surprised you? - What's the one thing you'll use next week? Also worth tracking, four weeks later: how many of the workshop projects are still in use. That number, not the survey, is what you take to `[SPONSOR]`. Be honest about the limits — this is self-reported confidence, not productivity. If someone asks you for hours saved, the credible version is a per-project estimate from the person who built it ("this report took me 90 minutes a week, now it takes 20"), collected in the capture form and clearly labeled as an estimate. --- ## After the workshop The workshop fails quietly if nothing follows it. Three low-cost things: - **Publish within a week.** Notes, the prompt library, and the showcase recording, somewhere the whole company can find them. - **Office hours.** 30 minutes weekly for a month. Attendance will drop to zero by week four and that's the correct outcome — it means people are unblocked. - **Name owners.** For each project someone wants to keep using, write down who maintains it. Things built in a workshop and adopted by a team without an owner become the team's problem in six months. Then tell `[SPONSOR]` what happened, in specifics: what was built, what's still running, what the team wants next. --- ## Common ways this goes wrong | Failure | Fix | | --- | --- | | Half of Day 1 lost to installs and logins | Install live in the kickoff meeting, one week out | | Projects too big to finish | 60-second round-robin on Day 1 with facilitators empowered to shrink scope on the spot | | One person builds everything, others watch | Everyone demos. Say this on day one and mean it | | Nobody knows what data is allowed | Get it in writing before the workshop; restate on Day 1 | | Participants pulled into normal work | Sponsor blocks the time explicitly and publicly | | Great work, nobody outside sees it | Invite guests to the showcase; publish the recording | | Nothing survives the week | Owners named, prompt library published, office hours | | The skeptics stay skeptical | Pair them with a project that removes a chore they personally hate. Don't argue about AI in the abstract | --- ## Running it remote or hybrid Everything above assumes a room. Most of it still works over video — the failure modes just get quieter and harder to spot. A stuck person in a room fidgets; a stuck person on a call goes silent and looks exactly like a busy one. Plan around that. **Do the async prep for real, because you can't lean over and fix it live.** Send the starter project and the setup steps three days out, not one, and ask each person to confirm they got a real reply out of the tool before Day 1 — a screenshot, not a thumbs-up. The half-day you lose to installs in a room becomes a whole morning of dead air on a call. **Use breakout rooms as your project pods.** Three to four people each, a named facilitator in each who can actually build, and a shared doc per room so work is visible without screen-sharing. Rotate yourself through the rooms the way you'd walk the floor. The round-robin that shrinks over-scoped projects on Day 1 matters *more* remote — do it on the main call before anyone breaks out. **Make screen-sharing the default, not the exception.** "Share your screen and let's look at it together" is the remote version of leaning over someone's shoulder, and it's how you catch the silent-stuck person. Normalize it on Day 1 so nobody reads a share request as being singled out. **Shorten the days and add breaks.** A full day on video is longer than a full day in a room. Prefer two half-days over one full day, put a real 10-minute break every hour, and keep the demos strictly timed — remote attention doesn't survive a rambling showcase. **Record the showcase, and mean it.** This is the one part remote does *better*: the demos are already on video. Record them, publish the link, and you've solved "great work, nobody outside sees it" for free. **If it's hybrid, pick one mode and commit.** A few people in a conference room with the rest dialing in is the worst case — the room talks, the remote people can't get a word in, and the demos only work for whoever's near the good camera. Either get everyone on their own laptop on the call (even the ones in the building), or run it fully in person. Don't split the difference. **Time zones:** if the team spans more than about four hours, don't force a synchronous full day. Run a shorter shared core (kickoff, project pods, showcase) and let the building happen in each person's own hours, with facilitators reachable in a channel. --- ## Appendix: messages you can copy **Kickoff invite** > Subject: AI workshop prep — 1 hour, `[DATE]` > > We're running a hands-on AI workshop on `[DATES]`. A day and a half, > and by the end everyone will have built one real thing they can use. > > This meeting is prep: we'll get the tools installed and logged in > together, cover what data we can and can't use, and look at a list of > project ideas. Come with a rough idea of a repetitive part of your job > you'd like to hand off — and if you already have something in mind you > want to build, bring it. > > No prep needed for this one. Just bring your laptop. **Day-before reminder** > Tomorrow's the workshop — `[TIME]`, `[LOCATION/LINK]`. > > Before you log off today, please confirm: you can log into `[TOOL]`, > and you know what you're building. If either is shaky, ping me now > rather than at 9am tomorrow. > > Reminder on data: `[ONE-LINE DATA RULE]`. **Showcase invite (external guests)** > Subject: Come see what `[TEAM]` built with AI — `[DATE]`, `[TIME]` > > The team spent a day and a half building working AI tools for their > own jobs. They're demoing what they made — 5 minutes each, live, no > slides. Drop in for any part of it. > > If your team is thinking about doing something similar, this is the > fastest way to see what's realistic.