Skip to content
Latticework
Esc
Try
No. 108AI Systems

The Dynamo Lesson (Productivity Paradox)

A general-purpose technology pays off only when work and organisation are redesigned around it, and that takes years; dropping it into the old layout gives little.

“You can see the computer age everywhere but in the productivity statistics.”

Factories gained little from electricity until they were redesigned around it; AI's value arrives the same way, after the work changes.

To an executive

Electricity took decades to raise factory productivity because factories first kept their old layout. AI pays off when we redesign how work is organised, and that takes time.

To an engineer

Treat AI as a new power source, not a faster part. The gains need complementary changes in data, process and team structure, so plan for those, not just the model.

The idea

In 1987 the economist Robert Solow, reviewing a book in the New York Times Book Review, wrote: "You can see the computer age everywhere but in the productivity statistics." Businesses had invested heavily in computers, yet productivity growth had slowed.

In 1990 the economic historian Paul A. David pointed out that this had happened before. Electric power was available to factories from the 1880s, but American manufacturing productivity surged only in the 1920s, decades later. At first, factories swapped the central steam engine for one large electric motor and kept everything else: the line shafts and belts running through the building, the multi-storey layout, the work organised around a single power source. The gain was small.

The pay-off came when factories moved to unit drive, a small motor on each machine. That freed the layout: single-storey buildings, machines arranged in the order of the work, and new ways of organising labour. The value came from redesigning the factory, not from the motor. David argued that computers would follow a similar path, and that the lag was an expected part of moving to a general-purpose technology.

Why it works

General-purpose technologies need complementary changes. Electricity, computers and AI change what is possible across many activities, but each activity has to be redesigned to use them. Until then, the new technology runs inside the old constraints.

Existing investment slows the change. Factories with working steam systems and buildings designed around them had little reason to start again. Enterprises with hundreds of applications, established processes and org charts are in the same position.

The gains arrive late and unevenly. Learning, new skills and redesigned organisations take years, and the benefit shows first in the organisations that redesign earliest. Measuring too soon, or per task, can make a real shift look like failure.

Where it applies

  • Enterprise AI strategy, where pilots add assistants to existing roles and processes and the expected productivity gain does not appear.
  • Business cases and stakeholder expectations, to explain why value lags spending and what must change for it to arrive.
  • Data and integration foundations, the line shafts of today: fragmented knowledge and duplicated data that stop AI being used across the work.
  • Operating model design, where teams, roles and decision rights are still organised around the old way of working.

How to apply

  1. Name the steam engine. Identify where AI is being used as a drop-in replacement for an existing step, role or tool.
  2. Find the line shafts. List the constraints that the old setup imposes: data silos, hand-offs, approval chains and team boundaries shaped around systems.
  3. Plan the unit drive. Design the complementary changes, such as shared data, redesigned processes, new roles and skills, and fund them alongside the AI itself.
  4. Set expectations for the lag. Agree leading indicators (adoption, redesigned processes, cycle time) that show progress before the productivity figures move.

Example scenario

A manufacturer's AI programme gave every office worker an assistant and ran forty pilots. A year later, surveys showed people liked the tools, but the operating figures had not changed. Order-to-cash still took the same time, because orders still passed through the same five systems and four teams.

The enterprise architects reframed the programme around a few value streams. For order-to-cash they consolidated customer and pricing data, redesigned the flow so one team owned an order from quote to invoice, and gave AI the job of checking orders against contracts. They told the board to expect process and adoption measures to move within months, and cost and cycle-time figures later.

Questions to ask

  • Are we replacing the steam engine with one big motor, adding AI to the old structure, or redesigning the work around it?
  • Which complementary changes (data, processes, roles, skills) have to happen before this AI investment can pay off?
  • What would tell us we are in the lag before the gains, rather than on a path that will never pay?

When not to use it

  • Narrow, well-defined automation, where a tool replaces one task and the gain is immediate and measurable.
  • As an excuse for no results, when nothing is being redesigned; the lag only applies if the complementary changes are under way.

How it misleads you

The dynamo story can be used to defend any spending: the gains are always coming, just later. David's point was that the gains came after redesign, not after waiting. Hold AI programmes to evidence that the work itself is changing, and treat "it takes time" as a claim to test, not an answer.

In the wild

Further reading

Last reviewed · Suggest an improvement