Factories electrified around 1890 and got almost nothing out of it for thirty years, because they kept the existing factory design instead of redesigning it around the new technology. Most AI adoption is doing exactly that right now.
Every company runs steps that exist only because something used to be expensive. This page is about finding yours and cutting them.
Machines cluster near the driveshaft. Buildings go vertical. One repair idles the whole floor.
Only the power source changed. Thirty years, no measurable gain. This is where most companies are with AI.
A motor per machine. Layout follows the flow of work. Single storey, wide span. The productivity surge lands here.
The group drive outcome has symptoms, and they show up long before the numbers do. If four or more of these are true, you are paying for a new motor and running the old building.
Code output is visibly up. Time from decision to production is not.
Your review queue is the longest it has ever been, and your strongest engineers spend their day in it.
More work is in progress than six months ago. Less of it is finished.
You have more prototypes than decisions.
Someone reports a large time saving and you cannot find it in any number you track.
Your seniors got faster. Your juniors stopped getting better.
Every meeting that existed two years ago still exists, and most take the same amount of time.
Nobody can name revenue you won, or a cost you stopped paying, because of what you spend on AI.
None of that means spending on AI was wrong. It means the gain is stuck in a structure you can change, and the rest of this page is about which structure.
Paul David, The Dynamo and the Computer, American Economic Review, 1990. Six pages that explain most of what you are about to experience.
Practical electric power arrives around 1882. Electric motors cross half of American manufacturing horsepower around 1919. The manufacturing productivity surge shows up in the 1920s. Roughly four decades from arrival to payoff.
The delay was not a technology problem. It was a building problem: the shape of the factory came from its power source. Steam meant a central engine, a driveshaft running the length of the hall, and leather belts dropping from that shaft down to each machine.
That fixed where a machine could stand. It had to sit close enough underneath a shaft for a belt to reach it, and the shafts themselves ran in fixed straight lines out from the engine. So you could not put a machine where the next step of the work needed it. You could only put it where a belt could reach. Adding more shafting to serve a better layout was expensive, and every extra metre of spinning steel lost power to friction. The sequence of work bent around the geometry of the power system, never the other way round.
When electricity arrived, factories did the obvious thing. They pulled out the steam engine, dropped in one large electric motor, and kept the driveshaft and the belts. Group drive. Same layout, same limits. Almost no productivity gains.
The gain came from putting a small motor in each individual machine. Power stopped dictating position. Machines could finally be arranged in the order the work actually happened, buildings could go single-storey and wide, overhead cranes became possible, and one machine breaking stopped being a floor-wide event. That needed new buildings, not retrofits, which is why the payoff waited for the old plants to wear out.
David also makes a measurement point worth keeping. Productivity statistics were built to count manufacturing output, and the largest effects of both electricity and computing landed in services, where output is badly measured. So part of the productivity paradox is real lag: the payoff genuinely had not arrived yet. And part of it is that the instruments could not see the payoff that had.
Both technologies got bolted onto the existing shape, produced nothing for decades, and only paid off when someone redesigned the structure the old cost had justified.
| Phase | Electric motor1882–1920s |
Computer1960s–1990s |
|---|---|---|
|
Before
The old cost
|
Distributing power was expensive. One engine, one driveshaft, belts to every machine. Machines had to stand where a belt could reach them. Buildings went vertical. The whole plant ran or none of it did. Layout was dictated by physics, not by the work. | Moving information was expensive. Forms, carbon copies, internal mail, a report compiled monthly. Most decisions need information from several places at once, and the only place those streams met was further up the hierarchy. So decisions were made where the information converged, not where it started. Middle management existed largely to collect and pass on. Inventory was a buffer against not knowing. |
|
The trap
Bolt it on
|
Group drive. Steam engine out, one large electric motor in, driveshaft kept. Everything else unchanged. Roughly thirty years of minimal measured gain. | Computerise the existing process. Terminals in accounting, same approval chain, same forms, same handoffs. Barcode scanners producing a report that a person still reads. In 1987 the economist Robert Solow summed up the era: you could see computers everywhere except in the productivity numbers. |
|
The gain
Redesign the structure
|
Unit drive. A motor per machine. Machines arranged in the order the work happens. Single storey, wide span, natural light, overhead cranes. Machines run independently, so one breaking no longer stops the floor. Moving material around became the new design problem, which is where the moving assembly line comes from. | Work reorganised into cross-functional teams instead of functional handoffs. Training investment rose sharply. Inventory shrank because information replaced it. Coordination got cheap enough to change what counted as inside the company at all, which is where outsourcing and offshoring come from. |
A list of structures that only exist because something used to cost money.
The middle column is not a hit list. Some of those structures also serve human needs: alignment, trust, shared understanding, a regular moment to look at reality together. Those reasons survive the cost collapse. The work is separating the two, one structure at a time.
And most companies skip the third column because the first one is more fun. The third column is where the actual design work is.
The cost of building the thing twice. A spec is a prediction about something too expensive to make and throw away.
When a working, disposable version costs an afternoon, the product decision stops being "read this and imagine it" and becomes "here are three, use them." Shrink the written story to a sentence plus a link to something clickable. Prototypes replace prediction.
The cost of engineering time. Turning an idea into something buildable required an engineer in the room, and that time was scarce.
Most of it goes. What remains is not a grooming session but a decision: is this worth building at all. Keep the conversation where alignment genuinely needs it, drop the part that was only translation.
Uncertainty about how long something takes, back when human effort reliably predicted it.
That predictor has broken in both directions: some work collapses to an afternoon, some takes longer because someone is now debugging code they did not write and do not understand. The spread got wider, so the estimate carries less information than before. Worse, velocity will inflate and someone will read that as proof the investment worked. Replace it with cycle time from decision to production, and throughput of outcomes rather than tickets.
The cost of writing. When writing was expensive and reading was cheap, a human reading carefully was a sensible gate.
Flip that cost and the gate becomes the driveshaft: still there, still deciding how everyone else has to arrange themselves, and no longer doing the job it was built for. The answer is not "review less." It is making correctness machine-checkable: real test suites, contract tests at service edges, monitoring sharp enough to see breakage in minutes, feature flags, small reversible deploys. Approval moves from someone who understands the change to someone who can undo it.
The cost of deciding what to build. A team of seven could only make so much, so one person could keep up with deciding what they made.
Multiply production capacity and that person becomes the bottleneck. Move product decision rights into the team: the Product Owner frames problems and sets outcome boundaries, team members decide what to build inside them. This is the hardest change on the list, because it is a status loss for a real person and no tooling makes it happen.
The cost of picking up context. Support escalated to engineering because only engineering could read the logs and the code.
Routing that exists purely as a knowledge gate thins out. This is the clearest place where the technology genuinely moves a decision downward. It works well for finding your way around and explaining what something does, poorly where the answer depends on history nobody wrote down, so keep the escalation path for exactly that.
The cost of depth, which took years to acquire and could not be spread thin.
Cheap shallow context widens what one person can span, but it does not manufacture depth. The plausible shape is wider spans, not deeper ones, with real specialists concentrated where the failure modes are expensive: security, data, and the parts of your domain nobody has written down. Low confidence. Nobody has run this long enough to know.
The cost of reading source, which was slow.
Documentation that describes what the code does loses most of its purpose. Documentation that records why a decision was made becomes more valuable, not less, because it is the one thing that cannot be reconstructed from the code itself. Kill the first kind. Fund the second.
The cost of limited build capacity. You could only make so much, so you queued the rest.
The backlog stays. You still need somewhere to hold what is not being worked on, and it is still where you argue about priority. What changes is what protected you from overload: it was never the backlog, it was the limited capacity sitting behind it. Take that away and work floods in, more gets started and less gets finished. So the backlog now needs a hard work-in-progress limit next to it. If you keep one thing from Kanban, keep that.
That question puts the technology in the subject position, which is exactly the move that gave the 1980s two decades of computer investment and no measurable productivity gain.
The company does not get redesigned to leverage a tool. It gets redesigned because certain costs collapsed, and the steps that existed to manage those costs are now driveshafts.
For a software company the constraint was never typing code. It is deciding what to build, trusting that what got built works, and coordinating across people. Faster generation hits none of those and floods all three. Pull requests pile up, review queues stretch, more things are in flight and fewer are done. That is the group drive outcome in its purest form, and it is the default unless the work is redesigned.
Machine-checkable correctness, fast detection, easy revert. Approval shifts from someone who understands the change to someone who can undo it. This is a serious infrastructure spend, and it is exactly the line item that gets cut when the gains are supposed to appear this quarter.
The person deciding no longer needs an engineer's time to see the option. A decision that used to wait for information to travel to a meeting now happens where the information already is.
Not as a value statement. As a consequence: if you triple what a team can produce and leave one person deciding what it produces, you have built a human driveshaft.
The tasks juniors learned on are the automated ones. Pairing gets quietly abandoned because everyone feels like they are already pairing. Put junior people on debugging, integration, incident response and verification early, and protect human pairing as a practice rather than reclaiming it as efficiency. Get this wrong and you stop producing senior engineers without noticing for four years.
Two different roles that behave very differently when you remove them.
The first role is carrying information. Production tells support, support tells the Product Owner, the Product Owner tells the team. Each hop costs days, and detail gets lost along the way. That role is pure overhead, and removing it is the whole point of the exercise.
The second role is deciding what counts as good. That one is not a bottleneck. It is the standard the loop steers by, and a loop without it does not run on its own: it just improves whatever it happens to be measuring.
Error and crash rates, latency, cost per request, funnel completion, support ticket clustering, and explicit success criteria attached at the moment the change ships. If the criterion is not written down when the change goes out, the loop has nothing to close on.
Feature flags, canary at one percent, automatic rollback on breach, blast radius caps, a limit on how many automatic changes are in flight. Autonomy scales with revertibility, not with confidence.
Get this wrong and nothing else in the loop matters, which is why this is where the money goes. The loop can never be better than the tests it is judged by. A weak test suite produces a system that gets very good at passing weak tests. Property-based tests, contract tests, replayed production traffic, a regression corpus built from every past incident.
A record of every automatic change — what changed, why, and what triggered it — plus a rate limit that keeps the system inside the range a person can still make sense of if it goes wrong.
Stated in variety terms of the Viable Systems Model: if you amplify the variety of the operational units without amplifying the variety of the regulator, you do not get a faster system. You get an uncontrolled one.
Everyone says human-in-the-loop as though it settles the question. It does not. It names a fear and a real constraint at the same time, and those pull in opposite directions.
Every human checkpoint is a hop that costs days. The loop only pays off when it closes without waiting for someone.
Someone has to answer for what shipped. Not a feeling: a legal, contractual and reputational fact that does not automate.
The useful move is to stop arguing about whether humans stay in and ask which loop they are in. Out of the fast one, where the question is whether the system still works. Firmly in the slow one, where the question is whether the thing is worth building and who answers for it.
If you actually take that seriously, the shape of the company changes. These are the pieces that keep showing up when people work it through, along with the two endpoints the logic runs toward if you follow it all the way.
The setpoint has to be explicit, because nothing downstream supplies it any more. Vague direction used to be survivable: people filled the gap with judgment. Now it just gets amplified.
Not a wiki nobody reads. The written record of decisions, constraints and domain rules becomes an operational input, so it gets maintained like code rather than like documentation.
Team size was partly a response to expensive handoffs between specialists. Make context cheap and the natural unit may be two or three people with a much wider span.
Depth stops living inside every team and concentrates where failure is expensive. Teams reach for it rather than staffing it.
Someone whose work is composing and supervising the loop rather than producing inside it. Genuinely new, and nobody knows yet whether it is a role or a phase.
Follow smaller teams and outsourced depth far enough and the company of one stops being a lifestyle choice and becomes a viable operating model for real products.
If producing a version costs an afternoon, the economics that forced standard products weaken. Individualised pricing is the first visible edge of that.
This section is the most speculative on the page. It is reasoning forward from a cost change, not evidence. Nobody has run a company this way long enough to know which parts survive.
The first one fails loudly, so you will catch it. The other two fail quietly, which is the problem.
Charles Goodhart, an economist, made the general point in 1975: once a measure becomes a target, it stops being a good measure. Here that looks like the loop improving latency by quietly skipping the expensive correct path, or getting the test suite green by deleting the failing test. Already well documented in agentic coding. You will catch this one, because it fails loudly.
The more the loop handles, the fewer people hold a working model of the system. Those are exactly the people you need when it fails: in the situation hardest to diagnose, with the least recent practice. Same shape as the apprenticeship problem, one level up.
Closed loops improve what they can see quickly. Latency, errors and conversion get optimised. Security posture, maintainability, coupling, user trust and whether the product still makes sense get traded away invisibly, because no signal arrives to object. A tight loop does not merely fail to protect those slow variables. It spends them. The only counter I know is to measure them deliberately and give them veto power on a slower cadence.
Both are true, and the gap between them is where most AI measurement goes wrong.
Attribution is the first problem. Revenue moves for a dozen reasons at once: market, pricing, a good hire, a competitor stumbling. Below a few hundred people you will never cleanly isolate what the technology contributed. So people fall back on the cost side, and that is where the fake maths lives. Four hours saved per week, times seventy people, times sixty euros an hour, equals a million. Nobody ever sees that million.
Saved hours become money exactly two ways: a role is not backfilled, or the freed capacity goes into something that produces revenue. If neither happens, the hours dissolve into slack, longer meetings and more polished documents nobody asked for.
Second problem: money lags. By the time it shows in the profit and loss statement you cannot steer any more. You need leading indicators that plausibly cause the money, which means naming the mechanism before you measure. Not "AI made us more productive" but "claims processing cycle time drops from six days to two, which lets us stop paying the overflow vendor." That is a testable sentence. Most AI business cases cannot produce one.
Third: gains anywhere other than the constraint are decoration. If your bottleneck is decision-making at the leadership level, making marketing generate copy three times faster produces work in progress and nothing else.
And treat self-reported productivity gains as worthless. A 2025 METR study found experienced open-source developers were roughly 19 percent slower on tasks in their own repositories while believing they had been about 20 percent faster. Sixteen people, so do not overweight it, but the direction matters. Against that, the Brynjolfsson, Li and Raymond call-centre study found around 14 percent more issues resolved per hour, concentrated heavily among novices. Both can be true: help where the task is well-defined and the person is inexperienced, harm where the work is ambiguous and the person already holds deep context.
Which decision in your company is still waiting for information to travel to someone?
That is the whole audit in one sentence. Then ask the harder second question: what would have to be true for that decision to happen where the information already is, and what breaks if it does. The real answers live in the second one, because that is where accountability, liability, trust and status turn up.
If nothing about who decides what changes, expect the group drive outcome. A new motor, the same building, and thirty years of waiting.
A session with your leadership team. We go through the three columns for your company, not a generic list: what actually got cheap, what you built to keep that cost low, what got harder. Half a day. You leave with the structures named.
Redesign the structure that is actually in the way. Not all of them. The one holding everything else in place. Who decides what, which meetings survive, where approval moves to. Concrete enough to try on Monday.
Baseline three workflows. So that in three months you can tell whether it worked, instead of arguing about whether it feels faster.
Manuel Küblböck. I design organisations for a living: twelve years of it, in tech companies scaling from twenty-five to five hundred people.