The Manager’s AI Toolkit

Section overview

This section is targeted towards managers. The goal is to give them information and tools to help with AI adoption and utilization within their team.

It’s written for the manager of a team of roughly 5–30 people who has been handed AI tools, or has gone and got them, and is now responsible for something happening. It assumes no technical background. Where a step differs for engineering teams, that’s called out.

Bracketed items — [TOOL], [OWNER], [DATE] — are yours to fill in.

Companion docs

Worked Example — one (invented) team with every template in this toolkit already filled in, including what went wrong. If you only open one other file, open that one.
One-Page AI Policy Template — the fill-in-the-blank policy described in section 2.
Getting the Yes — how to get the data rules signed off, which is the step that actually blocks people.
Operating Templates — six fill-in tools for the parts of this you have to run, not just plan.
Run an AI Workshop With Your Team — the full workshop template referenced in section 4.
The Compressed Version — the same sequence in 30 days and three hours, if the plan below is more calendar than you can hold.
Workshop Starter Project — a copy-and-hand-out project folder with working skills, commands, and a CLAUDE.md your team fills in. Needs Claude; on any other assistant use Prompt Recipes instead.

The short version

If you read nothing else:

Name one owner. Not a committee, not “the team.” One person with two hours a week. Adoption assigned to everyone happens to no one.
Write the one-page policy so people know what’s allowed before you ask them to use anything.
Pick 3–5 real use cases from work your team already does weekly.
Run a workshop so everyone builds one thing themselves.
Measure honestly — usage and specific artifacts, not vibes and not vendor-provided “productivity gains.”
Assign owners to what survives, or it rots by Q3.

Everything below is the long version of those six.

Two shortcuts worth knowing about now. If you want to see all of this already filled in for a real-shaped team before you write anything, that’s worked-example.md. If a 90-day plan and a day-and-a-half workshop is more calendar than you can realistically hold, take compressed-rollout.md instead — it’s 30 days and three hours, and it’s a better plan than a long one that gets cancelled.

1. The rollout sequence

Most rollouts fail at the same place: they end where adoption begins. Licenses get bought, IT flips access on, someone sends a launch email, the project is marked complete. Access was granted; adoption never started.

Adoption is the part after the email — the weeks of noticing that someone still does a report by hand, sitting with them to find the one step AI genuinely helps with, and checking back to see whether it stuck. That work is real work, and if it isn’t on someone’s job description it does not happen.

A 90-day plan

Phase	Weeks	What you do	Done looks like
Ground rules	1–2	Name the owner. Write the policy. Confirm licenses and data rules.	Everyone can state what they’re allowed to put in the tool
Pilot	3–6	3–5 people, 3–5 use cases, close support	At least three working examples from real work
Workshop	7–8	Whole team builds something (workshop doc)	Everyone has shipped and demoed one thing
Habit	9–12	Office hours, prompt library, owners named	Usage is boring and unremarked
Report	13	Honest write-up to leadership	Specific artifacts, honest numbers, a named ask

Why a pilot before the workshop

The pilot’s job is not to prove AI works — you already believe that. It’s to generate three or four concrete examples from your team’s own work that you can show at the workshop. “Here’s how Maria cut her Friday report from 90 minutes to 20” beats any vendor demo, because the room knows Maria and knows the report.

Pick pilot people for credibility, not enthusiasm. One respected skeptic who comes around is worth five early adopters.

What to resist

Org-wide launch with no pilot. Produces a spike of curiosity and a trough of nothing.
Mandating usage. You get compliance theater: people running work through the tool to be seen doing it. Mandate the outcome if you must; never the tool.
Waiting for the perfect tool. The gap between the top tools is smaller than the gap between using one and using none.
Buying more tools when the first one isn’t used. Tool count is not adoption.

2. Ground rules: the one-page policy

People will not experiment freely until they know where the line is. An unwritten policy doesn’t produce caution — it produces quiet, unmonitored use with no guardrails at all.

Use the template. ai-policy-template.md is a fill-in-the-blank version of everything below — brackets to replace and nothing else to write.

Keep it to one page. Four parts:

What it’s good for. Lead with permission, not prohibition: drafting, summarizing, brainstorming, rewriting, explaining things nobody wants to admit they don’t understand. A policy that’s all “don’t” gets ignored or scares people off the tool entirely, and you lose the upside.
The one hard line. What never goes in: customer or client data identifying real people, anything under NDA, regulated data (health, financial, legal specifics), credentials and API keys. The plain version of the rule: if you’d hesitate to post it publicly, it doesn’t go in.
Verify and disclose where stakes are real. A human approves anything client-facing or consequential. Disclosure where the audience would reasonably want to know — not on every reworded email.
One name to ask. Say the policy will change as the tools do, and give people someone to ask when unsure. A question asked out loud is a leak prevented.

Your job before any of this: get the answer in writing from security/legal/IT rather than inventing it. If you have an approved, paid tool with a real data agreement, name it in the policy and point people there for the riskier work.

