Last week I posted an article built on one claim (Read it here in German). Capacity sits in a budget and waiting time sits nowhere. That is why waiting time has huge potential in speeding up development: it is largely invisible, but a large source of ineffectiveness.
Within the hour, a reader took it apart. He was right, and the claim survives anyway, but not in the shape I articulated it. Which half failed is the part worth writing down.
The objection
Oskar von Dungern, a systems engineer who has spent years on collaboration standards in mechatronic development, wrote back with this:
Waiting time as such is normal and cannot be avoided. Only waiting on the critical path delays delivery. Where experts serve several projects, you get either idle experts if capacity is generous or waiting projects if capacity is tight. You can design an organization so that projects rarely wait, but that means holding considerably more expensive expertise than you need. Looking at waiting time certainly helps. It is one optimization criterion among several.
Dr.-Ing. Oskar von Dungern
Every sentence of that is correct. A queue that sits off the critical path costs nothing on the delivery date. An organization tuned so that no project ever waits for a specialist is an organization paying for specialists who are frequently idle. Waiting time is not waste by definition, and treating every queue as an enemy produces a different and equally expensive failure.
So the claim was too broad. It implied that waiting is bad, and waiting is not bad. It is a symptom whose meaning depends on where it sits.
The critical path does not hold still
But here we must not simplify too much: the reaction to “just manage the critical path” is right in principle and dangerous in practice.
In construction, the critical path is computable in advance and reasonably stable. You know the dependency graph, the durations are estimated from work that has been done many times before, and the path you calculate in month one is close to the path you observe in month nine.
Product development does not behave this way. The dependency graph and the durations both change as the program learns. A thermal test invalidates a packaging assumption, and a subsystem that had six weeks of slack is suddenly the thing everyone waits for. A supplier interface turns out to be less stable than the interface document claimed. The critical path is not a property of the plan. It is a property of what you currently believe, and belief updates.
The critical path is a hypothesis that updates over time.
That has an uncomfortable consequence. If you manage only the queues that sit on today’s critical path, you are permanently one discovery behind. The queue that hurts you is the one that was harmless the last time you looked.
There is a sharper version. Waiting off the critical path is not free. It is spent slack. Slack is exactly what lets a path absorb a surprise without moving the delivery date. A stage sitting in a long queue has already consumed that buffer, so on the day it moves onto the critical path it moves the date immediately, with no absorption at all. The cost was incurred earlier and invoiced later.
This is the same structural blindness described in Conway Drift, where the organization and the architecture decouple gradually and no single decision feels wrong. Nothing is visibly broken until coordination cost arrives all at once.
The utilization trap
The capacity argument deserves a real answer rather than a concession, because the tradeoff Oskar describes is genuine and the exchange rate is not what most organizations assume.
There is a reason organizations create shared specialists in the first place: division of labor works. A thermal expert who supports five projects can develop deeper expertise and be used more economically than five thermal experts embedded in five teams. The alternative to waiting is therefore not simply “better flow.” Eliminating every dependency would also eliminate some of the economic benefit of specialization.
The problem starts when the gains from specialization are evaluated through utilization while the resulting coordination and waiting costs remain invisible. Division of labor creates dependencies by design. Those dependencies create queues. The question is not whether to eliminate them, but whether the benefit of specialization exceeds the delay it introduces.
Division of labor works. But division of labor also creates dependencies, which in turn creates queues.
Queue time does not rise in proportion to load. It rises disproportionately as a resource approaches full utilization. Donald Reinertsen worked this out for product development in The Principles of Product Development Flow, and the shape of the curve is the important part: moving a shared specialist from ninety five percent loading to eighty five percent buys a large reduction in queue time for a small amount of idle capacity. Moving from eighty five to seventy five buys much less.
So the tradeoff is real and it is also asymmetric. Most organizations sit on the steep side of that curve, where a modest buffer buys a disproportionate reduction in waiting, because idle time looks wasteful on a report and queue time does not appear on any report at all. Loading people to near-full capacity because idleness is visible, while the resulting queues destroy responsiveness, is common enough to have a name. The utilization trap.
What actually survives
Strip out what the objection killed and this is what is left standing.
Every organization I work with can tell me its capacity. Headcount, loading, the cost of a specialist day, the size of the request queue for the test bench. These numbers exist because someone had to budget them.
Almost none of them can tell me their waiting time. Not the total, not the split between active work and waiting for a single feature, not which of that waiting sat on the critical path at the time.
That is the asymmetry, and it does not depend on whether waiting is waste. Oskar’s tradeoff between expensive idle expertise and delayed projects is a legitimate economic decision. It requires both numbers. When only one of them exists, the tradeoff still gets made, every day, by default. It just never gets made deliberately.
Which gives a better claim than the one I posted out:
Waiting is not waste. Unmeasured waiting is a decision nobody made.
A diagnostic that survives the objection
Take one feature you shipped last year. A real one, with dates.
Reconstruct its calendar time from first request to delivery, and split it into active work and waiting. Then, for each stretch of waiting, ask two questions rather than one.
Was this on the critical path at the time?
Would it be on the critical path if the same feature ran through your organization today?
Most organizations cannot answer the first question, because nobody recorded it. Almost none have asked the second. The second is the one that predicts next year, and the gap between the two answers is usually where the next surprise is already sitting.
If both answers come back no for every queue you find, your waiting time genuinely is one criterion among several, and you can go optimize something else with a clear conscience. That result is rare enough that I would like to hear about it.
Why this should bother anyone running an engineering system
The objection was better than the claim it attacked, which is the argument for publishing claims that can be attacked at all. A method that cannot be pushed back on is not a method. It is a slogan with a diagram.
But notice what the correction did not do. It did not rescue anyone. If you cannot say how much of your last delivery was spent waiting, you are not making Oskar’s tradeoff between expensive capacity and delayed projects. You are conceding it, quarter after quarter, to whichever number happened to be visible on a dashboard.
The uncomfortable part is that the fix is not a transformation program. It is one reconstruction of one feature, done honestly, with the waiting written down next to the work. Most organizations have never done it once.
I spend the first day of the Product Velocity training at oose in Hamburg on exactly that reconstruction, using a case the participants bring with them. That seminar runs in German on 21 and 22 September. As many readers are neither German speakers nor near Hamburg, this rules out most readers of this post.
What does not rule anyone out: run the diagnostic above on one feature and write to me with the number. I am collecting them. The pattern across organizations is turning out to be more interesting than any single one of them, and Oskar’s objection is the reason I now ask the second question as well as the first.
English
German