AI Leadership and Workforce Capability: A Practical Playbook
Last updated: 2026-08-14
You have a training budget and a mandate to raise AI capability. The default response is to buy a licence for an online platform, announce it, and report completion rates.
AI Leadership and Workforce Capability: A Practical Playbook
The decision this page helps you make
You have a training budget and a mandate to raise AI capability. The default response is to buy a licence for an online platform, announce it, and report completion rates.
Completion rates do not change behaviour. The decision worth making is narrower: which specific behaviours do you want changed, in which specific roles, and what evidence would show it happened. Everything else in this page follows from answering that.
Rules of thumb
1. Three audiences, three curricula. Those who decide, those who build, and those who use. They need different content, different formats, and different assessment. A single programme delivered to all three satisfies none of them and consumes the budget that could have served one properly.
2. Executives need practice refusing weak proposals, not architecture lectures. The capability a director actually requires is the ability to interrogate a business case: what decision changes, who owns the data, what happens when it is wrong, what does the operating year cost. Teach that through live proposals from their own organisation. Transformer internals are not the constraint on their decision quality.
3. Assess by artefact, not by attendance. Every programme produces something the participant made and can be evaluated: a completed use case assessment, a reviewed risk register entry, a working prototype, a rejected proposal with a written rationale. Attendance records tell you nothing about capability and everyone knows it.
4. Build internal faculty. External training does not compound. Identify practitioners who can teach, give them time in their objectives, and let them run sessions on your own systems and your own examples. Capability that lives in the organisation survives the end of the contract.
5. Teach on the organisation's real material. Generic exercises transfer poorly. Use your own use case backlog, your own data, your own vendor contracts, and your own failures. The session then produces both learning and work product, which is also how you justify the time.
6. Give people a legitimate sandbox before you write the policy. Restriction without a sanctioned alternative produces unmonitored personal account use. Provide an approved environment with logging and clear rules, make it easy to reach, and the policy becomes enforceable. This sequence matters more than the wording of the policy.
7. Name the roles that change, and say what happens to those people. Capability programmes stall on unspoken job security concerns. State plainly which roles change and what the organisation commits to for the people in them: redeployment, retraining, timeline. Ambiguity produces quiet resistance that no curriculum overcomes.
8. Make the first user cohort volunteers with real problems. Mandatory rollout to a reluctant population generates compliance behaviour and no advocacy. Start with people who came forward, help them succeed visibly, and let the second cohort arrive because the first one talked.
9. Teach failure modes and calibration, not prompt tricks. Prompt technique dates quickly and shifts with each model release. What lasts is knowing when the system is likely to be confidently wrong, how to verify an output cheaply, and when the task should not be delegated at all. Build the curriculum around judgement.
10. Put capability into job descriptions and objectives. Training that does not appear in what people are assessed on remains optional. Write the expected capability into role profiles and annual objectives for the affected roles. This is administratively tedious and it is the step that makes the programme durable.
11. Run cohorts, not enrolments. Fixed start dates, a defined group, and shared deadlines produce completion. Self-paced open enrolment produces high registration and low finish rates. The cohort also creates a peer network, which frequently outlasts the content.
12. Measure behaviour at ninety days. Ask what the participant has done differently since the programme, and require an example. Satisfaction scores taken on the last day measure the session. Behaviour at ninety days measures the investment.
The artefact: three-audience curriculum map
Audience 1: those who decide. Executives, directors, budget holders, governance body members.
- Format: three sessions of two hours, spaced two weeks apart, cohort of twelve to twenty
- Content: what these systems do and do not do reliably. How to read a business case. Consequence tiering and where accountability sits. Vendor questions worth asking. Cost of the operating year.
- Method: live proposals from their own portfolio, assessed in the room
- Artefact: each participant reviews one real proposal and produces a written decision with rationale
- Assessment: quality of the interrogation, not the conclusion
Audience 2: those who build. Data, engineering, analytics, and delivery staff.
- Format: extended cohort over eight to twelve weeks with project work
- Content: evaluation design, failure mode analysis, retrieval and grounding patterns, agent permission design, monitoring and drift, deployment path, secure integration
- Method: build against the organisation's own platform and standards
- Artefact: a working system passing the internal gate, or a documented decision not to proceed
- Assessment: peer and faculty review against the gate checklist
Audience 3: those who use. Everyone whose work the tools touch.
- Format: ninety minutes, role specific, plus an open office hour weekly
- Content: what the approved tools are, what may and may not be entered, how to verify an output, when not to delegate the task, how to report a problem
- Method: participants work on their own live tasks during the session
- Artefact: one task in their own workflow, completed and verified
- Assessment: self-reported at ninety days with an example
The artefact: executive session design
The three-session format that works, in detail.
Session one. What these systems do. Sixty minutes of demonstration on the organisation's own material, including two deliberate failures shown live. Forty minutes of discussion on where in their own portfolio the same failure would matter. Twenty minutes to identify one candidate use case each.
Session two. How to read a proposal. Participants bring their candidate. The group applies the four-axis scoring model and the readiness assessment. At least a third of the candidates should fail, and the session is working when participants reach that conclusion themselves.
Session three. What you are accountable for. Consequence tiering applied to their own systems. Stopping conditions drafted. Vendor question set applied to a real contract in the organisation. Each participant leaves with a written decision on their candidate and a named next action.
The artefact: capability evidence framework
For each affected role, complete this row. This is the document that turns a programme into a durable expectation.
| Role | Capability required | Evidence of capability | Where it is recorded | Reassessed |
|---|---|---|---|---|
| Example: service manager | Can assess whether a proposed system should be adopted in their service | Completed use case assessment reviewed by the CoE | Annual objectives | Yearly |
| Example: data engineer | Can design and run an evaluation against live-like data | System passing internal gate | Role profile and objectives | Yearly |
Failure signals
- The programme reports completion rates and cannot cite one changed behaviour.
- Executive sessions were delivered by a vendor using the vendor's examples.
- No participant has produced an artefact anyone reviewed.
- Staff use personal accounts because the approved environment is difficult to reach.
- The same enthusiasts attend everything and no new names appear in the second cohort.
- Capability appears in no job description and no objective.
- Internal faculty were identified and given no time allocation, so the sessions quietly stopped.
What this does not cover
This page covers capability building for organisations adopting AI. It does not cover formal academic curriculum design, accredited qualification pathways, or national skills policy. It also does not address the industrial relations dimension where role change is subject to consultation or collective agreement, which in many organisations must be settled before any of this can be announced.