Sabie Systems spent most of last year's training budget on AI courses. Developers took a coding-assistant course, the data team took a vendor's machine learning learning path, and about thirty people collected a fundamentals certificate from a cloud provider. Completion rates were excellent. When the head of engineering asked team leads what had changed in the work, the answers were vague. A few people used the coding assistant more. Nobody could point to a test set, a runbook or a specification that was better because of the training.
That outcome is common, and it is not the fault of the courses. A tool course teaches how to use the tool. It cannot teach a tester which risks matter in Sabie's billing system, or an analyst how to write an acceptance criterion an agent will implement correctly. Those are skills tied to the verbs a role performs and the work products it owes, which is what this series has been building towards.
CloudNala's view is that a learning path should be organised by the verbs a role is hired for and should end in a work product on real work, accepted by a practitioner. Tool courses and certifications are useful inputs. They are not the path, and they are not the finish line.
Part 1 decoded AI roles into six verbs. Part 2 applied that to existing roles and the evidence they now owe. This part turns both into learning paths.
Sabie Systems is fictional, and its systems and figures are illustrative. Sabie is a Pretoria software and data services company of about 140 people. For this plan it chose a first cohort of twenty: developers, testers, two analysts, an architect and three people from operations.
A tool course teaches the button, not the decision
The AI literacy article explains why a prompting workshop plateaus. The same thing happens with tool courses, for a specific reason: they are designed to be useful to every customer of the tool, so they cannot use your systems, your data, your risks or your standards.
That leaves a gap between "I know how the tool works" and "I can produce the work product my role owes, using the tool, on our systems, to our standard". The gap is where most of the value is, and it can only be closed on real work with someone reviewing the result.
There is a second problem. Tools change on a cycle of months. A path built around one tool's features needs rewriting every time the tool changes, and people trained on the old version carry habits that no longer fit. A path built around verbs and work products changes far more slowly. The tool becomes one of the things you learn along the way.
One shared foundation, four paths
The two-layer idea itself, shared foundations with role-specific depth on top, is set out in the AI literacy article and is not repeated here. What this part adds is a way to group the top layer by verb rather than by job title, and a hard finish line for each path. Sabie's structure has a short foundation that everyone takes, then four paths grouped by verb family. Each person follows the path for the verbs their role profile lists as core.
The foundation is the same for everyone, including managers. It covers four things: how language models and agents fail (confident wrong answers, missing context, tool calls that fail silently); how to handle data with AI services, including which data may go where, which the traffic-light article explains in plain language; the habit of verifying output before relying on it; and how to read a specification. The foundation is short. Sabie runs it in four half-day sessions, each built around examples from its own products.
Frame and explain. For analysts, product owners, architects and anyone who leads work. Learning covers problem statements, acceptance criteria, decision records, and explaining trade-offs to non-technical decision-makers. Practice is on a real incoming request. The path ends in a one-page brief for that request that a delivery team, or an agent, could build from.
Build and integrate. For developers and engineers. Learning covers structured contracts with models, tool definitions, permissions, failure handling and working with coding agents inside team standards. Practice is on a real backlog item. The path ends in a merged change, with the review record that Part 2 described.
Evaluate. For testers, quality engineers and anyone who will own whether an AI feature is right. Learning covers test sets drawn from real cases, rubrics, comparing a model's judgement with a human's, and reporting failures usefully. Practice is on a live AI feature. The path ends in an evaluation report that the product owner can act on.
Operate and govern. For operations, platform and risk roles. Learning covers traces, cost and usage monitoring, incident handling for AI features, and mapping policies to controls and evidence. Practice is on a real or replayed incident. The path ends in an updated runbook or control record.
Many people will need more than one path over time. That is fine. The point is that each person starts with the path their role is hired for, and finishes it with something the organisation can use.
The work product is the finish line
The single most important design choice is that a path is complete when a practitioner accepts the work product, not when a course is finished. The reviewer is someone who does that work for real, not the trainer.
This changes behaviour in useful ways. Learners pick real work because the work product has to be real. Reviewers see early whether the learning is landing. Gaps show up as specific comments on a specific artefact, rather than as a vague feeling that training "did not stick". The work-products article in the capability series describes a ladder of evidence and a production capstone; the paths here feed directly into that.
It also makes the training budget defensible. "Twenty people completed courses" is an activity count. "Fourteen accepted work products, including three evaluation reports that found real defects" is a result someone can check.
Where certifications fit
Vendor certifications are not useless. For build, integrate and operate roles on a specific platform, a current certification can be a reasonable way to learn that platform's services and to show a client that someone has done so. Some public-sector and enterprise tenders also ask for them.
Three cautions apply.
They are volatile. Cloud and AI providers revise, rename and retire their AI exams frequently. Before paying for one, check the exam's current objectives and retirement dates on the provider's own certification pages on the day you decide, not from a list someone shared last year.
They measure knowledge of the platform, not your work. A certificate says someone passed an exam about a provider's services. It does not say they can produce your work products on your systems.
They should not be ranked as outcomes. Counting certificates per head is easy and says little about capability. Sabie keeps certifications as an optional step inside the build, integrate and operate paths, funded when a role or a client needs that specific platform, and never as the measure of whether the path is complete.
A 90-day plan
Sabie ran its first cohort over ninety days in three blocks. The plan is deliberately plain.
Days 1 to 30. Everyone takes the foundation. Each person and their manager agree the role profile from Part 2, choose a path, and pick the piece of real work they will use. A reviewer is named for each person. By day 30, everyone knows exactly what work product they are aiming for.
Days 31 to 60. Path learning, mixed with practice on the chosen real work. Sabie pairs learners where it can, for the reasons the delivery-system training article gives for training adjacent roles together: an analyst on the frame path works with a developer on the build path on the same backlog item, which teaches both of them how their work products fit together. By day 60, each person has a draft.
Days 61 to 90. Practitioner review, rework and a short record of what was learned and what was still missing. Gaps go into the next cohort's design.
The plan costs mostly people's time, which is the honest cost of any capability that matters. Sabie set aside about four hours a week per learner, protected in the team's sprint planning.
Keep the paths current
Paths built on verbs change slowly, but their content still needs care. Sabie reviews each path every quarter, as part of the curriculum loop described in the maturity article. Reviewers bring the common weaknesses they saw in work products, team standards bring changes to the toolchain, and the path content changes to match. Nothing is added to a path unless a reviewer has seen people struggle with it on real work.
Start this week
- List what you spent on AI training in the last year and what each item produced. Separate activity (courses, certificates) from work products.
- Pick one team and one path. Name a practitioner reviewer and one real piece of work for each learner.
- Write down the work product that ends the path before anyone starts learning. If you cannot describe it, the path is not ready.
Next: Part 4, Hire on evidence: interviewing for AI-era roles. All parts are on the series page.
How CloudNala can help
CloudNala designs AI learning paths around the roles you have and the work products they owe. We help you define the foundation, choose paths per role, select real work for practice, and set up practitioner review, so that training spend turns into evidence you can inspect. We are independent of training vendors and certification programmes, and we will tell you when a certification is worth it and when it is not.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Capability Planning Session or write to us at consult@cloudnala.co.za