Monday Myth: A Faster Machine Produces More

The Machine Everyone Wants

Walk through an industrial plant and some machines announce their importance immediately. They are large, expensive, fast and surrounded by the unmistakable evidence of capital investment: motors, conveyors, control cabinets, cooling systems, safety barriers and screens reporting quantities with reassuring precision. Somewhere nearby, another machine performs a slower and less theatrical operation. It drills a hole, cures a coating, performs an inspection or waits for temperature to stabilise. Nothing about it looks particularly impressive.

Suppose the first machine produces one hundred components per hour. A new model can produce three hundred. The arithmetic appears irresistible. Three times the capacity, perhaps with fewer operators and lower energy consumption per component. The investment case practically writes itself.

The new machine arrives. Engineers install it, commission it and gradually bring it towards its rated capacity. Soon its production figures look magnificent. Its utilisation climbs. The cost per component falls. The dashboard confirms that the investment delivered precisely what the manufacturer promised.

There is only one awkward detail. The factory still ships forty finished products per hour.

Nothing has gone wrong with the machine. That is precisely the problem. It performs exactly as expected. The mistake occurred somewhere else: in assuming that the performance of a component could describe the performance of the system containing it.

Industrial engineering has spent a very long time discovering how expensive that assumption can become.

When Machines Become a System

A factory stops behaving like a collection of machines as soon as the output of one operation becomes the input of another. From that moment, capacities interact. One station can starve because its predecessor cannot supply material quickly enough. Another can become blocked because the next operation cannot accept its output. Buffers appear between processes. Material waits. Variability propagates. A breakdown somewhere seemingly unimportant can eventually silence equipment hundreds of metres away.

Consider five operations capable of processing 100, 80, 40, 70 and 90 units per hour. Look at them individually and the first station appears productive, the fifth respectable and the third rather disappointing. Look at the production line and the numbers acquire another meaning. Unless inventory can accumulate indefinitely, the system cannot sustain a flow greater than its constraining operation.

Replacing the 100-unit machine with one capable of 300 units per hour therefore creates an interesting form of success. The machine improves dramatically while the factory barely changes.

If management insists on exploiting its new capacity, something else changes instead. Components begin accumulating before the slower operations. Pallets occupy floor space. Material gets moved, counted, stored and moved again. Defects can hide inside larger batches. More capital sits between raw material and finished goods. Supervisors discover that keeping a machine busy and moving a product through a factory are not remotely the same activity.

The factory has not converted additional speed into additional throughput. It has converted it into inventory. This is where the apparently simple question of productivity starts becoming a systems problem.

The Mathematics of Waiting

John Little formalised one of the most useful relationships in queueing systems with an equation remarkable for how little it asks us to know:

L = λW

In a stable system, the average number of items inside it equals the average rate at which items pass through multiplied by the average time an item spends there.

For a factory, the relationship can be read almost conversationally:

Work in progress = Throughput × Lead time.

If forty finished products leave every hour and a product spends an average of five hours travelling through the production system, approximately two hundred products will exist somewhere inside that system on average. Some are being transformed. Others are travelling. Many are simply waiting.

Now return to the new machine.

If downstream capacity still limits completed production to forty units per hour, making the first operation three times faster does not magically alter the relationship. Feed more unfinished material into the same constrained system and work in progress starts increasing. If throughput remains roughly constant while inventory grows, average lead time grows with it.

The faster machine can therefore contribute to a slower product.

There is an important qualification here. Little's Law describes stable systems. If material enters permanently faster than the system can discharge it, no stable larger queue eventually appears. The queue simply continues growing until something intervenes. Production gets throttled. Storage fills. Work gets discarded. Another capacity gets added. Or the system begins behaving in increasingly unpleasant ways.

The distinction matters because organisations often describe excess capacity as an unconditional advantage. From the perspective of the individual machine, it often is. From the perspective of the system, capacity only acquires meaning through its relationship with flow.

This distinction lies close to the heart of systems thinking. A component has properties. A system has behaviour. The second cannot reliably be inferred by adding together the first.

The Constraint Does Not Disappear

Improving the constrained operation can transform a production system. If the forty-unit station genuinely limits throughput and engineers increase its sustainable capacity to sixty, the factory may indeed ship substantially more.

But something interesting happens immediately afterwards. The constraint moves.

Perhaps the station capable of seventy units per hour now limits production. Perhaps inspection becomes saturated. Perhaps packaging cannot keep pace. Perhaps the loading dock becomes the problem. Perhaps the factory can manufacture sixty products per hour but customers only absorb forty-five.

Removing a constraint does not create a system without constraints. It reveals the next one.

This matters because optimisation changes the system being optimised. Yesterday's dominant problem may disappear precisely because yesterday's intervention worked. Continuing to optimise the same place after the constraint has moved produces diminishing returns, then useless capacity, then queues.

Systems thinking therefore asks a more difficult question than whether an intervention improves something. It asks what happens to the behaviour of the whole after that thing improves.

That question becomes particularly important when an improvement arrives suddenly.

A Remarkably Fast New Machine

Software engineering has recently acquired one.

Generative AI can accelerate parts of software production dramatically. It can generate implementations, tests, migrations, documentation and alternative solutions in fractions of the time previously required. For some tasks the improvement is modest; for others it is extraordinary. Arguing that this acceleration does not exist requires ignoring what engineers can already observe at their desks.

But the existence of local acceleration tells us nothing yet about system throughput.

An engineering organisation contains its own sequence of transformations. An idea has to become sufficiently understood to justify work. Product decisions have to resolve ambiguity. Architecture constrains possible implementations. Code gets produced, reviewed, integrated and tested. Changes move through deployment mechanisms. Operational behaviour provides feedback. Customers encounter the result and eventually reveal whether anybody created value.

