Section 1
The three capabilities that actually transfer
Prompt tricks age badly. Three underlying skills do not, and they are what a training programme should build. Specification. Describing a task precisely enough that its output can be judged. This is the skill that separates people who get useful output from people who get plausible output, and it is the same skill that makes a good brief for a contractor. Verification. Knowing how to check work you did not do. What does a wrong answer look like here, which part is most likely to be wrong, what is the cheapest way to confirm it. Most people have never been taught this explicitly. Escalation judgment. Knowing which cases should never be handled by the system, and being willing to say so under time pressure. This is the skill that most protects the company, and it is the one most easily eroded by targets that reward throughput.
Section 2
Train the workflow owner, not the volunteer
The natural instinct is to train whoever is most excited. The better choice is whoever owns the process end to end, because they know the exceptions, the workarounds, and the reasons the documented process is not the real process. Work in pairs where you can: the person who knows the workflow and the person who is comfortable with the tools. Neither one alone produces a design that survives contact with a real week. Then give the time back. The most common reason internal enablement fails is that people are asked to learn a new way of working on top of a full workload. If the change is worth making, the hours have to come from somewhere visible, and saying so protects the programme when results are slow in the first month.
Section 3
What changes about the shape of the team
Two effects show up early and are worth planning for honestly. The junior rung thins. A lot of entry level work is exactly the checkable, high volume work that automates first. If you do nothing, you keep hiring seniors and lose the pipeline that produced them. The response is to redesign junior roles around review, exception handling, and customer contact rather than production, which means juniors need judgment sooner than they used to. Seniors become reviewers whether you plan it or not. That is a different job with a different failure mode: fatigue. A person checking a high volume of plausible output degrades quickly. Cap review volume, rotate it, and sample deliberately rather than asking anyone to check everything. The wider labour question is covered in [AI Automation and Job Displacement: What Founders Should Know](/blog/ai-automation-and-job-displacement-what-founders-should-know), and the skills path in [Preparing for the Future: Reskilling for the Age of AI Automation](/blog/preparing-for-the-future-reskilling-for-the-age-of-ai-automation).
Section 4
A sequence that works
Start with one workflow the team already complains about. Complaints are free evidence of where the friction is real rather than theoretical. Baseline it before touching anything: how long it takes, how often it goes wrong, what the rework costs. Without this you will not be able to tell whether the change worked, and you will be arguing about it from opinion. Redesign the workflow on paper, including the review step and the exception route, then build the smallest version that runs end to end. Run it in parallel with the manual process for a cycle. Then teach the rest of the team using that live workflow as the material, not a generic course. Repeat with the second workflow. Capability compounds across workflows in a way that licence counts never do.
Section 5
Oversight and the honest conversation
NIST frames AI risk management around trustworthiness, design, evaluation, and use, and the people side of that is mostly about who is allowed to decide what. Be explicit about which decisions the team must not delegate to a tool, what may never go into a prompt, and who signs off before something reaches a customer. Have the direct conversation about jobs early. People assume the worst in an information vacuum, and the assumption itself changes behaviour: quiet non-adoption, withheld knowledge about exceptions, defensive documentation. Saying what you know, including that some things are undecided, buys more cooperation than a reassuring statement that later turns out to be false.
Section 6
Measure capability, not usage
Seat activation and message counts tell you almost nothing. Measure whether the work changed: cycle time on the redesigned workflow, rework rate, exception volume, the share of outputs a reviewer alters, and how many people can run it without help. One test beats a dashboard. Ask someone who was not involved in the build to run the workflow cold. If they can, the capability lives in the team. If they cannot, it lives in one person, and you have a single point of failure rather than a trained organisation. You are ready to expand a programme if one workflow has a measured before and after, a second owner, and a documented exception path. You are not ready if the evidence is enthusiasm and a licence count. On communicating the change internally, [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation) is the companion piece.