Excerpt of my new upcoming book: Vertical Velocity!

How to Break Silos, Ship Faster, and Reclaim Engineering Joy 

The Resource Utilization Trap (The 100% Busy Fallacy)

In many corporate cultures, "slack time" is treated as an existential sin. Managers obsess over ensuring every developer is $100$ utilized. If a backend developer finishes their tasks early, they are immediately assigned another ticket. If a QA engineer has downtime while waiting for a build, they are given manual regression scripts to run.

This philosophy—maximizing resource utilization—makes intuitive sense to someone managing a factory floor. But software engineering is not a factory floor. It is not a manufacturing line of physical, predictable goods; it is a creative network of highly variable cognitive work.

Optimizing an organization for resource utilization systematically destroys flow efficiency—the percentage of time a feature actually spends being worked on, as opposed to waiting in line.

To visualize this, think of a local highway.

• When highway utilization is $50$, cars can move at the maximum speed limit. If one car changes lanes or taps its brakes, the system absorbs the variation. Flow efficiency is high.

• When highway utilization reaches $90$, traffic slows to a crawl. The slightest variation—a minor lane merge—creates a cascading shockwave of brake lights that travels miles backward.

• When highway utilization is $100$, the highway is perfectly "utilized." Every square foot of asphalt is covered by a vehicle. But the speed is $0\text{ mph}$. You have built a parking lot. No value is being delivered to anyone.

In siloed organizations, software delivery functions exactly like a $100$ utilized highway. Because every engineer is fully booked, there is zero buffer capacity. When a frontend developer needs a minor backend change to unblock their task, they cannot get it immediately. The backend developers are $100$ booked with their own sprint commitments. The request is placed in a backlog—a queue—where it sits idle, waiting for capacity to free up.

By maximizing resource utilization, we minimize delivery speed.

The Mathematics of Congestion (Kingman’s Formula)

The highway isn't just an analogy. Queueing theory gives us the exact math. Kingman's Formula (specifically Kingman's approximation for average waiting time in a single-server queue) shows why:

$$E[W]\approx \left(\frac{\rho }{1-\rho }\right)\cdot \left(\frac{C_a^2+C_s^2}{2}\right)\cdot E[S]$$

Where:

• $E[W]$ is the average waiting time (queue delay).

• $\rho$ is the resource utilization level ($0\le \rho <1$).

• $C_a$ is the coefficient of variation for arrivals (how unpredictably work arrives).

• $C_s$ is the coefficient of variation for service times (how unpredictable the work is to complete).

• $E[S]$ is the average service time (how long it takes to actually write the code).

Source: Donald G. Reinertsen, The Principles of Product Development Flow (2009)

Look closely at the first term of this equation: $\frac{\rho }{1-\rho }$. This is a non-linear relationship.

If we plot the average waiting time ($E[W]$) against utilization ($\rho$), the curve is relatively flat until it crosses the $70$ mark. Beyond $80$, the curve bends sharply upward. At $90$ utilization, the waiting time explodes. At $99$, it approaches infinity.

In software delivery, variation ($C_a$ and $C_s$) is naturally high. We rarely build the exact same feature twice, meaning we cannot precisely predict how long a task will take or when unexpected bugs will arrive.

📋 What this means: When utilization exceeds 80%, waiting time grows exponentially. The more unpredictable your work, the worse it gets.

Because our variation is high, Kingman's formula dictates that any organization operating near $90$ resource utilization will experience massive, systemic queue delays. If a feature has to traverse four different horizontal teams, and each of those teams is operating at $90$ utilization, the feature will spend over $90$ of its lifecycle waiting in queues.

Vertical feature teams solve this math problem. By bringing all necessary disciplines into a single pod, we drastically reduce the number of handoffs. When you eliminate the handoffs, you eliminate the queues, shifting your delivery speed back down to the flat, fast end of the Kingman curve.