Coding occupies an important position inside that system. It does not constitute the system.

If producing an implementation once required two days and now requires two hours, the machine has unquestionably become faster. What happens next depends on what constrained the flow before the improvement and where the constraint moves afterwards.

Perhaps engineers had genuinely spent most of their time translating well-understood intent into code. In that environment, AI can release substantial system capacity.

But perhaps product decisions already arrived slowly. Perhaps architectural dependencies required coordination across teams. Perhaps code review struggled to keep pace. Perhaps test environments remained unreliable. Perhaps releases required cumbersome approval. Perhaps customers needed weeks to validate whether a change solved anything useful.

Accelerating implementation does not remove any of those constraints automatically. It may simply feed them faster.

Digital Inventory Still Occupies Space

Factories make excess inventory difficult to ignore. Steel takes space. Components require racks. Pallets obstruct aisles. Warehouses cost money. Somebody eventually notices when unfinished material starts occupying the building.

Software inventory enjoys better camouflage.

A pull request waiting three days for review occupies no warehouse. A feature completed behind a flag creates no pallet. An architectural decision waiting for another team does not block a forklift lane. Partially integrated functionality can sit quietly inside repositories, branches, ticketing systems and staging environments while every dashboard continues displaying reassuring quantities of activity.

Yet these objects remain work in progress.

Code waiting for review is inventory. Reviewed code waiting for integration is inventory. Integrated functionality waiting for validation is inventory. Released capability waiting for meaningful customer adoption may represent inventory at an even larger system boundary.

Once implementation becomes cheaper, producing more of this inventory becomes easier.

This creates an uncomfortable possibility. An organisation can successfully increase developer productivity while simultaneously increasing its delivery lead time.

Little's Law has not stopped applying because the pallets became pull requests.

If useful throughput remains constrained downstream while the rate at which candidate changes enter the system rises dramatically, queues grow somewhere. Reviewers receive more work. Test systems process more changes. Integration conflicts multiply. Product managers face more decisions. Operational complexity increases. Engineers spend more time understanding code they did not write, including code that nobody spent very long writing in the first place.

The new machine works perfectly. The factory fills with inventory.

When Measurement Draws the Wrong Boundary

The problem becomes harder to see when organisations measure productivity around the intervention itself.

Buy an AI coding tool and measuring adoption feels reasonable. Tokens consumed increase. Suggestions accepted increase. Code generation rises. Estimated engineering time saved rises. Each number may describe something real.

But every measurement implicitly draws a boundary around a system.

Draw the boundary around code production and AI may produce astonishing gains. Draw it around development through deployment and the gain may look different. Draw it around idea through reliable customer adoption and it may change again.

None of those measurements necessarily contradicts another. They answer different questions about different systems.

The danger begins when a local measurement gets interpreted as evidence about a larger boundary.

A factory manager would recognise the mistake immediately if somebody announced that plant productivity had tripled because one machine now produced three times as many components. The obvious questions would concern finished throughput, inventory, lead time, quality and the capacity of downstream operations.

Software organisations can somehow forget to ask the equivalent questions when the machine happens to generate code.

Worse, the measurement itself can create a feedback loop. If AI adoption becomes evidence of successful transformation, people have an incentive to increase AI usage. Usage rises, dashboards improve and management receives confirmation that its intervention worked. The organisation can generate progressively stronger evidence of adoption without establishing whether more valuable capability reaches customers.

The map becomes increasingly detailed while the territory remains stubbornly unchanged.

What the Faster Machine Reveals

There is another possibility, and it may prove considerably more interesting than the productivity claims surrounding AI.

For decades, software organisations have treated coding as the central productive act around which everything else revolves. There were good reasons. Code was expensive to produce, skilled engineers were scarce, and translating ideas into reliable executable systems consumed substantial human effort.

When one activity dominates cost and attention for long enough, organisations begin constructing their understanding of the entire system around it.

Then someone makes that activity dramatically cheaper.

Suddenly the surrounding constraints become difficult to ignore.

A requirement that takes three weeks to clarify looks different when implementation takes an afternoon. A five-day review queue looks different when the code took forty minutes to generate. A monthly release process looks increasingly peculiar when candidate changes appear continuously. Organisational dependencies previously hidden behind the natural pace of implementation become visible because implementation no longer masks them.

AI may therefore perform an unintended diagnostic experiment on software organisations.

It removes resistance from one part of the system and allows us to observe where pressure accumulates next.

Some organisations will discover technical constraints. Others will discover architectural ones. Many may discover that their principal limitations never belonged to software production at all. Decision latency, unclear ownership, conflicting priorities, organisational boundaries, risk mechanisms and the simple difficulty of deciding what deserves to exist may emerge from behind a bottleneck we had conveniently called engineering capacity.

The faster the machine becomes, the harder the constraints become to disguise.

The Loading Dock

Imagine returning to our factory a year after the new machine arrived.

It still runs beautifully. Its control panel reports extraordinary utilisation. Cost per component has fallen. Operators have become remarkably efficient at feeding it. Management can produce graphs proving that the investment transformed the performance of that operation.

Elsewhere in the building, engineers have added racks for the additional inventory. Supervisors have introduced processes for prioritising which batches move next. More people now coordinate the growing queues. Somebody has built a dashboard to provide visibility over the unfinished material. Meetings discuss why downstream operations cannot absorb everything the machine produces.

Each intervention makes sense when viewed from sufficiently close range.

At the far end of the factory stands the loading dock.

That boundary cares very little about how quickly any individual machine moved, how busy every station remained, how much material crossed the factory floor or how impressive the utilisation dashboard became. It records something much less sophisticated: what successfully completed the entire journey.

Every evening, forty trucks still leave the gate.