That sentence is easy to write and hard to do — it’s the single most common place this whole sequence stalls, usually not because anyone said no but because nobody replied. getting-approval.md is the whole job: who to ask, the five questions that are actually answerable, the email to send, what to do at day 10, 20, and 30 of silence, and what you can get on with in the meantime. Send it on day one — it’s the only step whose timing you don’t control.

Engineering teams — add three lines: whether source code may be sent to the tool and which repos are excluded, that generated code is reviewed like any other code, and how license-encumbered output is handled.

3. Picking the first use cases

Most teams pick badly on the first try, in a predictable direction: too ambitious, too rare, too far from the person choosing.

A good first use case is:

Frequent. Weekly beats quarterly. The value is in the repetition, and so is the learning.
Owned by the person doing it. Motivation comes from the annoyance being your own. Nobody automates someone else’s chore with energy.
Low-stakes on the way out. A human reads it before it reaches a customer.
Text-shaped. Drafting, summarizing, reformatting, explaining, extracting. These are where today’s tools are strongest.
Small enough to show working within a day.

Reliable starting points

Kind of work	Example
Meeting → action	Notes into owners, dates, decisions
Recurring report	Same structure every week, different numbers
First-draft replies	Common questions, answered in your team’s voice
Long doc → brief	Contracts, RFPs, research into a one-page summary
Messy data → summary	A spreadsheet export into a readable interpretation
Explaining	Jargon, legalese, or a system nobody documented

Engineering teams — tests for untouched modules, docs for undocumented services, small migrations, ops scripts, alert triage. Same criteria: frequent, owned, reviewable.

Avoid at the start: anything touching production, anything sending to real customers unread, anything requiring the tool to be right 100% of the time, and anything where “did it work?” takes a month to answer.

A cheap way to find them. Ask each person: what part of your week do you dread, that’s basically the same every time? Write the answers on a wall. The first use cases are on that wall.

4. The workshop

Once ground rules exist and you have a few pilot examples, run a workshop so everyone builds something themselves. This is the step that converts “I’ve heard about it” into “I’ve done it.”

The full template — timeline, agendas, project lists, surveys, copy-paste emails — is in ai-workshop.md. The short form: a 1-hour kickoff a week ahead where you install the chosen tools live so nobody arrives unprepared, then a day and a half of building, ending in a showcase where every person demos and outside guests attend.

Why a workshop rather than training: nobody learns to use AI from a slide deck, and the demo is what makes the work visible to the rest of the company.

If you can’t hold a day and a half — and plenty of managers genuinely can’t — run the three-hour version in compressed-rollout.md rather than dropping the step. The structure is what matters, not the length: everyone builds one thing, everyone shows it, someone owns what survives. A three-hour session that happens beats a day and a half that keeps moving to next quarter.

Hand out something at the kickoff — never an empty window. People given a blank page mostly produce one-line prompts and conclude the tool is mediocre. Give them something that already half-works and let them improve it; “editing this until it does what I want” is the actual competence you’re trying to build.

Which handout depends on your tool. On Claude, it’s the starter project — four working skills, a CLAUDE.md of guidelines, and context files for your team’s names and terminology. On Copilot, Gemini, ChatGPT, or anything else, it’s prompt-recipes.md, which is the same jobs as copy-paste prompts. Check which one you’re actually paying for before you plan the kickoff around the wrong one.

5. Ownership and maintenance

Things built in a workshop and adopted by a team without an owner become the team’s problem in six months. Handle it before that.

When something graduates from experiment to dependency, write down four things:

What it is:
Owner (a person, not a team):
What breaks if it stops working:
Reviewed / re-checked: [how often]

The fuller version — including the two single-point-of-failure boxes that catch the “someone else could run this” assumption before it’s tested — is sheet 5 of operating-templates.md. A filled-in one is in worked-example.md, section 7.

The maintenance realities people miss:

Model updates change output. A prompt tuned to one model version can behave differently after an update. Anything load-bearing needs an occasional spot-check, not set-and-forget.
The builder leaves. If one person’s private prompt is now in the team’s critical path, it’s a single point of failure. Move it somewhere shared and make sure someone else has run it.
Silent degradation. Wrong output that looks right is the failure mode to design against. Keep a human check on anything consequential.
Cost drift. Usage-based tools get expensive quietly. Whoever owns the budget should see usage monthly.

The prompt library. One shared document of prompts and setups that worked, with a line on what each is for. The cheapest way to start one: merge everyone’s edited copy of whatever you handed out at the kickoff — the starter project or prompt-recipes.md — back into one shared file at the end of the workshop. The library then has a shape already, rather than being a blank doc someone is supposed to fill in. It’s the most durable artifact the whole effort produces — it outlives every individual project, and it’s what makes a new hire productive in week one instead of month three. Someone owns it, or it decays into a graveyard.

Sunset things deliberately. Once a quarter, ask which of these nobody uses anymore, and delete them. A toolkit of twelve things where four work is worse than four that work.

6. Skeptics and over-enthusiasts

