Most companies are using AI to do the same work faster, and mistaking that for progress. It is exactly the mistake factories made with electricity in 1890, and it cost them 30 years before the productivity gains arrived.
In about nine out of ten conversations I have right now, a business leader tells me a version of the same thing:
They have trained the team, and people are using Copilot and Claude every day.
Then the real problem surfaces, almost word for word every time: the only way to handle more work in this team is to add people, and that is not an option.
That is the ceiling they hit, having done everything the playbook said. McKinsey found the same gap at scale, with around 90% of companies experimenting with AI and fewer than 10% capturing real value from it. The thing is, training does not transform how the work happens. It makes people do the same things faster, which was a constraint, but quickly humans have become the bottleneck for how work gets done faster.
The factory story is the same mistake dressed in older clothes
To bring this to life, when electricity arrived, owners bolted an electric motor where the steam engine used to sit, in the dead centre of the building, and kept everything else exactly as it was. The motor ran fine, but output barely moved for years.
Under the old steam design, every machine on the factory floor was physically connected to one central engine by a network of overhead shafts, belts, and pulleys. If the engine stopped, everything stopped. Machines had to be clustered tightly around it, arranged by mechanical necessity rather than by the actual sequence of work. Switching to an electric motor in the same spot replaced the power source but preserved every constraint that came with it.
The gains only came decades later, when a new generation built factories around what electricity actually allowed. They put small motors on every machine and arranged the floor by the flow of work, not the reach of a central driveshaft. Economist Paul David documented this in his 1990 paper "The Dynamo and the Computer". By the 1920s, electrification accounted for roughly half of all US manufacturing productivity growth.
The lag was not caused by slow technology, it was caused by factories using a new source of power to run the old design. Erik Brynjolfsson notes that the gap between adoption and payoff ran to 20 or 30 years for electricity.
The few factories that redesigned early did not wait that long, because they understood the real lesson and pulled away from everyone else.
That is the choice in front of every business using AI today, and it matters now because AI is not on a 30-year clock. The compression of that timeline is critical in itself.
Redesign the work, not the task
There are two ways to bring AI into a process, and that difference is the core business decision for all Execs moving forward.
**The first is to bolt it on, where AI speeds up the steps that already exist.**The marketer drafts the blog faster, the advisor researches faster, and the same process runs in less time. It feels like progress, but the gains are capped at how fast a human used to go.
**The second is to design the process around AI from scratch, which changes the question completely.**Not "how do we do the current thing faster", but "why is the current thing done at all, and why is a human doing this particular step". The bolt-on is not a stupid move, it is the responsible-looking one, and it is the first step almost everyone takes first. The challenge is that it is also the ceiling almost nobody notices they have hit until they've overinvested in training and the wrong strategy.
Three examples make the difference concrete, and each one applies the same two questions to a real workflow.
**A content team is the first.**The team researches, drafts, and publishes each blog by hand, in a process built back when writing was the expensive part.
Bolt-on version: has the writer use ChatGPT to draft faster, so the same blog ships in half the time.
Work redesign version: asks a different question: why does a human draft the first version at all? An agent pulls from the content library, produces the draft, and routes it to a person for judgement and direction. The writer's job is not drafting anymore. It is editing and taste, where what compounds over time is the library of built up knowledge and writing rather than any single post.
A policy team is the second. The team gathers evidence, drafts a submission, and routes it through a part-time director for sign-off. That takes 10 weeks end to end, with the bottleneck sitting on one person's availability.
Bolt-on version: has advisors use AI to research faster, write the submission in a 10th of the time, but the process is still 10 weeks, just slightly compressed behind the same laggard approval process.
Work redesign version: an agent pulls and distils the evidence into a first draft, and the medical director shifts from drafting to reviewing. Ten weeks becomes about 2 weeks, which is roughly five times the cycle speed. The same team, without adding a single person, can absorb five times the volume that was stuck in a queue before. Cycle time is the leading indicator here, and the financial number follows.
Quality assurance in engineering is the third. It is the example where the trap is most obvious. An engineer writes code, then a person checks it by hand, because QA was a human bottleneck back when checking was slow.
Bolt-on version: looks most like progress and does the most damage: the engineer uses AI to write code faster, and now there is more code stacked behind the same manual QA queue. The bottleneck did not disappear, it just moved downstream and got clogged the system.
Work redesign version: builds an agent to QA the work first. The human is not removed from the loop but moved up a level, from doing the checking to designing the agent that does it, so the check stops being the thing everything waits on.
There is a single pattern across all three. **AI value is limited by how much the business is willing to change the way work gets done.**To rephrase the point another way, Businesses get the most from AI when they use it to reset workflows, not simply speed up existing ones.
Just replicating the old process with a faster engine deletes the gains, especially as the tide rises and those same approaches to work across a competitor base become the norm in every business. This is the bottleneck shift in action, where the constraint does not disappear when AI arrives but simply relocates itself, which is the part most AI rollouts miss entirely.
None of this is easy, and pretending otherwise is where most advice from consultants is misguided. Despite what the frontier labs (Anthropic, OpenAI etc.) or LinkedIn / Twitter bros would have you believe, redesign is much harder than most people understand, because it means changing who does what, which people do not always welcome, on top of getting data out of systems that were never built to give it up (although that's changing, see Salesforce's headless move). That hard part needs specialist capability, an AI engineer or architect, not a keen domain expert with a Copilot licence who's spent 50 hours on YouTube watching Nate Herk (no shade thrown at Nate, love his work. It's just not applicable to most enterprises). The clever agent at the end is the easy 20%, while the context and plumbing underneath it are where most of the effort goes, and where most projects die.
How to actually start
The way to do this without trying to redesign the whole organisation at once comes down to four steps.
Enable everyone at the hygiene layer, with broad fluency training so the whole company has a baseline. This is necessary, but it is the bolt-on layer, and it will not move the business on its own.
Pick a lighthouse team, the SWAT team chosen for genuine enthusiasm and similar-role scalability. A sales or support team where everyone does the same kind of work scales cleanly. A mixed team where every person needs a different solution does not. Go deep with them first, and their wins create the internal envy that pulls everyone else along. Get the plumbing sorted (data, context, systems, hand-offs, rituals).
Build the three things every AI-first workflow needs, borrowing from Kieran Flanagan's four-layer model for the agentic team. Those are context, the institutional knowledge agents need made usable; orchestration, who does what across the steps and what runs on its own; and extraction, getting data out of the legacy systems. Context and extraction are the actual work, not a checklist item.
Drive it from the top, because leadership has to own and protect the redesign, and without that the lighthouse team drifts back to the old way within weeks.
There is a fear underneath all of this, and it deserves an answer from the coalface. If an agent drafts the policy and an agent QAs the code, are these not job cuts wearing a friendlier name?
The straight answer is no, it is not. The reason is already visible in software engineering, where AI now writes a large share of new code and demand for engineers has risen rather than fallen. Economists call it the Jevons paradox (most are now familiar). The name comes from William Stanley Jevons, who noticed in 1865 that more efficient steam engines burned more coal, not less, because cheaper power drove far more demand for it.
When work gets cheaper to produce, organisations do far more of it. The policy team that goes from 10 weeks to two does not cut staff (unless they're already bloated, but that's not an AI problem, that's poor planning and hiring leadership). Instead it takes on the submissions that nobody had capacity for before, because the freed capacity flows straight into the backlog that was always sitting there.
That is also why this is not a technology project run by IT alone. Redesigning work changes the work and the jobs at the same time, which makes it a people decision as much as a technical one. The leaders who treat it as both are the ones who get the gains (increasingly seeing more and more the People and IT leader jumping on an introduction call as a duo).
The leaders who treat AI as a faster motor for the old factory will get exactly what those factory owners got, which is a tool that runs fine and a business that barely moves. To be super clear, the core issue here was never really about the technology at all. Not a technology problem, but a design problem that lands squarely on leadership.
The first step is a small one. Pick one team and run a simple test on a single workflow, asking why this work exists and why a human is doing this step, before building the redesign rather than the speed-up.
Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.
Subscribe to The AI Corner
