Chapters 5 to 8 describe where each role should be. This chapter is about how people get there. An enablement program is the work of turning approved tools and guardrails into daily practice: learning paths, workshops, labs, coaching, and the change management around them. Counts and durations on this page are illustrative.
The program does not replace governance. It runs inside it: every lab uses an approved tool, every hackathon uses synthetic or approved data, and every artifact an agent produces still goes to a human with the existing authority to approve it.
1. Four phases, one team at a time
The program moves each team through four phases. A phase is a state of the team, not a date on a calendar. Two teams in the same department can sit in different phases, and that is normal.
| Phase | Goal | Activities | Evidence to move on |
|---|---|---|---|
| Awareness | Everyone knows what is approved, what is prohibited, and why | Leader briefing; acceptable-use walk-through; one demo on the team's own work; intake explained | Acceptable use attested and scenario-checked; every member knows the escalation path; first use cases on the intake card |
| Experimentation | People try approved tools on low-risk tasks and learn the limits | Hands-on labs; office hours; personal productivity tasks (Stage 1); near-miss reporting switched on | Eligible users active; first net-time-saved sample including review time; no unreported policy breaches |
| Implementation | The team builds shared context and bounded tasks into its workflow | Build-along sessions; team instructions file reviewed like code; reusable prompts; first evaluation set; reuse advisory hook | Reuse, extend or create decisions recorded; evaluation set with thresholds for each delegated task; reviewer capacity confirmed |
| Adoption | The new way is the normal way, and the team improves it | Demo day; champions inside the team; contributions to the asset catalog; periodic review | Use is sustained after coaching ends; the team contributes at least one asset or pattern; regressions are caught before release |
Phases and stages. The phases describe the team's learning. The ladder stages (chapter 5) describe what AI is allowed to do. A team can be in the adoption phase for Stage 2 work and in experimentation for Stage 3 work at the same time.
Stepping back. A team goes back a phase when the ladder says it steps down: a model or provider change, a failed evaluation, an incident, or a material change in the use case.
2. Learning paths per role
A learning path is an ordered set of modules for one role. Each level ends with a piece of work the person shows, not a quiz they pass. Foundation is required before anyone uses an approved tool on proprietary data.
| Role | Foundation | Practitioner | Advanced |
|---|---|---|---|
| Product owner (PO) | Acceptable use; data classification; what AI can and cannot do; the intake card | Drafting an outcome statement and a value case with AI; reviewing AI-drafted stories for meaning | Writing a leader decision brief; sponsoring a use case through risk review |
| Business analyst (BA) | Acceptable use; data classification; spotting fabricated facts in a draft | Reusable prompt for story drafting (Lab 2); acceptance criteria with negative cases | Building an evaluation set for story quality; owning a team prompt in the catalog |
| Developer | Acceptable use; secrets and protected paths; reviewing AI output as your own code | Team instructions file (Lab 1); reuse-first hook and decision record (Lab 3) | Delegated task behind an approval gate (Lab 5); writing hook specifications; tool-access boundaries |
| QA (quality assurance) engineer | Acceptable use; why generated tests can pass for the wrong reason | Test generation with an evaluation set (Lab 4); negative test cases | Evaluation by risk slice; regression detection after a model change |
| Release manager | Acceptable use; how AI-assisted changes appear in the change record | AI-drafted release notes reviewed against the change record | Evidence checks for delegated and agentic work; rollback and kill-switch drills |
| Risk and control partners | Acceptable use; the two axes; the control crosswalk | Reading traces and evaluation reports; reviewing an intake card | Independent validation of a high-tier use case; periodic review design |
3. Workshop formats
A workshop is a scheduled session with a stated outcome. Pick the format by the audience and the outcome, not by habit. Business means product, operations and control partners; technical means developers, QA and platform engineers.
| Format | Audience | Length | Outcome |
|---|---|---|---|
| Leader briefing | Business; senior leaders | 45 minutes | Leaders understand the two axes, the first use cases, and the decisions they will be asked to make |
| Hands-on lab | Technical or business, by lab | 90 minutes | Each person finishes one lab exercise on an approved tool and leaves with a working artifact |
| Build-along | Technical; one team | 2 hours | The team builds a real piece of its own context (instructions file, prompt, hook) together, with the enablement lead driving |
| Demo day | Mixed | 60 minutes | Teams show working results with their evidence: time saved, evaluation results, what failed |
| Hackathon | Mixed teams | 1 to 2 days | Prototypes of intake-approved ideas, each with an intake card and a next-step decision |
| Office hours | Anyone | 1 hour weekly | Unblocked people; questions turned into catalog entries, glossary terms or policy clarifications |
| Champions network | One volunteer per team | 30 minutes every two weeks | Shared patterns across teams; early warning of friction; local support between sessions |
Hackathon rules. A hackathon in a regulated organization needs written rules before the first day.
| Rule | Why |
|---|---|
| Approved tools only | A hackathon is not a back door for an unapproved vendor |
| Synthetic or approved data | No customer data, no restricted data, no production credentials |
| Sandbox environment | Nothing connects to production systems or sends real messages |
| Intake card per idea | Every prototype gets a risk tier before it gets a demo slot |
| No production path by default | A winning prototype enters normal intake; winning is not approval |
| Prohibited stays prohibited | Ideas in the prohibited tier are not built, even as a demo |
Champions network. A champions network is a group of volunteers, one per team, who help their peers between sessions. Champions need protected time (for example, 10% of their week, illustrative) and recognition, or the network fades after the first quarter. A community of practice is the wider, open group where champions and anyone else share patterns.
4. The coaching cycle
Workshops teach. Coaching makes it stick on the team's own work. The coaching cycle has four steps, and the enablement lead does less at each one.
| Step | What the team does | What the enablement lead does | Done when |
|---|---|---|---|
| Explore | Picks one real task from its backlog; writes the intake card; sets a baseline | Helps pick a low or medium tier task; checks the data classification; asks how the task is measured today | Task chosen, tier recorded, baseline written down |
| Build and test | Builds the prompt, instructions or hook; tries it on real but approved inputs; writes negative test cases | Pairs on the first attempt; shows how to read the output critically; points to existing catalog assets | The artifact works on the evaluation set, including negative cases |
| Refine | Measures net time saved including review and rework; fixes what reviewers reject | Reviews the evidence with the team; challenges optimistic numbers; checks reviewer load | Results meet the threshold, or the team records why the task is not a fit |
| Embed | Adds the artifact to the team's workflow and the catalog; names an owner | Steps back; checks in after a few weeks; captures the pattern for other teams | Use continues without the lead; the asset has an owner and a review date |
A failed fit is a result. Some tasks do not improve with AI. Recording "not a fit, because" in the catalog saves the next team the same experiment.
5. Change management
Tools change in a day. Habits change over months. Change management is the planned work of helping people through that, and it fails most often when leaders treat resistance as a training problem.
| Lever | What works | What fails |
|---|---|---|
| Communication | Say what is approved, what is prohibited, and why, in one page; repeat it in team meetings; publish what changed and when | One launch email; policy in a long document nobody reads; silence after an incident |
| Resistance, real causes | Ask what the resistance is about before answering it; treat each cause separately (see below) | Calling it "fear of change"; more training for a problem training does not fix |
| Incentives | Count review, evaluation and catalog work as real work; include it in goals | Rewarding seat counts or prompt counts; punishing a team whose honest numbers look worse |
| Leaders modelling use | Leaders use approved tools for their own drafting and say so; they ask for evidence, not adoption percentages | Leaders mandating use they do not practise; leaders exempting themselves from the rules |
| Recognition | Demo day credit for useful failures and reused assets; champions named in team updates | Recognizing only the biggest time-saving claim |
| Real cause of resistance | What it sounds like | A useful response |
|---|---|---|
| Job fear | "If this works, what happens to my role?" | Leaders state plainly how roles will change and how time saved will be used; never promise what they cannot keep |
| Accountability fear | "I sign the change; I cannot check what the agent did" | Show the trace, the evaluation set and the approval gate; keep separation of duties visible |
| Quality concern | "It produces confident wrong answers" | Agree: show abstention, evaluation and the reviewer step; measure override rate openly |
| Workload | "Learning this is on top of my real work" | Protected learning time; start with a task that already hurts |
| Past failure | "We tried a pilot last year and nothing happened" | Show the path from pilot to production and who owns each gate |
6. The first 90 days of an enablement lead
The enablement lead is the person accountable for the program. The first 90 days (illustrative) are about earning trust from both delivery teams and control partners before scaling anything.
| Days 1 to 30 · Listen and map | Days 31 to 60 · Prove with one team | Days 61 to 90 · Make it repeatable | |
|---|---|---|---|
| Goal | Understand the current state and the people who decide | One team moves one phase with honest evidence | A program other teams can join without the lead in the room |
| With delivery teams | Process walks with 3 to 5 teams; collect pain points and current tool use, including unapproved use | Build-along and coaching cycle with one pilot team on one medium-tier task | Learning paths published; champions named; office hours running |
| With control partners | Meet risk, security, privacy, compliance and audit; learn their concerns and evidence needs | Walk them through the pilot's intake card, trace and evaluation set | Agree a repeatable intake and review path with named owners and turnaround times |
| Artifacts | Current-state map; AI inventory gaps; stakeholder list | Pilot baseline and results; first reuse decision records; first catalog entries | Scorecard (chapter 10); program plan; first leader decision brief |
| Watch for | Promising outcomes before you know the baseline | Picking a showcase task instead of a real one | Scaling before reviewer capacity exists |
7. The leader decision brief
Leaders approve funding, scope and risk acceptance. The leader decision brief is the one-page document that asks for one decision. It states the trade-offs plainly, including what remains risky after controls.
| Section | What it contains | Due-date example |
|---|---|---|
| Decision requested | One sentence; who decides; by when | Approve Stage 3 delegated test generation for the four services that display the due date |
| Options | Two or three real options, including "do nothing" and a non-AI option | A: keep manual tests · B: delegated test generation behind an approval gate · C: move the three wrong implementations onto shared-datetime, no AI step |
| Value | Expected benefit with baseline, measure and comparison period | Fewer escaped date defects; net time saved per change, measured over two releases |
| Cost | Licences, platform, people time, review time, evaluation upkeep | Reviewer time per generated suite; evaluation set maintenance each quarter |
| Residual risk | What can still go wrong after controls, and who carries it | Generated tests could miss a time-zone edge case the evaluation set does not cover; QA lead owns the gap list |
| Recommendation | The option the lead recommends and why | B, with C done first: adopt shared-datetime and the temporal-domain contract, then generate tests against them |
| Expiry | When the decision lapses or must be reviewed | Review after two releases, or at once if the model or provider changes |
The brief asks for a decision, not for enthusiasm. A leader who reads it should be able to say no for a good reason.