Both groups fail, in opposite directions, and both need managing.

The skeptic

Usually right about something. The common versions:

What they say	What’s actually true	What to do
”It makes things up”	Yes, confidently	Agree. That’s why verification is in the policy. Point them at use cases where a human reads the output anyway
”It’s not good at my job”	Often true for the hard 20%	Concede the hard part; aim at the boring 80%
“I tried it and it was useless”	Usually a one-line prompt with no context	Sit with them once. The gap between a bad prompt and a good one is the whole thing
”This is about replacing us”	The fear is legitimate	Answer it straight, in plain language, and don’t over-promise. Vague reassurance reads as confirmation

The move that works: pair them with the chore they personally hate most. Never argue about AI in the abstract — that argument has no end state. And genuinely leave room for “we tried, it doesn’t help here.” A manager who can’t hear that gets told nothing at all.

The over-enthusiast

Less discussed, more damaging when unmanaged:

Ships unverified output. Set the expectation that they own what they send, whoever drafted it.
Automates things that shouldn’t be. Performance feedback, condolences, anything where the point is that a human spent time.
Builds fragile machinery nobody else understands. Six chained steps only they can debug. Route them into section 5 — owner, notes, someone else runs it once.
Pastes things they shouldn’t. Speed and caution trade off. Re-read them the hard line.

You want their energy — they’re your pilot group and your best demonstrators. Aim it at building things other people can use, and make “someone else can run this” the standard they’re measured against.

The quiet majority

Neither loud group is the real target. The middle tries it twice, hits friction, and silently reverts — reverting costs nothing and nobody notices. This is why the owner in section 1 exists, and why office hours and check-ins matter more than any launch email.

7. Measurement

Measure so you can steer, and so you can answer leadership honestly. Both get harder if you started with no baseline — so take one before anything launches.

What’s worth tracking

Signal	How	Why it’s honest
Active usage	Admin console, weekly or monthly actives	Distinguishes access from adoption
Artifacts	Count of things built and still in use at 30 days	The number that survives scrutiny
Self-reported confidence	Same 5 questions before and after	Cheap, comparable over time
Per-task estimates	From the person who does the task	Credible when labeled as an estimate
Prompt library growth	Entries added per month	Proxy for shared, not siloed, learning

The confidence survey (1–5, anonymous, same wording every time):

I understand what AI tools can and can’t do for my job.
I feel confident using an AI assistant on real work.
I know what data I’m allowed to put into these tools.
I could teach a colleague to do what I do with AI.
I expect to use AI in my work next week.

Be honest about what this isn’t. Self-reported confidence is not productivity. Time saved on a task is not time returned to the business, because the saved time goes somewhere and usually isn’t tracked. Studies claiming dramatic organization-wide productivity gains are mostly measuring task-level speed in controlled conditions. If you inflate the claim, the first person who checks discredits the whole effort — including the parts that genuinely worked.

The version to take to leadership:

Twelve people have access; nine used it last month. Seven things were built in the workshop; five are still in weekly use. The clearest single case: [NAME]’s weekly [REPORT], which took about 90 minutes and now takes about 20 — their estimate. We have not tried to measure aggregate productivity and I’d be skeptical of anyone who claims to. What we need next: [ASK].

Specific, checkable, and it makes the ask credible. The fill-in version is sheet 6 of operating-templates.md; a real-shaped one, including the failure it volunteers, is in worked-example.md, section 8.

8. Your own AI use

The fastest way to kill adoption is to sponsor it without doing it. Teams read that instantly: this is a thing that happens to us, not with us.

Use it weekly on your own work, visibly. Meeting notes, first drafts, reading long documents. Say when you did.
Share your failures out loud. The most useful thing a manager can say is “I tried it for this and it was worse than doing it myself.” It gives everyone else permission to report honestly, which is the only way you find out what’s actually working.
Don’t delegate the learning. If your entire understanding comes through one enthusiastic person, you can’t evaluate their claims or spot the thing they’re overselling.
Keep the human parts human. Feedback, hard conversations, praise that should mean something. The point of some work is that you spent the time.
Model the verification you’re asking for. If you send around AI output with an error in it, the policy is dead the same day.

You don’t need to be the most skilled user on the team. You need to be visibly a user, and honest about where it falls short.

Checklist

Pull this out at the start.

Before anything

One named owner, with hours protected for it
Licenses confirmed for everyone who’ll need them
Approval email sent on day one (getting-approval.md) — longest lead time
Data rules in writing from security/legal/IT
Baseline survey run
One-page policy written and sent

Pilot (weeks 3–6)

3–5 people, chosen for credibility
3–5 use cases from real weekly work
Weekly check-in with each of them
Three concrete examples captured to show the team

Workshop (weeks 7–8)

See ai-workshop.md

Habit (weeks 9–12)

Prompt library published, with an owner
Office hours running
Owner named for everything still in use
Post survey run and compared to baseline

Report (week 13)

Usage numbers, artifacts still in use, one clear example
Honest statement of what you did not measure
A specific ask