Since the start of this year I’ve been a regular guest at a series of invite-only Artificial Intelligence (AI) discussions held over dinner in Manchester, Leeds, and London. The rooms are deliberately mixed; team leads, Human Resources (HR) professionals, founders, operations directors, and the occasional engineer. Most of the attendees have decision-making authority over budgets, hiring, and process. Almost none of them have led an AI rollout before. And, by my count, I’ve been one of the only people in the room with practical experience of leading AI adoption for clients.
One topic keeps coming up. It surfaces under different phrasings, but the underlying question is always the same: What’s the one AI thing that saves us millions?
Sometimes it’s framed as a productivity question. Sometimes it’s a workforce question. Occasionally, and uncomfortably, it’s a redundancy question. The questioners want a moonshot; one bold programme, one transformative tool, one announcement to the board that justifies the budget they’ve already been promised. Having led AI adoption for clients including a globally recognised logistics business (where a structured programme produced a 75% improvement in feature delivery), my honest answer is rarely the one they hoped for: the moonshot is the wrong target.
The biggest gains from AI adoption do not sit behind a single, headline-worthy bet. They are scattered across the small, repetitive, frequently invisible toil that everyone in the business has learned to tolerate. The companies that will get the most out of AI over the next few years will not be the ones with the most ambitious strategy; they will be the ones with the discipline to keep finding small problems and removing them.
That is the argument of this post.
Everyone Wants the Moonshot
When I ask the other guests around these tables to describe what a successful AI rollout looks like for their organisation, the answers cluster around a small set of themes. Replace the first-line support team. Automate the entire month-end accounting close. Build the AI sales development representative. Hand the marketing pipeline to a swarm of agents.
These are not unreasonable ambitions in themselves. The discomfort is that they are almost always proposed as the starting point, not the destination. The intention is to find a single, transformative project, fund it heavily, and emerge twelve months later with a dramatically restructured organisation.
There are several reasons this framing dominates. Vendors pitch in moonshot terms because moonshots justify enterprise pricing. Boards prefer moonshots because they look like strategy rather than housekeeping. Executives know that quiet improvements to internal workflows are difficult to put on a slide, but a flagship AI programme is easy to point at and easier still to take credit for. There is also a deeper, less-spoken pressure: nobody wants to be the company that did AI in 2026 and ended up with marginal gains while the competition allegedly built something extraordinary.
This pressure shows up in newer and stranger forms than the usual board-deck theatrics. Axios reported in May 2026 on a pattern they called “tokenmaxxing”: enterprises gamifying their AI adoption through internal leaderboards that rank employees by how many tokens they have consumed against the company’s enterprise Application Programming Interface (API) account. The implicit logic is that visible consumption is the same thing as visible value. In the same report, an AI consultant described a client who had spent half a billion dollars in a single month after failing to put usage limits on the Claude licences they had issued to employees. Half a billion dollars is real money even at the largest of enterprises. The moonshot framing, taken seriously enough, produces line items like that one.
Days after that Axios report, Amazon shut down its own internal AI usage leaderboard following revelations that employees had been cheating to climb it. Gameable league tables, taken seriously enough, produce fraud.
The trouble is that moonshot programmes have a poor track record. They are expensive to scope, slow to deliver, and structurally prone to overpromising. They concentrate risk into a single bet, often before the organisation has built up the AI fluency it would need to evaluate whether the bet is paying off. Worse, while leadership attention sits on the moonshot, the smaller, cheaper, higher-yield opportunities go cold. The people closest to the toil have neither budget nor permission to address it themselves. They wait for the programme to land. By the time it does, half of them have moved on or stopped offering ideas (a pattern I have seen more than once across the dozens of organisations I’ve worked with).
You end up with a vivid pitch deck, a sluggish rollout, and a team that has lost its appetite for change.
Speed Without Technique Just Breaks Things Faster
There is a famous line in martial arts coaching: technique first, then speed. The principle behind it is that speed multiplies whatever motion you already have. If your form is good, speed makes you formidable. If your form is poor, speed makes you both less effective and more likely to injure yourself or someone else. Bruce Lee is often associated with this sentiment, particularly through his observation that he feared the practitioner who had drilled one kick ten thousand times more than the one who had dabbled in ten thousand kicks once.
AI is a speed multiplier. It does not, on its own, improve the quality of the underlying process; it accelerates whatever was there before. This is the principle that decision makers most consistently underweight when planning their adoption strategy.
Consider what this means in practice. If your forecasting spreadsheets are full of stale assumptions, an AI assistant will produce forecasts more quickly using those same stale assumptions. If your customer support scripts are designed for a product that no longer behaves the way the scripts describe, an AI agent will hand out incorrect guidance at a higher volume. If your codebase has been allowed to drift for a decade without architectural attention, an AI coding tool will help your developers add features more quickly to a structure that is already buckling. The output is no better; there is just more of it.
The companies that suffer the most from this pattern tend to share a profile. They have moved fast on AI tooling without first interrogating the quality of the workflows that the tooling is now amplifying. The first few months feel like a win. Throughput goes up. Reports flow more easily. Confidence rises. Then the consequences land: faster wrong answers, more confidently delivered, harder to trace because nobody owns the speed-up enough to audit it. Technical debt compounds at the rate of AI velocity rather than human velocity. Customers receive more polished, more incorrect responses. Engineering teams encounter merge conflicts and review queues they have no realistic way to clear.
There are public examples of this dynamic landing badly. McDonald’s ran a multi-year trial of AI ordering at their drive-thru lanes, partnered with IBM, and rolled the system out across more than a hundred restaurants. They pulled the test in 2024 after a string of viral failures; customers being charged for orders they had not placed, bacon being layered onto ice cream sundaes, and at one widely shared moment an AI agent insisting it had not added nine sweet teas to a customer’s order, despite the running total showing exactly that. The failures were not really an AI problem. They were a workflow problem. The drive-thru lane is a noisy, accent-rich, multi-speaker environment with a strict latency budget; the underlying ordering process had not been redesigned for the kind of constrained, well-bounded conversation that current models handle reliably. AI did not break the drive-thru. AI made the existing fragility legible in public.
The hidden tax of skipping technique becomes obvious only once the bill arrives.
This does not mean AI should wait until everything is perfect. Nothing ever is. It means the order matters. Look at the workflow first. Improve what is improvable without AI. Then bring AI in to accelerate the version of the process that is actually worth running faster.
Enter Kaizen
The most useful mental model I’ve found for this is Kaizen.
If you have spent any time in modern software organisations, you have already encountered Kaizen even if you didn’t know its name. Agile, Lean, DevOps, the Toyota Production System: each of them inherits, directly or indirectly, from the same continual-improvement philosophy that Masaaki Imai described in his 1986 book of the same name. (I wrote about Kaizen at length in my 2020 Continual Professional Development (CPD) review, for readers who want the longer treatment.)
The literal translation of 改善 is closer to “change for the better” than to the more sweeping “improvement” that English readers often assume. The cultural practice that emerged around it is the more important part. In a Kaizen-influenced workplace, anyone involved in the work has the authority, and the expectation, to stop the production line when they spot a defect. Everyone is responsible for raising small concerns. No improvement is too minor to be worth surfacing. The discipline lives in the accumulation, not in any single intervention.
This translates almost without modification into a useful AI adoption philosophy.
The people doing the work know where the toil lives. They know which spreadsheets need an hour of cleanup before they become useful. They know which reports they regenerate every Monday morning. They know which customer responses they paste in from a saved file with three small edits. They know which internal documentation hasn’t been touched since their predecessor left the role. These are not glamorous problems. They are also exactly the problems AI is currently best suited to solve.
A Kaizen-shaped AI strategy starts from the bottom of the toil pile and works upward. It treats each small win as data; you learn what your team is willing to adopt, how much governance you actually need, and where the genuine bottlenecks sit. The cumulative effect of fifty small wins, well chosen, will outpace a single moonshot in almost every realistic scenario. It also leaves the organisation in a far better position to attempt something ambitious later, because by the time it tries, it will have built genuine AI fluency rather than imported it from a vendor’s pitch deck.
Three Examples From the Field
The three examples below are all real situations, drawn from client engagements over the past couple of years and lightly anonymised. They are deliberately ordinary. That is the point.
Example One: The Onboarding Wizard
A business had a customer onboarding wizard that had grown, organically and uncomfortably, over several years. It now ran to tens of screens, each carrying its own conditional logic, and the sales team had developed a folklore around which combinations of answers were safe to choose and which would trap the user in a dead-end branch.
The initial proposal was straightforward: automate the wizard with an AI agent that could ingest the customer’s information up-front and complete the form on their behalf. There were gains to be had there. The problem was that the agent would be automating, and then locking in, every piece of accidental complexity the wizard had accumulated since launch.
The Kaizen move was to simplify the wizard first. We mapped the existing logic, looked for branches that no longer served a real business purpose, consolidated screens that had drifted apart for historical reasons, and pruned the conditional traps that the sales folklore had grown up around. Only once the wizard made sense as a workflow did we consider automation. The automation was then dramatically simpler to build, easier to test, and more pleasant for customers to encounter when they were asked to verify the agent’s work.
There was a hidden benefit which proved more valuable than any of us anticipated. The act of simplifying the wizard produced, as a byproduct, the first proper documentation the onboarding process had ever had. The team had previously held the workflow in collective memory; now it lived in a single artefact. That documentation primed the AI tooling far more effectively when the automation work began. The model had context that the previous version would have lacked, and the team had a reference they could point at the next time someone suggested adding “just one more” screen.
ℹ️ Note
Automating complexity locks the complexity in. Simplify first, then automate the simplified version. You will save engineering time, reduce the surface area for bugs, and gain real documentation as a side effect.
Example Two: The Accountant’s Spreadsheet
An accountant on a finance team spent hours every month preparing data before the actual work of balancing the books could begin. The data came from several upstream systems, each with its own export format, and none of them quite agreed on how dates, currencies, or category codes should be written. The accountant’s job, before anything resembling accounting could happen, was to reformat, reconcile, and re-key.
The conversation, when AI came up, began in the usual place: could the team replace the accountant with an AI accountant? The honest answer was that they could not, and that anyone promising otherwise was selling something. Bookkeeping requires judgement, regulatory awareness, and accountability that no current model can provide.
The Kaizen-shaped question was different. Where in the accountant’s day was AI a reasonable fit? The answer was obvious once the question was reframed. The reformatting step was a near-perfect candidate for automation. We built a guarded data-cleaning pipeline that took raw exports, normalised them against an agreed schema, and presented the accountant with a single, consistent file ready for review before it entered the spreadsheet. The accountant kept the judgement work, kept the accountability, and kept their job; what they lost was the toil.
A 6% reduction in monthly time spent on a single task does not sound like a moonshot. Multiply it across a finance team and a calendar year, and you start to see why it matters. The team gained capacity to invest in the parts of their work that humans are still meaningfully better at.
Example Three: The Slide Deck Templates
A consultancy had commissioned a brand refresh from an external designer. The new brand looked excellent. It also arrived as a set of template designs that needed to be propagated across hundreds of existing client decks, internal training materials, and proposal templates. The team’s initial plan was to roll the work out across multiple months of careful, manual reformatting; one designer alone was looking at the better part of a quarter.
The Kaizen move here was almost embarrassingly straightforward. The designer had built the new brand templates in Figma. Rather than asking a human to manually re-implement that work across hundreds of existing decks, we connected Figma’s Model Context Protocol (MCP) server to an AI agent, pointed the agent at the relevant client decks, and let it run. The agent transformed the bulk of the templates against the new guidelines; the designer’s role shifted to reviewing the output, refining the edge cases, and applying judgement to anything the agent couldn’t quite resolve.
The work that had been scoped at months landed in weeks. The shift suited the designer’s experience far better; production work moved to the agent, curation work stayed with the human. The team also learned a useful, generalisable lesson: AI is well suited to high-volume, low-judgement transformation work, particularly where the rules can be described clearly in advance and the source-of-truth lives somewhere the agent can read directly.
None of these three examples is a moonshot. None of them required a flagship programme. Each of them returned more value, more quickly, than the headline AI strategies their organisations had been considering at the same time.
A Case Study: Ligentia
A useful real-world illustration comes from the work I did with Ligentia, a logistics business whose Chief Information Officer (CIO) brought me in to introduce AI development tooling to a team with no prior AI experience and, by their own admission, a healthy scepticism around training data, output quality, and the time cost of the learning curve. The team’s reservations were entirely reasonable. They had heard the moonshot pitch elsewhere and had not been impressed.
We approached the work as a Kaizen-shaped programme rather than a flagship one. The first phase was an evaluation of tooling options with the Director of Engineering, which led to selecting Claude Code Enterprise as the team’s development platform. The rollout was structured as a pilot rather than a launch; small, deliberately reversible, and run with the active partnership of the Head of Automation. Weekly lunch-and-learns gave developers space to share their own findings with each other, which (predictably, in retrospect) did more for adoption than any top-down communication ever could.
We deliberately picked a single, real piece of client work as the proving ground; a two-person integration build originally scoped at three months. The intent was not to use the project to demonstrate AI; it was to use AI to deliver the project, and to learn from the experience as a team. The full architecture was in place inside the first month. The remaining engagement time was spent shipping features at the pace the end client could request them.
By the end of the engagement, feature delivery had improved by 75%. The team had to redesign its release cadence because they were shipping faster than they could review code, and we were scoping automated first-stage pull request reviews to address the new bottleneck. Developers had moved from zero AI use to daily Claude Code workflows. Some had begun experimenting with GitHub SpecKit; one was fine-tuning small language models. Claude was rolled out to the wider business not because we pushed for it, but because the rest of the organisation had heard the team’s own stories and asked.
Within a week of him working with us, [Jamie] had already identified five different areas for improvement, given two inspiring talks, and created a handful of engaging demos, all leading to almost immediate ROI.
Nothing about that work was a moonshot. It was small bets, weekly reflection, and a discipline of letting the team own the curve. The 75% improvement was not the goal we set out to hit; it was what fell out of the approach.
How to Start Tomorrow
You do not need a strategy document, a budget approval, or a vendor selection process to begin. You need three short conversations with the people who do the work.
Here are the three questions I would take to your team this week.
✅ Where is the toil? Which tasks do people sigh through every week, every month, every quarter? Which spreadsheets get reformatted by hand? Which reports get assembled from the same sources every time? Which communications get drafted from a saved template with minor variations? These are your starting candidates.
✅ Which of your systems are so complex that you would struggle to describe them to a competent newcomer in an hour? Those systems are not automation candidates yet. They are simplification candidates. Use AI to help you understand and simplify them first; then revisit the automation question. (The two activities sit closer together than you might think; the simplification work itself often produces the documentation and shared understanding that future automation will rely on.)
✅ Where are you measuring outcomes badly enough that an AI win would look like noise? If you cannot tell whether your support team’s response quality has improved, you cannot judge whether a support AI is helping. Quietly fix the measurement before you fix the workflow; otherwise you will burn budget arguing about whether the rollout worked.
There are larger, more ambitious AI projects worth doing in most organisations. This is not a counsel of caution. It is a counsel of direction. The big wins are real; they tend to be the cumulative effect of dozens of small ones, rather than the result of a single, well-funded bet.
Closing Thought
The dinner conversations I’ve been part of this year will, I suspect, keep producing the same question. Someone will keep wanting to know which one AI thing will save them millions. The honest answer is that the company quietly improving a hundred small workflows in 2026 will out-deliver the company that spent twelve months chasing one moonshot. The advantage compounds. The team gets better at finding problems. The toil shrinks. The AI fluency grows organically, in the hands of the people who actually do the work.
That is, in the end, what Kaizen has always been about. Not the dramatic transformation. The next small, deliberate, sensible improvement, repeated until it accumulates into something the moonshot crowd will eventually call a revolution.
The 75% improvement at Ligentia did not come from a flagship programme. It came from a structured, deliberate rollout. If you want to run one of those inside your organisation, book a consultation.