Building Organisational AI Engineering Capability
Most organisations answered AI tools with licences and a prompting workshop. Usage rose and delivery barely moved. This eight-part series sets out the organisational path: shared foundations for every role with depth where the work needs it, training the whole delivery system rather than only developers, specification literacy, the move from personal tools to a governed toolchain, an internal MCP registry that records ownership, a guild that produces standards, capability measured through work products, and four maturity levels with a curriculum that keeps pace. One fictional South African insurer's group IT function carries the examples, and every figure is illustrative.
8 articles
- Part 1AI literacy is not a prompting workshopMost organisations answered the arrival of AI tools with a prompting workshop and a licence purchase. Usage went up and delivery barely moved. Part 1 sets out what organisational AI engineering capability actually is: shared foundations for every role, depth where the work needs it, and evidence in the work itself.8 min read
- Part 2Train the delivery system, not only the developerWhen coding assistants arrived, training went to developers because that is where the tools landed first. The result is predictable: code gets faster and the bottleneck moves to review, testing and release. Part 2 explains how to train the whole path a change travels, stage by stage.6 min read
- Part 3What every role needs to know about specificationsWhen agents implement from specifications, a vague requirement is no longer smoothed over by a developer who knows the business. It is implemented exactly as written. Part 3 sets out what analysts, architects, engineers, testers, designers and leaders each need to know about specifications, and why nobody is exempt.6 min read
- Part 4From personal AI tools to a governed team toolchainPersonal AI tools spread because they are fast and nobody has to ask permission. That same property makes them invisible to security, cost and quality controls. Part 4 sets out four steps from personal tools to a governed toolchain, and why the goal is a safe default rather than a longer policy.6 min read
- Part 5Why an internal MCP registry needs ownershipAn internal MCP registry is usually introduced as a catalogue so teams can find servers. Its real job is ownership: who runs each server, what it can reach, which data passes through it and what happens when its owner leaves. Part 5 covers the registry entry, the lifecycle and the orphaned state most registries forget.6 min read
- Part 6The AI guild must produce standards, not just enthusiasmMost organisations have an AI community of practice. Many of them meet regularly, share demonstrations and generate goodwill, and change very little about how the next team works. Part 6 sets out what a guild should produce instead: versioned standards, reference implementations and platform defaults, each with an owner and a review date.6 min read
- Part 7Measure AI capability through work productsAttendance and certificates are easy to count and say little about whether a team can deliver safely with agents. Part 7 sets out a ladder of evidence, a capstone built around a real production change, and the small set of work-product measures that show whether capability is growing.6 min read
- Part 8Four levels of AI engineering maturity, and a curriculum that keeps upMaturity models are easy to draw and hard to use. Part 8 offers four levels of AI engineering maturity, each recognised by a signal you can observe in the work, and a quarterly loop that keeps the curriculum and standards as current as the toolchain they describe.6 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala