Show a colleague: the 30-minute demo

T13-L02 · Adoption & enablement · Level 2 Power user · 20 minutes

At Level 2, your demonstration can influence what a colleague puts into a shared document or sends to the team. A convincing but unchecked result therefore has a larger blast radius than an experiment that stays in your own notes.

2. The room has already seen the slides

You have thirty minutes in a group meeting. You have seen an approved AI assistant turn a tedious source-based task into a useful first draft. Your colleagues have not. Their last AI session was twenty slides about disruption, followed by a polished example that had nothing to do with their work.

One colleague expects the assistant to invent facts. Another hears "efficiency" and wonders which jobs will disappear. A third thinks all AI use is forbidden. If you answer with bigger claims, a model leaderboard, or another slide deck, you will lose the room.

You need to show one ordinary task they recognise, use safe material, expose the checking step, and let a colleague take control. Success is not applause. Success is that one person leaves with a specific, permitted task they have chosen to try.

3. After this you can

• Select a familiar task that can produce a visible result within ten minutes.
• Run a live before-and-after demonstration inside a fixed 30-minute agenda.
• Verify the result in front of the colleague instead of hiding uncertainty.
• Answer the three recurring objections without overselling or dismissing them.
• Measure whether the demonstration produced one specific first-task commitment.

4. Prerequisites

• T01-L02 · Trust but verify.
• T02-L02 · Your daily driver.
• One approved assistant and an account that you are permitted to demonstrate.
• A colleague who has agreed to a 30-minute session and can type during it.
• A stopwatch or visible clock and a text editor for the demo record.
• One short public, synthetic, or explicitly approved source and one rehearsed prompt.

Do not demonstrate with customer records, participant or patient data, unpublished results, confidential contracts, personnel information, credentials, or an unapproved account. The fixtures below are synthetic. Replace them only with material explicitly approved for this session.

5. The idea in one page

A useful adoption demo changes the colleague's next action, not their opinion about AI in general. Before the session, write this outcome: By minute 30, the colleague has named one permitted task, its input, its desired output, and when they will test it. That statement is observable. "They understand AI" is not.

Choose a task with five properties:

1. It is theirs. Use a job they perform or review, not your favourite workflow.
2. It is boring. Reformatting notes, extracting fields, or drafting a bounded update usually lands better than an impressive creative stunt.
3. It fits. The input can be understood quickly and the result appears within ten minutes.
4. It can be checked. Keep the source visible and verify names, numbers, dates, claims, and omissions.
5. It is safe. Use only an approved tool and permitted data. If the boundary is unclear, switch to a synthetic fixture.

Rehearse once with the exact fixture, prompt, account, display, and network you will use. Save the fixture and prompt locally. Rehearsal does not guarantee a smooth live run; it removes avoidable surprises and gives you a manual fallback. Never substitute a secretly prerecorded success while calling it live.

Run the meeting in four moves: their task, live attempt, visible check, their turn. Show the raw input first so the colleague can judge the transformation. Start the timer. Run one prompt, then inspect the answer against the source. Do not polish away a wrong result. Name it, correct the instruction or reject the result, and show that checking is part of the work.

Then move the keyboard. Ask the colleague to request one change or try one follow-up. This separates a performance they watched from a method they can use. Reserve the final minutes for objections and the written first task.

Measure the outcome with evidence that matches the claim. Record actual start and finish times, whether the result passed its stated checks, whether the colleague typed, and whether their first task names input, output, safety boundary, and test date. An enthusiastic comment without a next action is interest, not adoption. A specific small trial is enough; you do not need a promise of permanent use.

6. The worked example: one timed slot, two settings

Both examples use the same 30-minute run sheet and the same success bar. Mira uses literature notes in a Lab group meeting. Jonas uses supplier-status notes in a Company department meeting. Each fixture is fictional, each output remains a draft, and each colleague controls the final interpretation.

Lab framing: turn reading notes into a meeting brief

Mira asks Arun which recurring task he dislikes. He chooses turning scattered reading notes into the weekly literature discussion table. Mira prepares this synthetic fixture:

