In most companies, the decision process goes like this: If the business case is feasible and the budget exists, the project gets greenlit. The more activities running simultaneously, the more efficient the organization appears to be.
But this is a fundamental misconception.
High utilization creates the illusion of productivity while actually destroying flow. When everything is running at once, nothing moves quickly. Resources get fragmented, context-switching kills momentum, and delivery timelines stretch.
The better approach: prioritize ruthlessly based on value creation and speed to market. Finish fewer things faster rather than starting everything at once.
Efficiency should be measured in flow, not utilization. A team running at 100% utilization but delivering slowly is far less efficient than a team with slack capacity that ships value continuously.
It's not about how busy your organization looks—it's about how quickly you can deliver real value to customers.
And let's be clear: this is nothing less than a cultural transformation at the top management level. It requires leaders to let go of the comfort of "full capacity" metrics and embrace the uncertainty of flow. That's not a process change—it's a fundamental shift in how success is defined and measured.
Thank you so much, Uwe. This nails a pattern I see all the time.
Many organizations have a very clean "start" process (business case + budget = greenlight), but a very messy "finish" process. And once you keep approving new work without an equally explicit mechanism to stop or pause existing work, WIP quietly becomes the strategy.
On paper, that looks efficient: lots of activity, lots of motion. In practice, it fragments attention, increases handoffs and stretches timelines, so customers experience more waiting, not more value.
I also agree on measurement. Utilization is comforting because it feels controllable. Flow is harder because it forces tradeoffs. But those tradeoffs are where speed actually comes from.
The leadership move here is simple, but not easy: treat "starting" as expensive and protect "finishing" as the scarce resource. Or put differently: if we greenlight something new, what are we willing to pause so the system can actually move?
A common management approach involves forcing efficiency improvements by increasing workload while simultaneously reducing resources. Employees are then left to figure out how to cope on their own. While this method may seem convenient from a leadership perspective, it fundamentally relies on overloading the system. It requires utilization rates exceeding 100% to function—which is inherently unsustainable and leads to the negative effects you explained.
Leadership needs to understand that this method does not, in fact, create efficiency but rather inefficiency. The intended gains are undermined by the very pressure meant to generate them.
You're absolutely right and I think the key word in your comment is rely.
That approach doesn't really improve the system. It relies on people acting as a buffer when demand goes up and capacity goes down. For a while, that can look like efficiency: more urgency, longer hours, faster response. But those gains come from consuming a finite resource: human slack - not from improving flow.
Once that buffer is gone, the system starts paying interest: more context switching, more coordination, more rework and longer lead times. The pressure that was meant to create efficiency ends up creating exactly the waiting and friction customers experience.
So I agree with your conclusion: running beyond 100% utilization isn't a strategy, it's a temporary coping mechanism. Real efficiency comes from changing how much work is in flight and how decisions get made, not from asking the system to outrun its own limits.
Excellent application of Little's Law to knowledge work. The embedded hardware example nails it, 6 months of active work stretched to 18 because of queue dynamics feels painfully familiar. Most orgs I've worked with optimize locally (faster code reviews, better tooling) when the real leverage is systemic (fewer parallel iniciatives, explicit WIP limits). The hardest sell is always convincing leadership that slack is a feature not a bug.
The local vs. systemic distinction you're making is exactly the trap many organizations fall into. Faster reviews and better tools feel productive, but they mostly shift waiting around unless the amount of parallel work actually changes.
What often happens instead is that teams try to compensate by working longer hours. For a while, that creates the illusion of progress. Lead times shrink a bit, backlogs move. Until they don't. At some point, the system just hits a human limit. Fatigue goes up, errors increase and everything slows down again.
And yes, convincing leadership that slack is a feature, not a bug, is often the hardest part. Once that clicks, many of the other conversations become much easier, because the focus shifts from squeezing more effort out of people to designing a system that can actually flow.
Nice work, Thomas. The way you break down effort versus flow makes the hidden waiting time obvious. Once people see it, they see it everywhere. One idea your piece made me think about is how the bottleneck and the critical path shape the system as a whole. When the constraint remains fixed, speeding up the surrounding spaces gives a lift, but only up to a point. You are already heading toward that insight. It might be interesting to explore how identifying the true constraint changes the picture even more. Sometimes, slowing one part down is what lets the whole system move faster. Really enjoyed this one.
Thank you, Andrew. That's a really thoughtful observation.
You're absolutely right: once the true constraint remains fixed, speeding up the surrounding steps only helps up to a point. After that, most additional "efficiency" simply turns into waiting around the bottleneck.
In my experience, seeing waiting time is often the first real shift in perspective. Identifying the true constraint is the next and usually more uncomfortable step.
And I completely agree with your last point. Once you understand where the constraint really is, the logic flips. Sometimes slowing one part down or protecting it from variability, is exactly what allows the whole system to move faster.
I see constraints not as a different theory, but as a natural continuation of the same line of thinking.
You've hit on something critical here.
In most companies, the decision process goes like this: If the business case is feasible and the budget exists, the project gets greenlit. The more activities running simultaneously, the more efficient the organization appears to be.
But this is a fundamental misconception.
High utilization creates the illusion of productivity while actually destroying flow. When everything is running at once, nothing moves quickly. Resources get fragmented, context-switching kills momentum, and delivery timelines stretch.
The better approach: prioritize ruthlessly based on value creation and speed to market. Finish fewer things faster rather than starting everything at once.
Efficiency should be measured in flow, not utilization. A team running at 100% utilization but delivering slowly is far less efficient than a team with slack capacity that ships value continuously.
It's not about how busy your organization looks—it's about how quickly you can deliver real value to customers.
And let's be clear: this is nothing less than a cultural transformation at the top management level. It requires leaders to let go of the comfort of "full capacity" metrics and embrace the uncertainty of flow. That's not a process change—it's a fundamental shift in how success is defined and measured.
Thank you so much, Uwe. This nails a pattern I see all the time.
Many organizations have a very clean "start" process (business case + budget = greenlight), but a very messy "finish" process. And once you keep approving new work without an equally explicit mechanism to stop or pause existing work, WIP quietly becomes the strategy.
On paper, that looks efficient: lots of activity, lots of motion. In practice, it fragments attention, increases handoffs and stretches timelines, so customers experience more waiting, not more value.
I also agree on measurement. Utilization is comforting because it feels controllable. Flow is harder because it forces tradeoffs. But those tradeoffs are where speed actually comes from.
The leadership move here is simple, but not easy: treat "starting" as expensive and protect "finishing" as the scarce resource. Or put differently: if we greenlight something new, what are we willing to pause so the system can actually move?
Appreciate you adding this layer.
There are additional root causes to the problem:
A common management approach involves forcing efficiency improvements by increasing workload while simultaneously reducing resources. Employees are then left to figure out how to cope on their own. While this method may seem convenient from a leadership perspective, it fundamentally relies on overloading the system. It requires utilization rates exceeding 100% to function—which is inherently unsustainable and leads to the negative effects you explained.
Leadership needs to understand that this method does not, in fact, create efficiency but rather inefficiency. The intended gains are undermined by the very pressure meant to generate them.
You're absolutely right and I think the key word in your comment is rely.
That approach doesn't really improve the system. It relies on people acting as a buffer when demand goes up and capacity goes down. For a while, that can look like efficiency: more urgency, longer hours, faster response. But those gains come from consuming a finite resource: human slack - not from improving flow.
Once that buffer is gone, the system starts paying interest: more context switching, more coordination, more rework and longer lead times. The pressure that was meant to create efficiency ends up creating exactly the waiting and friction customers experience.
So I agree with your conclusion: running beyond 100% utilization isn't a strategy, it's a temporary coping mechanism. Real efficiency comes from changing how much work is in flight and how decisions get made, not from asking the system to outrun its own limits.
Appreciate you adding this perspective.
Excellent article! This should be obvious—but it’s not. Thanks for calling this out
Thank you. Appreciate that.
A lot of these dynamics feel obvious once you see them. The tricky part is noticing them while everyone is busy and things seem to be moving.
Glad it resonated.
Excellent application of Little's Law to knowledge work. The embedded hardware example nails it, 6 months of active work stretched to 18 because of queue dynamics feels painfully familiar. Most orgs I've worked with optimize locally (faster code reviews, better tooling) when the real leverage is systemic (fewer parallel iniciatives, explicit WIP limits). The hardest sell is always convincing leadership that slack is a feature not a bug.
Thank you, that resonates a lot.
The local vs. systemic distinction you're making is exactly the trap many organizations fall into. Faster reviews and better tools feel productive, but they mostly shift waiting around unless the amount of parallel work actually changes.
What often happens instead is that teams try to compensate by working longer hours. For a while, that creates the illusion of progress. Lead times shrink a bit, backlogs move. Until they don't. At some point, the system just hits a human limit. Fatigue goes up, errors increase and everything slows down again.
And yes, convincing leadership that slack is a feature, not a bug, is often the hardest part. Once that clicks, many of the other conversations become much easier, because the focus shifts from squeezing more effort out of people to designing a system that can actually flow.
Nice work, Thomas. The way you break down effort versus flow makes the hidden waiting time obvious. Once people see it, they see it everywhere. One idea your piece made me think about is how the bottleneck and the critical path shape the system as a whole. When the constraint remains fixed, speeding up the surrounding spaces gives a lift, but only up to a point. You are already heading toward that insight. It might be interesting to explore how identifying the true constraint changes the picture even more. Sometimes, slowing one part down is what lets the whole system move faster. Really enjoyed this one.
Thank you, Andrew. That's a really thoughtful observation.
You're absolutely right: once the true constraint remains fixed, speeding up the surrounding steps only helps up to a point. After that, most additional "efficiency" simply turns into waiting around the bottleneck.
In my experience, seeing waiting time is often the first real shift in perspective. Identifying the true constraint is the next and usually more uncomfortable step.
And I completely agree with your last point. Once you understand where the constraint really is, the logic flips. Sometimes slowing one part down or protecting it from variability, is exactly what allows the whole system to move faster.
I see constraints not as a different theory, but as a natural continuation of the same line of thinking.
Really appreciate you adding this layer.