We've done the excitement phase of AI. We've done the experimentation phase. Most organisations are now in implementation, which in practice means the bottom of the J-curve: the stretch where something with real potential feels like hard work and cost - way before it shows up as proven ROI.
It's an uncomfortable place to be, mostly because it seems likely everyone is already way beyond it. LinkedIn is full of people shipping agents in an afternoon, but really, many organisations that rolled out Copilot licences a year ago are still mostly using them to summarise meetings - or focused purely on 'personal productivity'.
The clearest take I've heard on how to move beyond this stage is from a recent episode of the Capability Loop Podcast with Rory Hill, Head of Corporate Transformation and AI at an NHS trust. Rory has spent 13 years in the NHS, most of it in programme management and governance, and he ran London's mass vaccination centres during Covid. When AI arrived, he moved to a four-day week so he could spend a day experimenting with AI (a move that turned out to be very wise for his career). That head start meant he was ready when the NHS rolled out Copilot, and his early pilots went well.
What is really interesting though is that it wasn't the head start that moved things forward. It was the structure he built from it.
Personal productivity is a step, not a destination
Rory calls it the stair step. Everyone starts at day zero in Copilot Chat, prompting. The next step is saved prompts, available to everyone on the free licence, which subtly changes how people think: once you know you'll reuse something, you start improving it. Reusable prompts lead to personal agents pointed at the right documents. A personal agent that works for you is probably useful to your team, and turning it into a team agent forces another shift, because now there's a customer for what you've built. If it works for the team, the next question is whether it works for the organisation.
None of those steps is dramatic. Each is small enough that people grow into their AI usage and each changes how they think about the work, not just how they use the tool.
The real value is in what Rory hangs off the structure. For each of the use cases that emerge out of his team's use of Copilot, an acceptable use policy covers prompting. Personal agents raise questions about which data they can reach and who has access to it. Organisation-wide agents need a completely different level of control. One shared picture lets him explain to every part of the organisation what has to be in place before a given use case can happen.
My question to you: if someone in your organisation built something genuinely useful tomorrow, could anyone tell them what it would take to scale it? If not, it will most likely stay on their laptop, and the rest of the organisation will never benefit.
One training session is an event. Five is a programme.
Rory's team started where most do, with broad training on where Copilot helps, and the data proved that usage went up after a single session. But the really compelling insight came from comparing people who attended one session with people who attended three, four or five in sequence. The second group's usage wasn't a little higher. In Rory's words, it was many multiples higher.
That matches everything I've seen. A training session is an event and AI capability is a state. Organisations keep buying the first and hoping it produces the second, without thinking about what needs to happen in between.
And the gap is widening. PwC's 2026 Global Workforce Hopes and Fears Survey, which surveyed nearly 50,000 workers, found 64% had used AI at work in the past 12 months, up ten points on last year. Yet only 51% say they have access to the learning and development they need, down from 59%.
Usage is going up while the support to use it well is going down. That's a lot of people being handed the tool and left to work out the rest on their own.
The shift Rory's after is people thinking differently about the work itself. If you automate what you already do, you won't get very far. You need people spotting opportunities, thinking in systems and building the judgement to redesign how work gets done. That normally takes time to experiment, and most people don't have a spare day a week. Rory sees part of his team's job as shortcutting that journey: giving people the structure he found through his own experimentation, so they can get there in less time.
Not can't. Not yet.
How do you decide which ideas to scale when you only have a small team to build them? Rory's answer has moved on in stages. At first it was simply backing the people who got ahead of the pack, then it was impact: how many people would this help, and by how much. Now it includes two further dimensions:
The first is digital maturity.
This is measured on two fronts. One is the people - does the requesting team have a subject matter expert ready to test the outputs and feed back? Without that person, a solution is just a product that sits on the shelf. The other is the organisation's technical maturity. Are the controls in place to support something this complex, and if not, when will they be?
Put those two together and a request that would otherwise get a flat no becomes a not yet, with a date to revisit it when the controls on the roadmap arrive. That turns frustration into pent-up demand, and pent-up demand is what pushes an organisation to fund the governance work it has been putting off.
The second is reuse.
With limited resource, Rory looks for use cases built from parts that can be used elsewhere. A shared mailbox agent, for example, will sit inside a lot of future solutions, so building it well once makes every later build cheaper.
I've seen the opposite plenty of times: teams building agents because they looked good in a demo, with no assessment of whether the business was ready for them and no layer above asking whether anyone could support, govern or improve them. They looked great in the demo and served no real purpose afterwards.
Return is more than money
Rory's view on ROI is back to basics. Before you build anything beyond personal productivity, write down the problem you're solving, the benefit you expect, and where you'll be able to see it afterwards. Miss that stage out and you can be a long way into a complex build before realising you're not sure it will deliver what you expected.
What counts as return is broader than in most commercial conversations. In the NHS it's time saved, but it's also staff experience, and ultimately patient experience and the quality of what gets produced. The NHS is a hard place to work at times, and tools that make that better are a benefit worth counting. The cost of the licences still has to be justified, as it does everywhere, but it isn't the only measure.
He also profiles benefits over time. Personal productivity shows up early and almost everyone feels it. Organisational efficiency comes later and is harder to win. Being clear about that at the start stops you writing off useful benefits, and tells everyone when to expect the bigger ones.
My question: does your business case for AI say when each type of benefit should appear? If it doesn't, the first few quarters of thin efficiency numbers will look like failure, when they're simply the bottom of the J-curve.
Thanks, as always, Andy
PS. You can watch the full conversation with Rory on YouTube. Rory also writes about this work at riordanhill.com.
