# The Compressed Version — 30 days, three hours of calendar *The full toolkit assumes 13 weeks and a day and a half of everyone's time. Plenty of managers can't get either. This is the same sequence at a fifth of the cost — what to keep, what to cut, and what you're actually giving up.* Use this if any of these is true: - You can't hold a day and a half of your team's calendar, and you know it. - Someone above you wants to see something within the month. - Your team is under ten people and 13 weeks of ceremony would feel absurd. - You already tried the long version, it slipped twice, and it's now been "next quarter" for two quarters. **The honest trade.** The compressed version gets you roughly 70% of the outcome for about 20% of the calendar cost. What you lose is depth per person — fewer people build something they keep, and the things they build are smaller. What you keep is the entire mechanism: written rules, a real example from your own team, everyone touching it once, and someone owning what survives. Those four are what make it stick, and none of them requires 13 weeks. **What you must not cut,** whatever else you do: 1. **The written data rules.** Non-negotiable, and mostly not your time — see [getting-approval.md](./getting-approval.md), because this is the step with the longest lead time and the least control. Compressing the calendar never means proceeding without them: until they land, everything runs on public or made-up material only. See [the one hard gate](#the-one-hard-gate). 2. **A baseline.** Ten minutes. You cannot recover one later. 3. **One named owner.** Even at this size. Even if it's you. 4. **Somebody's real before-and-after.** One is enough. Zero is fatal. --- ## The 30-day sequence | Days | What you do | Your time | Team's time | | --- | --- | --- | --- | | 0 | Send the approval email. Name the owner. | 30 min | — | | 1–3 | Baseline survey out. Draft the policy while you wait on security. | 45 min | 5 min each | | 4–10 | **Micro-pilot:** you and one other person, one task each — on public or made-up material until the rules land. | 2 hrs | 2 hrs (one person) | | — | ⛔ **Gate: written data rules confirmed.** | — | — | | 11+ | Publish the policy. Re-run the pilot task on the real thing. | 30 min | 20 min | | +2–3 days | Book the session. Send the project list. | 30 min | — | | Session day | **The three-hour session.** Everyone builds one thing. | 3 hrs | 3 hrs | | +5 days | Capture the library. Name owners for what survived. | 1 hr | — | | ~30 | Post survey + a short honest update. | 45 min | 5 min each | **Total: about 9 hours of yours, about 4 of everyone else's.** Day 0 is the send-the-email day because the approval is the only part you don't control. Everything else can compress; that can't — which is why the day numbers stop being fixed at the gate. If security takes three weeks, the schedule slides three weeks. Sliding is fine; starting without them isn't. ### The one hard gate **Nothing touches real company material until the written rules come back.** Not a sanitized export, not "just this once for the demo," not a document you're fairly sure is fine. That's the constraint the whole 30-day plan bends around, and it's the reason the micro-pilot is where it is in the table rather than after the policy. Before confirmation, the micro-pilot uses **only**: - material that's already public — your website, published documents, anything a stranger could read - material you made up for the purpose, with the same *shape* as the real thing but invented names and numbers - anything security, legal, or IT has already approved in writing That's enough to learn the tool and enough to produce a usable before-and-after, because what you're measuring is how long the *task* takes, and a realistic fake input takes the same effort to process as a real one. If you cannot even get the rules to run a pilot on invented data, publish the interim notice in [getting-approval.md](./getting-approval.md) and keep escalating — don't quietly proceed. After confirmation: publish the policy, then re-run the same task on the real input. That re-run is fast (you already know the prompt) and it's what turns an illustrative number into a real one you can quote. ### Days 4–10: the micro-pilot This is the step people cut first and it's the one that carries the session. Not 3–5 people and 3–5 use cases — **two people, two tasks, one week**. You're one of them. Do it on your own work, so you can speak from having done it rather than having read about it. Pick the other person for credibility, not enthusiasm: the one whose opinion the team already checks against. You need exactly one outcome from this week: **a before-and-after from someone in the room.** "Here's how Priya's Thursday summary went from 50 minutes to 15" is what makes the session land. Without it you're running a demo of somebody else's software. If the rules haven't landed yet, that number comes from the run on invented data and you say so when you show it — an honest "on a test file" costs you nothing and is a better look than a number you can't source. Score your candidates with sheet 1 of [operating-templates.md](./operating-templates.md) if you have competing options — it takes five minutes and stops the argument. If one task is obviously the answer, skip the scoring and start. --- ## The three-hour session Same design as the full workshop — everyone builds one real thing and shows it — compressed hard. It works because you cut *scope per project*, not the structure. **Before, non-negotiable:** everyone arrives logged in with a working tool. Send the setup steps three days ahead and ask for a screenshot of one real reply, not a thumbs-up. If you skip this, you're running a 90-minute session, because installs will take the rest. | Time | Item | | --- | --- | | 0:00 | **Why, and the data rules.** 10 minutes, not 30. Read the policy out. | | 0:10 | **The example.** You or your pilot partner shows the before-and-after live. This is the most important ten minutes of the session. | | 0:20 | **Pick, out loud.** Each person names their task in one sentence. You shrink anything too big on the spot. | | 0:35 | **Build.** | | 1:45 | **Break.** 10 minutes, real. | | 1:55 | **Build.** | | 2:30 | **Show.** 3 minutes each, hard-stopped. Everyone, no exceptions. | | 2:55 | **Capture.** One line each into the shared doc, in the room. | **Circulate every 30 minutes, not every 90.** Three hours doesn't forgive a person being silently stuck for an hour. Ask: *show me what you have working right now*, and *what did you last try that didn't work?* ### The sizing rule that makes three hours work **"What's the version of this you could finish in an hour?"** Then have them build that. In a day and a half you can let someone attempt something ambitious and rescue it. In three hours you cannot, so the scoping happens out loud at 0:20 and you are the one who does it. Be blunt about it — "that's a great second version, build the first one today" is a kindness at this length. Projects that reliably finish in an hour: turning last week's recurring report into a saved prompt; a reply template for the question everyone answers twice a week; a long-document brief with a fixed structure; a messy export into a readable summary; the glossary of your team's jargon, written by explaining it to the tool. The recipes for all of these are in [prompt-recipes.md](./prompt-recipes.md) — hand that file out at the start and half the room has a running start. ### Three hours, twelve people, one facilitator If you're alone with a large group, change two things. Pair people up — one project per pair, which halves the check-ins and means nobody is stuck alone. And cut the show to 2 minutes with a timer visible to the room. --- ## The 90-minute version If three hours is genuinely impossible: run the session as **60 minutes of building plus 20 minutes of showing**, and make everyone build *the same thing* — the one workflow from your micro-pilot, adapted to their own work. This is meaningfully worse. Nobody chooses their own project, which is where most of the motivation lives. But it does deliver the one thing that matters most: every person in the room has now made an AI tool do something useful with their own material, once. That single experience is most of what separates a team that adopts from a team that doesn't. What you're giving up, stated plainly, so you can decide rather than discover: no showcase guests, so the work stays invisible outside the team; almost nothing built will survive without a follow-up session; and the skeptics will not be converted in 90 minutes — at best they'll be curious. --- ## Days 16–20: the part that actually decides it The compressed version fails in exactly the same place as the long one — the week after — and it fails faster, because less was built. Three things, about an hour total: - **Publish the library within 48 hours,** while people can still remember what they did. One shared doc, one line per prompt: what it's for, and the prompt. - **Name an owner for anything anyone wants to keep using.** Use sheet 5 of [operating-templates.md](./operating-templates.md). It takes two minutes per item and it's the difference between four working things and a fond memory. - **One 30-minute office hour, once.** Book it for the week after. If nobody comes, that's fine and you don't repeat it. Then add a 30-second ritual to your existing team meeting: *what went into the library this week?* No new meeting, and it's the cheapest mechanism in this whole toolkit. --- ## Day 30: the update Same format as the full version — sheet 6 of [operating-templates.md](./operating-templates.md) — with your claims sized to what you did. You ran a three-hour session, not a transformation programme, and saying so is what makes the rest credible. > Eleven people have licenses; eight used it last month, up from two. > We ran a three-hour session on the 15th; everyone built something and > five of those are still in use. The clearest case: `[NAME]`'s > `[TASK]`, about `[BEFORE]` down to about `[AFTER]` — their estimate. > We spent about four hours of team time on this in total. We haven't > tried to measure aggregate productivity and I'd be skeptical of > anyone who claims to. What we'd like next: `[ASK]`. The low time cost is a feature — say it out loud. "Four hours of team time" is what makes the next request easy to approve, and it's the sentence that gets you the day and a half next quarter if you want it. --- ## What to do if it worked Don't immediately schedule the long version. Do the same 30 days again with the next two use cases from your scoring sheet. Two rounds of 30 days beats one 13-week programme for most teams, because each round ends in something real and neither round is ever the thing that gets cancelled when the quarter gets busy. The full sequence is worth running when you've got a genuine mandate, budget, and a sponsor who'll block the calendar. Until then this is not a lesser version of the toolkit — it's the version that ships. --- *Related: the full 13-week sequence is in [managers-toolkit.md](./managers-toolkit.md); the full day-and-a-half workshop is [ai-workshop.md](./ai-workshop.md); a team that ran this compressed session is in [worked-example.md](./worked-example.md), section 9.*