# 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](./worked-example.md) — 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](./ai-policy-template.md) — the
  fill-in-the-blank policy described in section 2.
- [Getting the Yes](./getting-approval.md) — how to get the data rules
  signed off, which is the step that actually blocks people.
- [Operating Templates](./operating-templates.md) — six fill-in tools
  for the parts of this you have to run, not just plan.
- [Run an AI Workshop With Your Team](./ai-workshop.md) — the full
  workshop template referenced in section 4.
- [The Compressed Version](./compressed-rollout.md) — the same sequence
  in 30 days and three hours, if the plan below is more calendar than
  you can hold.
- [Workshop Starter Project](./workshop-starter/README.md) — 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](./prompt-recipes.md) instead.

---

## The short version

If you read nothing else:

1. **Name one owner.** Not a committee, not "the team." One person with
   two hours a week. Adoption assigned to everyone happens to no one.
2. **Write the one-page policy** so people know what's allowed before
   you ask them to use anything.
3. **Pick 3–5 real use cases** from work your team already does weekly.
4. **Run a workshop** so everyone builds one thing themselves.
5. **Measure honestly** — usage and specific artifacts, not vibes and
   not vendor-provided "productivity gains."
6. **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](./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](./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](./ai-workshop.md)) | 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](./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:

1. **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.
2. **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.*
3. **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.
4. **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](./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](./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](./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](./workshop-starter/README.md) — 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](./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](./operating-templates.md). A filled-in one is
in [worked-example.md](./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](./workshop-starter/README.md) or
[prompt-recipes.md](./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):

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.

**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](./operating-templates.md); a
real-shaped one, including the failure it volunteers, is in
[worked-example.md](./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](./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](./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