Webinar: Make Your AI Rollout Stick

On 10 September 2026, I gave a webinar about the part of an AI rollout that never gets budgeted. The licences land, some training happens, and everyone builds their own version of their own work. Six months later the demos are impressive and the business runs at the same speed. Who owns the tools people have already built, and who fixes them when the AI changes or the person who made them leaves? If the answer is nobody, the rollout has not stuck yet.

Let people try things

A support worker builds a tool to spot repeat requests and tells nobody. Finance uses AI to read invoices and saves a few minutes a week. These trials are how people learn what AI can do for their work, but colleagues often know nothing about them, so teams end up solving the same problem several times.

Peter Seibel called this letting a thousand flowers bloom at Twitter.¹ The next step was to choose which tools to support. Trying things is a useful start, but a shared tool needs care beyond its first version. A Thousand Flowers Is Not Enough explores that next step.

Finish the work

Little’s law says the time to finish anything equals the unfinished work divided by the rate work gets finished. AI has raised the unfinished work. A pile of prototypes, meaning early working versions only one person can use, does not change what the business gets done. It adds noise: more half-built things to keep track of, and more for whoever has to check them. The business only speeds up when work leaves the building as a result people can use and trust.

A tool can also seem to work while hiding a serious fault. One executive built a tool in Claude to view client work. When they asked to use it from home, the AI put the data behind a public link. That exposed the company’s data, even though the tool appeared to do its job.

Where work waits

Writing code faster does not help if it then waits longer for someone to check it. A study of ten thousand developers found that heavy AI use produced 98% more pieces of work for review.² Reviews took 91% longer, while the pace of delivery stayed the same. Feedback Is the New Bottleneck brings together the sources on these delays.

Those figures describe software teams, but the same problem can arise elsewhere. A finance worker can use AI to compare a hundred sets of accounts, but someone still has to check them. The slowest step has moved from doing the work to reviewing it.

Tools need support

Codex, ChatGPT and Claude are good at helping one person on one machine get work done, and they are still rough at the edges themselves. Changing a whole process takes someone who understands its steps and can connect the tools it uses. Buying licences does not assign that job to anyone.

AI companies have committed nearly $10bn to engineers who work inside their customers’ businesses.³ The name for the role is forward deployed engineer, or FDE, and you will hear it a lot this year. They map how the work happens, connect the AI to your systems and data, decide what it can see and when a person reviews its work, and stay until it runs on its own. The labs send them to customers with thousands of staff, so everyone else has to find their own.

Who does the work?

At a few hundred staff, a small team of engineers you already have can start part time. At around fifty, it is one engineer, or a couple, with a clear job to do and a name against it. If you are on your own, the same discipline applies: decide what starts the tool, who checks it, and what it can reach before you build. The people who suit this work like mess. They will sit with finance for an afternoon or chase a missing login for a week, and that matters more than being your strongest software designer.

The people doing the work are best placed to choose what to improve, so point the engineers at the tools people have already built. Their job is to sit with the person who made it, understand what they wanted, and make it safe for others to use. Start with real data and aim for a working process in five days. Long rollouts stall while teams wait on each other.

Is it worth maintaining?

XKCD’s chart asks how much time a task can save over five years.⁴ Saving one minute a day allows four hours to build the tool. Saving an hour a week allows ten days. But the chart leaves out the time spent keeping the tool working.

AI can cut the time it takes to build something, but the systems it connects to will still change. The AI itself will change, and the person who built the tool will leave. Count the work of keeping it running when deciding whether it saves time.

One real process

One finance team needed to check sales orders against customer purchase orders. Each sales order arrived in the finance system, but someone still had to find the matching purchase order. The purchase order arrived as a PDF or email, sometimes in another language. Someone compared the amounts, codes and terms, then chased anything that did not match. This took one or two people several hours a week.

This is work I did recently with the team. We did not want it to start life as one person’s private tool that nobody else could use or knew about, so we mapped the process first, decided how it would run and who would review it, and then built it.

The shared version starts when a new sales order arrives. It can read the finance system but cannot change it. It records what it checked and any details that did not match. A finance person gets an email alert to review those differences. A weekly email lists what matched, using the format the team found easiest.

Keep ownership

When outside engineers do this work, whether a vendor, a consultancy or me, the knowledge of how your work happens can end up in their team, and that is how help becomes lock-in. Before anyone starts, ask four questions. Who owns the process maps? Who owns the checks and the records? Can we run it without them? Are they teaching our people, or becoming our AI department? Escape the Great AI Lock-In covers this risk in more depth.

Questions from attendees

One attendee asked how to let people try AI while keeping data safe. My answer was to use company accounts and let tools read data without changing it. Turn on features as people learn to use them, and explain which tools are allowed. Banning AI can push people towards personal accounts.

They also asked about a single view of all the AI processes staff had built. I did not know of a platform that offered one. Usage counts do not explain what people are doing. Seeing the content of their work also raises questions about privacy. Talk to frequent users to find useful ideas, and to those who avoid AI to understand why.

Another attendee asked how to test AI when its answers can vary. Use evals, which are checks that show whether the AI still does its job after changes. The checks must cover the whole process, as why prompt evals alone are useless explains. The code and instructions around the AI are the subject of The Harness Is The Bottleneck.

Key takeaway to remember

Name who owns each AI process, and give engineers time to turn the useful early versions into tools the whole team can rely on. Letting everyone try things is the right start, but it is not a rollout until somebody owns the result and the work of keeping it running is in the plan.

One thing to try this week

Draw the steps of a process that takes a day a week. Note what starts it, where work waits, and who checks the result. Mark who fixes it when it breaks. Find any version someone already built, then ask whether the time saved covers its upkeep.