The AI talent market is expensive and slow. The people who understand your systems, your data and your edge cases are already on the payroll. Enablement is usually the faster route, provided you do it in the right order.
There are three ways to get AI capability into a retail technology function.
Buy it as a product, which is fast and gets you what the vendor decided to build, priced per seat, with your data in someone else's system and no capability left behind.
Hire it, which gets you real expertise eventually, at a salary set by a market competing with technology companies, after a search that takes months and a ramp that takes more.
Or enable the team you have, which is slower to start than buying and much faster than hiring, and is the only option that compounds. Your existing engineers and analysts already know why the returns process has that exception, which supplier feed is unreliable, and what broke last peak. That knowledge takes a new hire a year to acquire and cannot be bought at all.
Most organisations should do all three. The mistake is doing them in the wrong order, and specifically treating enablement as the last step rather than the thing that runs alongside everything else.
The standard enablement programme starts with a course. Fundamentals, prompt technique, a workshop, maybe a certification. Three months later, adoption is patchy and the sponsors are disappointed.
It fails because it teaches people to use something they have never seen working on anything they care about. The examples are generic, the exercises are toy problems, and by the time a real opportunity appears the training has gone stale.
Invert it. Put a working system into production first, on a real process the team owns, built where they can watch. Then train, while they have questions that came from their own systems. A team that has spent six weeks watching an agent handle a workflow they understand will learn more in a two-day session than a team that arrived cold, because they turn up with specific problems rather than polite attention.
The sequence is deploy, observe, then teach, then hand over. Not teach, then hope somebody deploys.
Enablement fails when it treats a technology function as one audience. In practice you are dealing with at least three.
The sceptic, usually experienced and often correct. They have seen tools arrive with big claims and leave a mess. Do not try to convert them with enthusiasm. Give them the failure modes, the guardrails, the audit trail, and the rollback path. Sceptics who are engaged early become the strongest advocates, because their endorsement carries weight precisely because it was hard to get.
The enthusiast, already using these tools, possibly without telling anyone. Your job here is not motivation, it is direction and safety. Find them, make their work visible, and give them the standards to follow so their initiative becomes an asset rather than an unreviewed dependency.
The quiet majority, who will adopt whatever becomes normal. They are not resistant, they are busy. They need the workflow to be the path of least resistance in the systems they already use, and they need to see colleagues doing it without drama. This group determines whether the capability sticks, and they are the ones generic training reaches least.
Not a curriculum. Four things.
Pairing on real work. Your engineer and someone who has done it before, building something the business asked for, in your repositories, through your review process. This is where most of the transfer happens and there is no substitute for it.
Written patterns from your own systems. How agents connect to your data, how guardrails are specified here, what gets logged, how something moves from experiment to production, who approves what. Short, specific to your environment, and derived from systems that exist rather than principles in the abstract.
An owner per system, named early. Not at handover, at the start. The person who will run it should be in the build, because operating knowledge is acquired by watching things break and be fixed, not by reading a runbook written at the end.
A visible internal example. One system the whole function knows about, can look at, and can copy. Internal service-desk automation is a good candidate: it is genuinely useful, low customer risk, and everyone in the technology function experiences it directly.
Attendance and certificates measure nothing. Capability is demonstrated, not attended.
Set a date and run a real test. Can the internal owner deploy a change to a production system without external help? Can they diagnose a failure from the logs and monitoring alone? Can a team member who was not part of the build ship a small improvement using the documented pattern? Can they explain the guardrails and say what the system is not allowed to do?
Give the test a date at the start of the engagement so it shapes how the work is done. It changes the behaviour of everyone involved: the external team builds to be understood rather than to be clever, and the internal team engages knowing they will be operating it.
If the team passes, the capability is real and you have a genuine choice about what happens next. Keep the external team on to build the next thing, or run it yourselves. Either is fine. What matters is that it is a decision rather than a dependency.
A retail technology function is not short of talent. It is short of exposure. The people are capable, the systems knowledge is deep, and the constraint is that nobody has yet built something that acts on production data with guardrails and lived with it afterwards.
That gap closes in weeks alongside people who have done it, and it closes permanently. Compare that with a twelve-month hiring cycle for a single person who will need a year to learn what your existing team already knows, and the arithmetic is not close.
Hire as well, when you know what the role is. But do not wait for that hire to start building, and do not treat the training of the people you already employ as the thing you get to after the strategy is signed off.
We build production systems alongside your engineers and hand over the capability, not just the code. Enablement is part of the work.