[P-17] Cedar study: 24 samples; compares method A and B; limitations not stated
in abstract; full text still to check.
[P-18] Harbor study: review article; no new experiment; useful background on
method B; published 2024.
[P-19] Northwind study: 18 samples; method B had shorter processing time;
exact time is not present in these notes; full text still to check.
Meeting question: Which paper should we inspect first for a method comparison?

Before opening the assistant, she shows the notes and asks Arun how he handles them now. He says he manually copies title, study type, count, relevance, and missing evidence into a table. That is the before state. She states the live checks: four rows or fewer, every number traceable to the notes, no invented processing time, and unresolved evidence clearly marked.

At minute 5 she starts the live attempt with this prompt:

Turn the supplied reading notes into a meeting brief.
Return a table with: source ID, study type, supplied sample count, relevance to
the meeting question, and next check. Use only the notes. Write "not supplied"
for missing facts. Do not recommend inclusion or claim which method is better.
End with one question the group must decide.

The output places 24 beside P-17, 18 beside P-19, and not supplied where the notes lack a number. Mira and Arun point to each number in the fixture. They reject a sentence calling P-19 "the strongest evidence" because the notes do not support that ranking. Mira removes it rather than pretending the run was perfect.

At minute 15 Arun takes the keyboard. He asks the assistant to add a reason to open full text column without changing any facts. They verify the revised table again. At minute 22 he raises the fabrication objection, and the rejected ranking gives Mira an honest example of the checking routine.

At minute 28 Arun writes his first task in the same demo record: On 7 September, test the approved workspace on five public abstracts from the existing literature corpus; produce a source-ID table with sample count, method comparison, and missing-evidence flags; verify every row against the abstract before showing it at group meeting. The demo ends at minute 30. It passes because Arun typed, the visible checks were performed, and the written task is specific and safe.

Company framing: turn status notes into a weekly report

Jonas asks Leila for an equivalent repetitive task. She chooses converting supplier-status notes into the weekly operations table. Jonas uses a parallel synthetic fixture:

[S-17] Cedar Supply: 24 units received; inspection A and B planned; limitations
not stated in the note; inspection record still to check.
[S-18] Harbor Supply: background account; no new delivery; useful context on
inspection B; status updated 2024.
[S-19] Northwind Supply: 18 units received; inspection B took less time; exact
duration is not present in these notes; inspection record still to check.
Meeting question: Which supplier record should we inspect first for comparison?

Leila explains that she currently copies supplier, delivery type, unit count, relevance, and missing evidence into a report table. Jonas uses the same checks: four rows or fewer, traceable numbers, no invented duration, and visible gaps. He changes only the domain words in the prompt: reading notes becomes supplier-status notes, source ID becomes supplier ID, and the assistant must not recommend approval or claim which inspection is better.

The assistant extracts 24 and 18, marks absent details not supplied, and adds an unsupported claim that S-19 is the lowest-risk supplier. Jonas and Leila locate the failure and delete the claim. Leila then types the same follow-up request for a reason to open the inspection record column. They check that the new column contains only reasons grounded in the fixture.

At minute 28 Leila writes: On 7 September, test the approved workspace on five synthetic supplier notes; produce a supplier-ID table with unit count, inspection comparison, and missing-evidence flags; verify every row before using the pattern for a weekly internal report. Her trial does not include a live contract or supplier record. The sequence, timing, checks, and evidence match the Lab version; only the task vocabulary and stakes differ.

Answer the three objections directly

"It makes things up." Yes, it can produce unsupported content. Show the failure, apply the T01-L02 checking routine, and restrict the first task to an output the colleague can verify. Do not answer with "the latest model is better."

"It will replace us." Do not deny the concern or promise an employment outcome you cannot control. State what this demonstration changes: the assistant drafts a bounded table; the colleague chooses the task, checks evidence, makes the decision, and owns what is shared. Ask which part of the proposed use feels threatening or inappropriate, record it, and do not pressure the person into a trial.

"We are not allowed." Find out before using real material. Show the approved tool and permitted data boundary if one exists. If no clear rule exists, stop at synthetic data and route the gap to T13-L03 · Your AI usage policy. Uncertainty is not permission.

