AI upskilling that stays after the trainers go

AI upskilling is building your team’s ability to do its own work better with AI, and to keep doing so as the tools change. A one-off course rarely gets you there, because the tools it teaches change within months. Lasting capability is built inside your team, on real work, with time to experiment and share what works. When you decide where the budget goes, pay for outside help only if it leaves that capability behind.

Why a training day does not stick

AI training is in demand. We have heard of organisations spending six figures and more sending teams on courses about whichever tool is the hot topic: Cowork, Codex, Copilot, pick your month. The need is real: in a 2026 survey by Boston Consulting Group (BCG), 72% of respondents say expectations for the skills they need have shifted, but only 36% feel they have received adequate upskilling.

A course changes less than that budget suggests.

• The tools move faster than the syllabus. AI products change so fast that, in our view, most training is out of date within six months.
• The learning happens away from the work. A course can show people where the buttons are. It does not change what they do on Monday morning.

BCG found that employees learn best when new skills are integrated into the flow of work, rather than in once-a-year workshops.

Where the value of AI actually sits

In BCG’s case work, about 10% of value from AI comes from the algorithms and another 20% from the technology, while the remaining 70% comes from rethinking the people component.

Most of the value from AI comes from people, not technology

• Algorithms10%
• Technology to implement them20%
• Rethinking the people component70%

One engineering leader told us their team was already willing and already experimenting. More training was not the gap. They needed a framework and some guidance on how the team should work with AI.

Here is an invented example. One reviewer waves AI-written code through because its tests pass; another rejects anything AI touched. A team rule fixes this, where a course would not: someone other than the prompter reviews the tests, and the pull request says which parts AI wrote. That is the cultural change we would spend the money on.

The skills that outlast the tools

The foundation is AI literacy and clear prompting: knowing what the tools can do, where they fail and how to ask for what you need. It dates fastest, because it is tied to particular tools. BCG calls these foundational skills and says the core skills that get full value from AI across whole workflows are contextual judgement, framing problems and interpreting results.

As an illustration, here are all three in one decision. An account manager asks an AI assistant to summarise a client contract before a renewal call, and gets a fluent summary that never mentions the notice period. Prompting skill alone takes it into the call. Judgement checks the contract and finds notice is due within weeks. Next time they frame the task differently: list every date and deadline, with its clause.

So train each person on their own work: for a support agent that means real tickets, for a finance analyst a real month-end. BCG reports that bespoke, persona-based learning journeys have been shown to deliver employee AI adoption at a level 20 times higher than a broad-based approach, persona-based meaning built around one role.

The last skill is a habit of trying new tools on real work and saying honestly how it went. A team with that habit learns the next tool without anyone booking it onto a course.

What to do with your budget

1. Start with one team and one piece of work it already owns. Not a sandbox.
2. Agree working rules before choosing tools. Which work AI may touch, who checks its output and what data stays out, like the review rule above.
3. Protect time to experiment. Regular time on real work beats two days in a training room.
4. Make sharing routine. A short weekly show-and-tell of what worked and what did not, with no blame for reporting a tool that let someone down.
5. Measure outcomes, not completions. Indeed’s view is that the true measure of AI adoption isn’t course completions; it is voluntary usage, time saved and improved quality. BCG adds that adoption tells you that people use AI, not whether it pays off.
6. Give it an owner and a monthly review. BCG’s advice is to treat AI as something you keep steering. One person in your team owns the working rules and the outcome measure. Once a month they spend an hour with the team on two questions: is the measure still moving, and has any tool or rule stopped earning its place? Change course when the measure stalls two months running, when quality checks catch more mistakes, or when someone shows a new tool doing a real task better.

Measuring one outcome: a worked example

Take a support team learning to draft replies with AI, where the outcome that matters is how quickly customers hear back. The figures are illustrative.

• Baseline. Before the programme, pull four weeks of tickets. The median time to first reply is six hours, and about one ticket in twenty is reopened.
• Comparison. Once the team has settled in, measure a matching four weeks, never a quiet month against a busy one. The median is now four hours.
• Quality check. Each week a team lead scores ten replies picked at random against your existing standard. Scores hold steady, but one ticket in ten is now reopened.
• The call. Faster replies are worth keeping only if the extra reopens can be fixed, so read the reopened tickets before deciding. If most went out without a look at the customer’s order history, keep the new way of working and practise that check next. Aim for reopens back to one in twenty, with replies near four hours. If the AI drafts are getting facts wrong, pause AI drafting for that kind of ticket until the team has agreed a rule for it.

Then decide where the saved time goes, or it vanishes into the working week.

What to ask before you bring in outside help

How the work is priced tells you what the supplier is set up to deliver.

Model	What you pay for	Best when
Time and materials	Days worked	The scope is still moving and you want to steer it week by week
Retainer	A monthly fee for ongoing access	You want someone on call, rather than a defined piece of work
Capability programme	A fixed price for a defined scope and end date	You want your own team able to carry on without outside help

No pricing model guarantees independence on its own. Whichever you choose, agree in writing what your team will do without help at the end, and how you will check. Before you sign, ask:

• What will my team be able to do without you on the last day, and how will we both know?
• Is this priced against a defined outcome and end date, or by the day or month?
• How will you find out where my team is starting from? A team already experimenting needs working rules and time; one that has barely opened the tools needs foundations first. A plan fixed before anyone has met your people is a warning sign.
• What stays behind when you leave? A way of working your team owns and can change, and people in the team who can teach it to the next hire.

What a Capability programme looks like from your side

If you bring us in, your programme starts with a Discovery: a look at how your team works today, what it can already do and the outcomes you want. Your team then works alongside senior people embedded with it on its own tools and real work. They bring the skills and experience your team does not have yet, and help it find and put into use the few workflows that save it meaningful time. Agreeing the working rules, permitted tools and data boundaries is part of the programme, and you approve them. One team typically takes two to three months, a whole function three to four and a cross-functional rollout four to six, as set out on what we do.

Price depends on scope, but for most teams, usually a mid-market engineering squad of ten to fifteen people, a capability build comes in under £30,000. It is a fixed price, agreed before work starts, and the Discovery fee is credited against the programme if you go ahead.

In Discovery we also agree how we will both know it has worked: which workflows your team will run on its own by the end, and the outcome measure it must hold. In the final weeks your team runs the work while we only watch and answer questions. A few weeks after we leave, we look at the measure together to check it has held.

If you come back to us, it should be because the last piece of work delivered something you could measure, never because your team cannot run without us.

Your next decision

Three choices come first: which piece of real work to start on, who in your team will own the capability and which outcome you will measure. Make those calls and any outside help has something concrete to be judged against. If you want to talk them through, start a conversation.