Building Capability, Not Just Rolling Out Tools

The standard training plan for a new tool is a launch session, a link to a resource hub, and maybe a champions network. We did a version of this across our programme and delivered nearly two thousand training attendances. What became clear very quickly is that most people settled into using the tool the way they used to use a search engine, asking it simple questions and getting simple answers, while the features that would actually deliver the business case sat untouched further up the capability curve.

Access without structured progression leaves people stuck at the surface, and the gap between what the tool can do and what your people actually do with it is where the promised benefit quietly dies. The fix isn't more training. It's different training: structured around a defined climb through the tool's feature set, targeted at each person's current level, and designed to capture data as people move.

Mapping features to maturity

Every tool with a wide feature set has a stair-stepped one. Single prompts come before reusable prompts. Reusable prompts come before agents working against curated documents. Personal builds come before team builds. The steps exist whether or not anyone names them, and naming them matters because it turns an implicit progression into a curriculum people can follow. Deriving those levels from your own tooling is covered separately. The point here is that once the levels are defined, training changes character. Someone at single-use prompting learns to build a reusable prompt and hears nothing about orchestration, because that's four levels above them and teaching it now adds noise without building capability. Everyone gets a next step that's visible and worth taking.

Judgement, not just features

But features are only half of what people need. The other half is judgement, meaning frameworks for developing and evaluating their own ideas: is this repetitive task actually worth automating, is the output safe to rely on, and what does good enough to share with my team look like? These frameworks need to grow with the person. Early on they can be simple prompts for self-reflection. By the time someone is building solutions for their team, the frameworks carry real weight, covering control over reference documents, a testing discipline before anything gets shared, and a clear line on what the build must never do. Features without judgement produces users with shortcuts. Features with judgement produces builders.

Training as a diagnostic

The part that makes this more than a training programme is the capture. As people learn and progress, recording where they sit against the maturity levels creates a live map of the organisation's capability. Not surveillance, not box-ticking, but evidence of where people are, what they're ready to build, and where the gaps sit. Without this data you're making decisions about what to pilot and where to invest based on assumption.

That data serves two purposes. It shows where your most capable people are clustering and what they should be building next, because a team with several people at level four should be scoping team-level solutions and somebody should be directing them towards it. Compared against organisational readiness, the same data also shows where to place the next pilot safely, because the departments where people cluster above the baseline are the ones mature enough to carry a test of the next set of controls.

It works in the other direction too. Wherever people sit below the feature set available to them, you have a specific, evidenced training need, and the next piece of training more or less designs itself from the gap.

Most organisations treat training as a rollout cost, a line item to get people over the adoption hump that gets done once and then cut. Structured this way, the training is the curriculum, the climb through it builds the capability, and the data thrown off by the climb is a continuous read on where the organisation is and where it can safely go next.