Despite being written in 2013, the phoenix project captures a timeless truth about software development: we keep making the same process mistakes. While its references to on-prem infra might feel dated in 2025, its core message about managing work flow remains crucial.

Today we dive into queue theory from a theoretical and practical angle. At the end of it, you will know for sure why 100% utilization of engineers is a recipe for disaster.

Key takeaways

• 100% utilization leads to an infinite backlog and lead time.
• 80% utilization is the sweet spot.
• Planned inefficiency results in longer term better outcomes and also makes your delivery anti-fragile

A Nerdy Demonstration

My approach to problems is to build prototypes, and AI editors like windsurf have made this more fun than ever before. I have created https://replit.com/@ebuckley2/Queuething to prove a point about Queue theory today. My demo is a simple web application that let’s you control the job rate, and work rate – it outputs metrics on lead time and worker utilization.

While you read, set the repl running with the following parameters

1. Set job creation: 500ms
2. Max finish time: 650ms
3. Min finish time: 450ms

What you will see over time is that the worker utilization tends towards 100%, and the lead time also progressively grows. After 3000 iterations I am seeing a 14 second lead time. Imagine scaling this up to an average software project length of 2 weeks. That means that an average project would spend 12 weeks in the backlog before it can be picked up.

The math behind the result

Beyond just being intuitive, we can prove this with hard core math.

The fundamental relationship in queuing theory is captured by the Pollaczek-Khintchine formula (1930) (P-K formula), which shows how wait times relate to utilization.

Wq= ((1 + scv)/2))(p/(1-p))(1/μ)

Where:

• Wq is the average wait time
• SCV is service time variability
• ρ (rho) is utilization (between 0 and 1)
• μ (mu) is service rate

The key term here is ρ1−ρ. As utilization (ρ) approaches 100%, this term approaches infinity. Here's what happens:

• At 50% utilization: 0.5 / 1−0.5 = 1
• At 80% utilization: 0.8 / 1−0.8 = 4
• At 90% utilization: 0.9 / 1−0.9 = 9
• At 95% utilization: 0.95 / 1−0.95 = 19

Service availability and service rate do impact the result. But there is a bigger factor. Utilization is the key. at 95% utilization, the lead time is a factor of 19! At 80% it is only a factor of 4, this is the sweet spot in my opinion.

Getting practical

Ok math is great, simulations have shown me the reality – Ersin, how do I take this into my day job?

Idle time in a software time doesn’t mean sitting around doing nothing, it means time you get to focus on non functional things to improve the overall product. This is your time for making the product faster to build on in the future. This is the time you get to really focus on reducing complexity of the system as a whole.

Managers you need to immediately build in 80% utilization or your team is doomed to be on a death march. Your ‘work generation’ rate needs to match the team's ability to deliver. It doesn’t make sense to plan 12 weeks in the future, the competition will have already moved on! My all time favourite way to build in 80% utilization is to embrace a cycle like 4 weeks on, 1 week off. On the weeks off – your teams will focus on reducing complexity as a whole and being available for fighting fires.

Not managing a team? You can embrace 80% from the trenches. As an individual contributor you can add 20% to your normal estimation. Make sure you are investing time on reducing the overall complexity of the system. The counterintuitive outcome is that you will move faster in the long run. Managers will learn to depend on you for the ‘extra’ important projects. Your own projects will deliver with less risk. Your colleagues will notice the marked improvement in quality and reduction in complexity across the whole system.

A balance of project delivery and ‘idle’ time is a happy place for many engineers. You get to deliver valuable work – while still building a stable and resilient system. This is not the default mode of operation for most teams, so it often needs to be trained and explicitly built into a way of working.

Conclusion: Embracing "Inefficiency" as a Strategy

The drive for 100% efficiency often comes from well-meaning but misguided Tayloristic thinking. As we’ve seen through 1930 math and 2025 react simulation, pushing for complete utilization creates exponential problems.

When lead times grow to 19x the work rate you’re looking at a quarter-long lead time for new projects. No business can compete in 2025 when they need to plan 3+ months ahead of time.

Make your product managers and business leaders happy by building an engineering organisation that can actually deliver the most important projects. Don’t load up on work that will take ages to even start. Don’t drive your teams to be 100% busy all the time.

Efficiency is a naive goal, we need to focus on being anti-fragile and nimble. Operating at 80% is a good start on the path.