7. What goes wrong

You demonstrate your workflow, not theirs

Symptom: the result is impressive, but the colleague cannot name where it fits in their week.

Fix: ask about one repeated task before preparing the session. Use their input shape, review standard, and destination.

Slides consume the live time

Symptom: fifteen minutes pass before anyone sees a source or touches the keyboard.

Fix: use one sentence for the purpose, show the raw input, and begin. Keep the fixture, prompt, checks, and timer on screen instead of presenting a deck.

The first live run is the rehearsal

Symptom: login prompts, permissions, display problems, or an oversized input consume the slot.

Fix: rehearse the exact run once, confirm the approved account, and keep a safe local fixture plus a manual before-and-after fallback.

Overselling costs the room

Symptom: you describe an unchecked draft as accurate, automatic, or guaranteed to save time.

Fix: state the narrow observed result and the checking cost. Show a failure when one occurs. Let the colleague decide whether the trade is worthwhile.

The objection becomes a debate

Symptom: you try to win a general argument about truth, jobs, or policy while the colleague's actual concern goes unanswered.

Fix: acknowledge the concern, answer only what the demonstration establishes, record unresolved questions, and route policy or employment decisions to the responsible person.

Nobody owns a next action

Symptom: the session ends with "interesting" but no task, date, input, or check.

Fix: reserve the final two minutes for the colleague to write one small permitted trial in their own words. No written task means the adoption outcome was not met.

8. Do it yourself: prepare, run, and capture in 60 minutes

Minutes 0-8: ask one real colleague for a boring repeated task they perform or review. Define a small result they can judge. Write the success bar: demo finishes within 30 minutes, the colleague types once, the result receives visible checks, and the colleague writes a first task.

Minutes 8-15: create a short synthetic, public, or explicitly approved fixture. Write one bounded prompt and three or four checks. Remove real names, identifiers, secrets, unpublished findings, confidential terms, and consequential decisions.

Minutes 15-23: rehearse once with the exact account and display. Time the live transformation. If it takes more than ten minutes, reduce the fixture or result. Prepare a manual fallback that honestly shows the planned before-and-after without pretending to be a live run.

Minutes 23-25: open the fixture, prompt, timer, and demo record. Close unrelated tabs and notifications. Confirm that screen sharing exposes no sensitive material.

Minutes 25-55: run the 30-minute session: purpose and current method in minutes 0-5; live before-and-after in minutes 5-15; visible source check and colleague's turn in minutes 15-22; objections in minutes 22-28; written first task in minutes 28-30. Record actual times and observed results, not a reconstructed ideal.

Minutes 55-60: finish the same demo record. Mark each success criterion pass or fail. If the colleague declines a first task, record that honestly; do not write one for them. Remove accidental personal or confidential details before storing the record in an approved location.

9. Exit check

Deliver exactly one artifact: one completed demo record for a session run with a real colleague. It contains the colleague's role or non-identifying label; date; approved tool and data class; task demonstrated; planned and actual start/finish times; before state; checked after state; pass/fail for the colleague typing; the objection raised and your answer; and the colleague's written first task naming its input, output, safety boundary, verification step, and test date.

It passes when the session lasted no more than 30 minutes, the result was checked against the source, the colleague controlled at least one request, and their own written first task is specific enough to run. A polished demo without that written task does not pass. Store no sensitive source content in the record.

10. Rule to remember

Their task, live, timed.

11. Further reading & tools

• Taught: T01-L02 · Trust but verify - supplies the visible checking routine for the live result.
• Taught: T02-L02 · Your daily driver - establishes bounded workspaces, approved inputs, source files, and context controls.
• Taught: T12-L01 · What you may and may not paste - classifies the demonstration fixture before it enters a service.
• Taught: T13-L03 · Your AI usage policy - handles the missing-rule problem surfaced by the session.
• Catalogued: NIST AI RMF Playbook (opens in a new tab) - optional risk-management actions; it does not approve a tool or replace local policy.
• Catalogued: Tools index - compare available services only after confirming organisational approval, account controls, and permitted data.