Your Team's Utilization Rate Is 95%. Here's Why Delivery Is Still Slow.
High utilization looks great on a dashboard. Here's the queueing-theory reason it can quietly slow delivery down instead.
Your team's utilization rate hit 95% this quarter. Everyone is logging full weeks. The capacity report is green across the board. And the roadmap is still three weeks behind, with the same two features stuck in review that were stuck in review last month.
If that sounds familiar, you're not measuring the wrong team — you're measuring the wrong thing. Team utilization rate tells you how busy people look on paper. It says almost nothing about how fast work actually moves through your system, and past a certain point, chasing a higher number actively makes delivery slower. That's not a motivational problem. It's math.
9 min read
- What your utilization rate is actually telling you
- The math behind why "busy" and "fast" aren't the same thing
- Resource efficiency vs. flow efficiency
- Three places the utilization number hides the real story
- The utilization audit: five questions to ask this sprint
- What to track instead of chasing 100%
What your utilization rate is actually telling you
A team's utilization rate is simple to calculate: billable or productive hours divided by total available hours. According to Asana's benchmark research, most software teams target 75–80%, leaving roughly a day a week for meetings, planning, and the unplanned work that shows up regardless of the schedule.
The problem isn't the formula. It's what leaders infer from it. A high number reads as "the team is productive." A dip reads as "the team has slack to give." Neither inference holds up, because utilization measures occupancy, not throughput. A team can be 95% occupied and still ship less than a team running at 70%, because occupancy says nothing about how much of that time is spent context-switching, waiting on a dependency, or working on the wrong thing well.
This is the same blind spot behind sprint velocity's reputation as a misleading metric — a number that looks like output but is really measuring something adjacent to it.
The math behind why "busy" and "fast" aren't the same thing
Queueing theory has an answer for why fully-loaded teams slow down, and it isn't intuitive until you see the curve. In systems where work arrives unevenly — which describes basically every software team — wait time doesn't rise in a straight line as utilization climbs. It rises exponentially.
Engineer Erik Bernhardsson lays out the math: "At 50% utilization, you get twice the latency that you do with 0% utilization. Once you start hitting say 80% utilization then it goes up. And it goes up FAST." The underlying formula for average wait time is roughly service time divided by (1 − utilization) — a denominator that shrinks toward zero as utilization approaches 100%, sending wait times toward infinity.
Utilization measures how busy people look. Flow measures how fast work actually moves. A team can max out one metric while starving the other.
Translate that to a sprint board: at 95% utilization, there's no slack left to absorb a code review, an urgent bug, or a blocked ticket without everything behind it queueing up. One person's "quick interruption" cascades into a two-week delay, and nobody can point to a single cause — because the cause isn't an event, it's the system running with no buffer.
Resource efficiency vs. flow efficiency
Agile consultant Johanna Rothman draws a useful line between two ways of optimizing a team: resource efficiency (keep every specialist busy) and flow efficiency (get features finished quickly). Her summary is the sharpest version of the argument: "Your customers buy features. They don't buy your busy-ness."
Most planning tools default to optimizing resource efficiency because it's the easier thing to see. Flow is invisible in a headcount spreadsheet; a green utilization bar is not.
| Resource efficiency (old way) | Flow efficiency (better way) |
|---|---|
| Success = every person has assigned work | Success = features move from start to done |
| Measured in hours logged per person | Measured in cycle time per item |
| Idle time treated as waste | Slack treated as capacity to absorb variability |
| Specialists work in isolation to stay "productive" | Work-in-progress is capped so items finish before new ones start |
| Bottlenecks hidden by everyone looking busy | Bottlenecks visible because queues are tracked |
Neither extreme is right. A team running at 40% utilization has real slack going to waste. But past roughly 80%, every additional point of utilization buys a shrinking amount of extra output and an escalating amount of queueing delay — the exact tradeoff the table above is pointing at.
Three places the utilization number hides the real story
A utilization report can look healthy and still be lying to you. Three common blind spots:
- Busywork counts as "utilized" time. Asana's research puts the average knowledge worker at 60% of their time spent on busywork — status chasing, tool-switching, approval waiting. All of it logs as billable hours. None of it moves a feature closer to done.
- Multitasking inflates the number while destroying flow. A person "utilized" across four concurrent tickets looks fully booked, but each ticket sits idle whenever attention shifts to the other three — the definition of high occupancy, low flow.
- Burnout doesn't show up until it's a resignation. Gallup's 2026 State of the Global Workplace report found global employee engagement fell to 20% in 2025 — its lowest level since 2020 — with low engagement costing the world economy an estimated $10 trillion in lost productivity. A utilization dashboard tracks hours, not the erosion happening underneath them.
This is the gap time tracking data for capacity planning is meant to close — treating utilization as one signal among several (alongside overhead ratio, unplanned work percentage, and project concentration) instead of the single number that decides whether a team gets more headcount or a talking-to.
The utilization audit: five questions to ask this sprint
Before you use utilization rate to make a staffing or workload decision, run the number through this checklist:
- What's the cycle time trend, not just the utilization trend? If utilization is flat or rising and cycle time is also rising, you're watching queueing delay in real time.
- How much "utilized" time is actually meetings, status updates, and tool-switching? Pull a week's calendar against logged hours and see what's left.
- How many items are in progress right now, per person? More than two or three is usually a flow problem wearing a utilization costume.
- Is anyone at or above 100% for more than two consecutive weeks? That's not dedication — it's a queue with no exit.
- What decision are you about to make with this number? If the answer is "add more work" and utilization is already above 80%, the audit just paid for itself.
What to track instead of chasing 100%
None of this means utilization is a useless number — it's a useful constraint, not a target. The healthier practice is to hold it inside a band (roughly 70–85% for most software teams) and put your attention on the metrics that actually track delivery:
- Cycle time — how long an item takes from start to done, which surfaces queueing delay directly.
- Work-in-progress (WIP) limits — capping how much is "in flight" per person forces flow efficiency instead of resource efficiency by design.
- Flow efficiency ratio — active work time divided by total elapsed time for an item; a low ratio means items spend most of their life waiting, not being worked on.
Teams that shift their weekly review from "who's underutilized" to "what's queued and why" tend to find the answer faster than a staffing conversation would have — and it's the same shift behind why time tracking fails teams that use it only for accountability instead of planning intelligence.
The shift worth making
A utilization number that's high and rising isn't evidence of a well-run team — past a certain threshold, it's the leading indicator of the opposite. The fix isn't to stop tracking hours. It's to stop treating "busy" as a proxy for "productive," and start watching how long work actually sits in queue before it moves.
That's also where tooling earns its place: capacity data is only useful if someone's actually looking at flow, not just hours logged, and doing that manually across a dozen tickets a week is its own form of busywork.
Frequently asked questions
What is a good team utilization rate?
Most software and services teams target 70–80%, leaving roughly a day a week of buffer for meetings, review, and unplanned work. Rates that sit consistently above 85–90% tend to show up later as rising cycle times rather than higher output.
Why does high utilization slow down delivery?
Queueing theory shows that wait times rise exponentially, not linearly, as a system's utilization approaches 100%. With no slack left to absorb variability — a blocked ticket, an urgent bug, a review request — every disruption queues up behind the next, and small delays compound into large ones.
What's the difference between utilization rate and flow efficiency?
Utilization rate measures how much of a person's available time is logged as productive or billable. Flow efficiency measures how much of an item's total lifecycle is spent actually being worked on versus waiting. A team can have high utilization and low flow efficiency at the same time — busy people, slow features.
How do I calculate my team's utilization rate?
Divide productive or billable hours by total available hours in the same period, then multiply by 100. The harder part is deciding what counts as "productive" — busywork like status chasing and tool-switching often gets counted even though it doesn't move projects forward.