Training your team on AI is the wrong first step

A company decides to get to grips with generative artificial intelligence. The first instinct, almost every time, is to book the team on a course. It is a reassuring instinct, and one of the surest ways to spend a budget without changing anything about how the company actually works.

The instinct that looks sensible

The reasoning runs in three steps. Generative AI is changing office work. Our people do not know how to use it. Let us train them, and we will work out afterwards what to do with it.

That reasoning has one genuine merit: it is easy to approve. A course can be ordered, scheduled and paid for. It produces visible proof that something is happening. It settles a board that senses it is falling behind. And it puts nothing at operational risk, because it touches no process.

The trouble is that it answers the wrong question. The question is not whether your staff can open a chat assistant. It is which work, in your company specifically, is worth rebuilding with these tools, and what that would be worth to you. No off-the-shelf course answers the second question, because it knows nothing about your processes, your data or your daily irritations.

Three reasons training first does not work

The skill goes stale faster than the training plan

The field moves at a speed few technical subjects have matched. Models change several times a year. The interfaces change with them. The practices held to be optimal eighteen months ago, above all the elaborate recipes for writing instructions, have been made largely pointless by models that understand a request written in plain language.

More to the point, the centre of gravity has shifted. The skill is no longer phrasing a question well in a chat window. It is connecting an assistant to your systems so that it reads your data, acts in your tools and hands back work you can check. Someone trained in January on how to write prompts finds a different landscape by the summer, and comes away with the uncomfortable sense of having learned something already out of date.

This is not an argument against learning. It is an argument against learning in the abstract. What does not go stale is the habit built on a tool you use every day in your own job. That habit survives version changes, because it is attached to a use rather than to a technology.

A generic course cannot know what to automate in your business

In a consultancy, the lost time does not sit where it sits in a services firm or a distributor. In one place it is the meeting notes and the proposals that should follow them. In another it is reconciling the invoicing software against the customer file. Somewhere else it is the manual preparation of studies that only three people know how to do.

None of this is visible from a training room. You find it by looking at a team’s real calendar, counting the back-and-forth, asking someone how long they spend retyping information from one screen into another. That is observation work, not knowledge transfer. It produces a list of projects ranked by gain and by difficulty, which a course never produces.

We do that work on one area at a time, over ten days. The output is not a step up in skills. It is a costed investment decision.

A team trained with no tool and no mandate returns to its habits

The third point is the most ordinary and the most fatal. A course ends on a Friday. On Monday the daily workload takes over again. The people who went come back with ideas, sometimes with enthusiasm, but with no tool installed, no budget, no explicit permission to change a process, and no time set aside to do it.

There is a further obstacle that gets little attention: the fear of doing the wrong thing with company data. Tell someone on a course that confidential information must never go into a consumer service, give them no contracted alternative, and they will make the only sensible decision available to them. They will use nothing at all. That has to be settled beforehand, and we have given it a guide of its own on generative AI and confidential data.

Three months later the picture is nearly always the same. Two or three motivated people have cobbled together useful personal habits. The rest of the team has gone back to working exactly as before. And the company is left with a vague sense of having tried, which makes the next attempt harder to fund.

What to do instead

The order of operations we argue for is simple, and it reverses the usual sequence.

• Pick one area, a single one, where everybody agrees there is pain.
• Measure where the time actually goes in that area, in hours rather than impressions.
• Build a first system that runs in production and produces something usable.
• Train the team on that tool, once it exists.

The choice of area matters more than people expect. A wide scope gives you a list of intentions. A narrow scope gives you a project. Sales, administration, customer support, the production work itself: start with the one whose manager tells you unprompted that there is a problem. You will have an ally rather than a sceptic.

Measuring the time is the step companies skip most readily, and that is a shame, because it decides everything else. Until you know how many hours a week go into a task, you cannot prioritise it, justify spending on it, or prove a gain afterwards. A rough count is enough. An honest range beats an invented percentage.

Then comes the building. A first system does not need to be ambitious. It needs to be genuinely used. That is the difference between a demonstration and a pilot build: the demonstration impresses once, the pilot gets in the way of somebody’s working day until it functions properly.

Training arrives at that point, and only then. It becomes concrete, short, and aimed at people with the tool in front of them. It stops being about artificial intelligence in general. It explains how to check a generated text, how to spot the typical errors, what to do when the output is poor, and where the machine’s autonomy ends.

Two projects that show the right order

At a twenty-person consultancy, sales follow-up used to evaporate after every pitch meeting. We sent nobody on a course. We set up recording and transcription of those meetings, then a system that drafts the follow-up email and the matching proposal on its own, sends them after a human read-through, and feeds the customer relationship management software. The learning took one conversation, because there was only one thing to learn: read it before you send it. That project has a guide of its own, from meeting transcript to sent proposal.

The second example comes from the same client. Their analysts prepared location studies through a chain of manual steps. We built them an internal tool, made to measure, that they operate themselves. They did not become generative AI specialists. They became users of a tool that makes their work faster, which is exactly the point. Whether to build rather than subscribe deserves a guide to itself, and we have written one.

In both cases the skill came after the system and was carried by it. That is the sequence we recommend.

When training becomes a good investment

It would be dishonest to conclude that training is useless. It is useful, at a different moment and for different reasons.

It is useful when a tool exists and its use has to spread beyond the first few users. It is useful for passing on rules of caution about data, once the framework is set and the permitted alternatives exist. It is useful for a team whose job is about to change deeply and who need to understand what is coming, not simply be handed software. And it is useful when a company wants to become self-sufficient and take over the systems built for it, which is the normal aim of a handover phase.

In all of those cases, training has a precise object and a tool in front of it. It is no longer a bet on the future, it is support for a change already under way. The same money, spent at the right moment, with an entirely different return.

If you are hesitating between booking ten people on a session and starting a first project, look first at what a diagnostic covers on a single area of your business. Ten days later you will know what there is to gain, and the training question will present itself in the right terms.