Efficiency Is Not ‘Faster and More’

Efficiency is not how much activity a system produces. It is how reliably the system turns a real need into a good outcome, without creating avoidable work along the way.

That distinction matters whenever an engineering team celebrates more tickets closed, more deployments, more model calls, or more features shipped. Each number can rise while customers wait longer, defects accumulate, and unfinished work expands. A busy system can be an inefficient system.

The two pages that prompted this essay come from Taiichi Ohno’s Toyota Production System: Beyond Large-Scale Production. On printed pages 64–65, at the transition into “Getting Away from Quantity and Speed,” Ohno reads Henry Ford against the later cult of mass production. His provocative claim is that efficiency cannot be reduced to quantity and speed. The deeper target is overproduction: making something before it is needed, or making more than the next part of the system can use.

The claim is powerful, but “quantity and speed never matter” would be too absolute. They matter when demand is real and capacity is the constraint—the step that limits the whole system’s result. The useful question is therefore not “Should we go fast?” It is:

Imagine a team changing a checkout service. A customer needs a payment to complete. Engineers choose a method, perform the work, and deliver a result. This is the smallest system worth calling efficient.

The customer need pulls work into the method. The result counts only when it is both needed and good. A fast change that nobody needs is not value. A needed change that fails in production is not a good result.

This definition changes the unit of measurement. Instead of asking how many tasks moved, ask whether the customer’s problem was solved, how long the whole journey took, and what the journey consumed.

Ohno’s example reaches back to Henry Ford and Samuel Crowther’s 1926 book Today and Tomorrow. Ford described an established material choice—cotton cloth—and then asked, “Is cotton the best material we can use here?” His team investigated flax rather than treating the inherited choice as a law.

The durable lesson is not that flax is always superior. It is that improving an accepted process is sometimes weaker than questioning the premise that created the process. A team can automate a bad default, scale it, and make the wrong work impressively cheap.

In software, the equivalent questions are often uncomfortable:

• Why does this report exist at all?
• Why must every request pass through this approval?
• Why are we optimizing a batch job instead of removing the batch?
• Why are we adding capacity before checking whether retries, duplication, or unused output create the load?

This is via negativa in engineering: first look for work that can be removed. Only then optimize what remains.

Now add a common management intervention: a quantity-and-speed target. The target pushes the method to produce more. If customer need does not rise at the same rate, output has somewhere else to go.

The original path still exists. The new path explains the danger. A quota pushes work whether or not demand pulls it. Surplus is not limited to physical stock: it can be unused features, queued pull requests, speculative abstractions, unread dashboards, excessive cloud capacity, or decisions waiting for an overloaded reviewer.

Surplus is deceptive because it looks like progress at the producing step. The cost appears later as storage, coordination, rework, expiry, context switching, or a longer wait for the one item that matters.

Ohno’s argument becomes especially visible when growth slows. Strong demand can absorb excess output and hide weak coordination. When demand falls, unfinished and unsold work remains in view. The system did not suddenly become wasteful; the slower market merely stopped concealing the waste.

Toyota’s current explanation of Just-in-Time—coordinating production around downstream need—says production should make what is needed, when needed, in the needed amount, while keeping goods and information flowing and matching the pace of sales. It also treats speed as a customer outcome: shorter lead time, the elapsed time from need to delivery, rather than a command to maximize every machine’s output. That combination is important: Toyota’s own description joins flow, demand, quality, cost, and timely delivery.

The objection to Ohno’s rhetoric is simple: sometimes the system really is too slow. Throughput—the rate of completed results—can be the problem.

If 1,000 valid checkout requests arrive each minute and the service can complete only 600, the queue grows. If a hospital needs blood, a disaster area needs clean water, or a security team must patch an actively exploited vulnerability, producing more useful output sooner is not managerial vanity. It is the requirement.

Quantity also creates information. Repetition can reveal variation, stabilize a process, justify specialized equipment, and spread fixed costs across more useful units. A small batch is not automatically efficient if setup dominates the work. Nor is unused capacity automatically virtuous: capacity that customers urgently need but cannot access is a real loss.

Even Toyota’s position is not “be slow.” Its public account says the system aims to shorten lead times and deliver quickly, cheaply, and at high quality. The argument is against speed detached from need and system health, not against speed itself.

The pro-throughput side therefore wins under three conditions:

1. Demand is verified. A real customer or downstream process can use the additional result now.
2. The constraint is known. Increasing this step’s capacity improves the end-to-end result rather than filling another queue.
3. Integrity is preserved. Quality, safety, worker health, and recovery do not deteriorate or merely become someone else’s problem.

Without those conditions, “go faster” is an untested theory wearing the costume of a target.

The disagreement cannot be resolved by slogans. Add evidence from the whole flow: demand, lead time, unfinished work, defects, and human strain.

Evidence distinguishes a useful speed increase from a local optimization. If completions rise while customer demand absorbs them, lead time falls, quality holds, and unfinished work does not grow, speed is helping. If output rises while queues, defects, or strain rise, the producing step has improved its score by making the system worse.

No single metric is enough:

Measurement matters only if it changes a decision. The completed model uses evidence to choose among improving the method, reducing incoming work, or adding capacity at the actual constraint.

The feedback loop prevents either camp from becoming dogma. “Lean” cannot excuse chronic under-capacity when customers are waiting. “Scale” cannot excuse producing defects, inventory, or exhaustion faster.

For the checkout team, the practical sequence is small:

1. Define demand in the customer’s unit: successful, correct checkouts—not commits, tickets, or CPU utilization.
2. Record the current arrival rate, completion rate, end-to-end lead time, unfinished work, failure and rework rate, and operator interruptions.
3. Identify the step that limits the whole result. Do not assume the busiest step is the constraint.
4. Change one thing: remove unnecessary work, reduce batch size, improve the method, or add capacity at the constraint.
5. Compare the same measures. Keep the change only if the needed result improves without unacceptable transfer of cost or risk.

Here is the reusable rule:

Accelerate when verified demand is waiting at a known constraint and downstream can absorb good output. Reduce, stop, or redesign work when unfinished output, defects, delay, or strain grows faster than customer value.

Source trace. The supplied screenshots show printed pages 64–65 of Taiichi Ohno’s 1988 English edition of Toyota Production System: Beyond Large-Scale Production, including the beginning of “Getting Away from Quantity and Speed.” The captures do not show a PDF page counter, so no separate PDF page is claimed. Ohno is interpreting passages from Ford and Crowther’s Today and Tomorrow, first published in 1926. The cotton-and-flax discussion belongs to its chapter “Learning by Necessity.”

Adaptation. The diagrams above are a conceptual reconstruction of the argument using a software-delivery example. They are synthetic teaching models, not Toyota factory maps, digitized measurements, or evidence that one named software process will behave this way.

Limits. Two pages can establish Ohno’s argument, but they cannot establish the performance of every pull system, the technical superiority of one textile, or a universal optimum batch size. Context determines capacity, setup, safety stock, and acceptable risk.

Falsification test. This essay’s thesis would fail in a specific case if raising a step’s quantity or speed, without changing demand, reliably improved the customer’s end-to-end result while quality, unfinished work, total cost, resilience, and human strain remained no worse. In that case, the supposed local optimization was system efficiency after all.

The point is not to make slowness virtuous. It is to refuse a cheaper definition of progress. The best system is not the one moving fastest. It is the one that can explain what its speed is for—and prove that the answer reaches the customer.