Digital Literacy Programmes That Scale
Training · 2 min read
Digital literacy programmes fail when they treat every employee as the same learner. The ones that scale are tiered by role, anchored in the work people actually do, and sustained by a community of practice rather than a single launch event.
Tier the curriculum by role
A single all-staff session produces familiarity, not capability. Literacy is better designed as a set of tiers, each with a defined audience and a defined outcome. The foundational tier covers what the tools are, how to ask a useful question, how to read an output critically, and where the boundaries of acceptable use lie. Everyone completes it, including people who will never build anything themselves.
Above that sits role-specific practice: the finance analyst querying spend, the service manager summarising a case history, the production supervisor interpreting a fault signal, the buyer comparing supplier documentation. Each is a task the person already performs, now assisted. A third tier serves the people who sign off on machine-influenced work; they need judgement rather than tool skills. A fourth, smaller tier serves those who configure and maintain systems, and is usually the easiest to source externally.
Anchor learning in the work, then keep it alive
Sandbox environments seeded with the organisation's own non-sensitive material teach far more than generic examples. Office hours make room for the awkward, specific questions a formal course never reaches. A community of practice — a standing channel, a regular clinic, a shared record of what worked — stops capability from evaporating when the launch cohort disperses.
Sequence matters. Begin with the roles whose work will change soonest and most, because early wins make the next tier easier to justify. A short baseline exercise, taken before any training, tells you where the gaps actually are rather than where you assume them to be; the results let you place people by capability instead of by job title.
- Make managers release the time — literacy competes with the day job, and the day job wins unless the hours are agreed in advance.
- Measure capability, not attendance — the useful signal is whether a person can complete a real task unaided, not how many sessions they sat through.
- Record what is learned — a short, searchable note on each new workflow turns individual discovery into organisational knowledge.
Rule of thumb: if a programme cannot name the specific tasks each role will do differently, it is awareness training rather than literacy training — useful, but not the same thing.
Questions to ask
- Which roles will change their daily work first, and what exactly will they do differently?
- Who owns the curriculum once the launch cohort has finished?
- How will we know that a person can judge an output, rather than merely produce one?
- Where does newly acquired capability get recorded, so that it survives staff turnover?
Assessing Change Readiness
Method · 2 min read
Readiness is not enthusiasm. It is the presence of the conditions that let a change survive contact with daily operations: clear sponsorship, available capacity, an honest history, and a workforce that trusts the process it is being asked to join.
Read the signals, not the mood
Sentiment is a poor predictor of whether an initiative will hold. The signals that matter are structural. Can a sponsor reallocate budget and time, or only give speeches? Can a middle manager describe the change in their team's own terms, or do they repeat the corporate script? Is the data the change depends on already reachable by the people who need it? Does disagreement surface early, in the room, or quietly afterwards in the corridor?
Past experience is part of the reading. An organisation that has launched three initiatives and quietly abandoned two will price the next one accordingly, whatever the slides say. Assessing readiness means taking that history seriously rather than treating it as pessimism to be managed.
- Sponsorship with teeth — leadership that moves resources and protects time, not merely endorses.
- Middle-manager translation — supervisors who can say what changes for their team, specifically.
- Evidence of past follow-through — a track record of finishing what was started.
- Permission to disagree — dissent raised early and answered, not deferred.
Assess at the level where the work happens
Readiness is not a single number for the organisation. A function may be ready while a particular team is not, and the two answers call for different responses. The board can be convinced and the shop floor exhausted, or the reverse. A useful assessment separates the levels — enterprise, function, team — and says plainly which one the change depends on most.
Blockers are rarely simple resistance. They are workload that leaves no room for learning, decision rights that are unclear, data a team cannot reach, and a reasonable fear that automation is a headcount announcement in disguise. Each is addressable if surfaced early, and corrosive if left to fester. A readiness assessment that does not let the workforce name these plainly is measuring politeness.
The useful output of an assessment is a short list of conditions to fix, each with a named owner, rather than a score to be reported upwards. A team is ready when the conditions that matter for its part of the change are genuinely in place, not when the average across the organisation looks acceptable.
Rule of thumb: a survey alone measures sentiment. Pair every survey with a handful of interviews and at least one walk-through of a real workflow.
Questions to ask
- Who can actually move budget and time behind this change, and have they?
- What happened to the last initiative we asked people to adopt?
- Which decisions become unclear once this change starts, and who resolves them?
- Where will we hear honest objections, and how will we respond to them?
Building an AI Champion Network
Org design · 3 min read
A champion network is not a fan club. It is a distributed layer of capability — people with a mandate, protected time, and a route to the centre — that turns a central team into something the whole organisation can actually reach.
What a champion actually does
Champions are most useful when their role is defined by function rather than by enthusiasm. They translate central guidance into the language of their own team. They surface real friction and edge cases back to the centre, which is otherwise blind to what happens on the floor. They run small, visible experiments in their own area, and they coach colleagues through a task rather than pointing at a manual.
- Translate — reframe general guidance as a workflow that fits this team.
- Surface — carry genuine problems and counter-examples back to the centre.
- Demonstrate — run a small experiment where the team can see it.
- Coach — sit with a colleague the first time they use a new tool.
Give it mechanics, not goodwill
Time allocation is the difference between a network and a mailing list. A champion needs named hours agreed with their line manager and visible in workload planning; if the role is expected on top of a full job, it is quietly dropped within a quarter. The mandate should be written: what the champion may decide alone, what they must escalate, and who answers when they escalate.
Recognition matters too, but it should be tied to the work rather than symbolic. A route into visible projects, a voice in design decisions, and credit for what they build will sustain a network far better than a badge. The centre's job is to keep the loop closed: when a champion surfaces a problem, something should visibly change.
Choose for reach, and keep the loop closed
Select champions for reach rather than rank. A respected supervisor who is trusted across two teams is worth more than a senior manager with no daily contact with the work. Look for people who already explain things well, who are asked for advice informally, and who will say when something is not working. One per team is usually enough; a network that covers every group but engages none is worse than a smaller one that meets regularly.
Keep the connection to the centre alive with a rhythm rather than a launch. A short standing meeting, a shared channel, and a rotating slot where champions present a problem or a result give the network a reason to exist between crises. The centre should also expect to change its own plans in response; a network that only ever receives instruction will stop volunteering information.
Rule of thumb: a champion network without protected time is a distribution list with better branding.
Questions to ask
- What may a champion decide, and what must they escalate?
- Whose budget carries the protected hours, and is it visible in workload plans?
- How does a problem surfaced by a champion reach someone who can act on it?
- What recognition is genuinely valued here, beyond a title?
Training Human Middleware Operators
Training · 3 min read
Human middleware are the people who stand between what a model produces and what the business decides: interpreters, judges, and escalation points. Their skill is not operating AI. It is knowing when, and how far, to trust it.
The judgement an operator needs
An operator who must judge model output needs four related capabilities. The first is reading confidence and uncertainty, distinguishing a fluent answer from a grounded one. The second is knowing the failure modes — the inputs a model handles poorly, the situations it cannot see, the questions where a plausible answer masks an empty one. The third is deciding thresholds: when to accept, when to check, when to pause and escalate. The fourth is feeding correction back so that an override becomes a durable improvement rather than a private fix.
- Calibrated trust — neither blind acceptance nor reflexive doubt.
- Failure-mode awareness — knowing where the system is weak and why.
- Clear thresholds — a stated rule for accepting, adjusting, or escalating.
- Disciplined feedback — recording the reason for a correction, not just the correction.
How to build it
Training of this kind is scenario-based and role-specific. Operators work through known cases where the correct answer is already established, so they can see where their judgement agrees with the model and where it diverges. Case reviews of near-misses are more instructive than abstract instruction: what did the model say, what did the operator do, and what would have happened if the operator had been absent? The goal is not technical mastery but calibrated trust, built through repetition on real material.
It helps to teach the habit of articulation. An operator who writes down why they overrode an output is practising the very judgement the role depends on, and leaves a trail the organisation can learn from. Interfaces that expose reasoning, rather than a single confident answer, give that judgement something to work with.
Support judgement in the interface and the escalation path
Training alone cannot carry a role that the surrounding system makes impossible. Operators need a clear route to a second opinion when they are unsure, and a named person who owns the final call when the stakes are high. The escalation path should be fast enough to use in the ordinary run of work, not reserved for emergencies.
Reviewing overrides over time shows where judgement and model disagree most often, and that pattern is itself a training asset. It also protects the operator: when a decision is questioned later, the recorded reasoning shows how the call was reached rather than leaving it to memory.
Rule of thumb: an operator is trained when they can explain not only what the model said, but why they chose to accept, adjust, or reject it.
Questions to ask
- Which decisions in this workflow require a human judgement, and which do not?
- Can the operator see enough of the model's reasoning to judge the answer?
- What is the agreed threshold for accepting, checking, or escalating?
- How does an override become a lasting improvement rather than a silent fix?
Fostering a Culture of Experimentation
Culture · 3 min read
A culture of experimentation is not a general tolerance for failure. It is a set of habits and permissions that let a small organisation test an idea cheaply, learn from the result, and change course without losing face.
Make experiments small and cheap
Most organisations do not have a lab, and they do not need one. Room for experimentation is made inside ordinary work: one workflow, one team, a fixed short window, and a stated decision the result is meant to inform. The smaller and cheaper the test, the more of them an organisation can afford, and the less each one has to justify its existence.
Culture is built by what leaders do with results, not by what the values statement says. When an experiment fails and the team is thanked for the finding, the next one is easier to start. When it fails and the team is quietly blamed, experimentation stops but the language around it does not, which is worse than never having encouraged it.
Separate the experiment from the decision
Before a test begins, write down what you expect, what you will measure, and what you will do under each plausible outcome. A result that is published either way becomes an asset; a result that is buried teaches people to hide the untidy ones. Separating the test from the decision also protects the people running it, because they are answerable for the method rather than for a predetermined answer.
- Time that is named, not borrowed — experimentation cannot run permanently on goodwill.
- A place to record — results, including failures, kept where the next team can find them.
- A named owner — someone accountable for running the test and reporting the outcome.
- A stopping rule — an agreed point at which the experiment ends and a decision is taken.
Make room in a small organisation
In a mid-sized organisation, nobody has spare capacity, so experimentation has to be carved out rather than added on. The most reliable way is to bound the test tightly: a fortnight, one team, one workflow, one measure. A test that can be run inside the ordinary week needs no special budget and no steering group, which is precisely what makes it possible to start.
Leaders set the price of failure more by their reaction to a specific result than by anything they announce. Closing a test down is a normal outcome, not a verdict on the people who ran it; the distinction is whether the decision is explained. Over time, an organisation that treats results as information rather than as evidence for or against a team will find that people bring problems forward earlier, when they are still cheap to fix.
Rule of thumb: if an experiment has no pre-agreed decision attached to it, it is a demonstration, not an experiment.
Questions to ask
- What decision will this test inform, and who will make it?
- What would have to be true for us to stop, scale, or reverse course?
- Where will the result be recorded so the next team can build on it?
- What happens here when an experiment fails — and does that match what we say we value?
← Back to Knowledge Bank