Running at 100% (classroom session): why loading a system full blows up the wait

▶ Present these slides — opens the deck in your browser. Arrow keys advance; press S for speaker notes, F for fullscreen.

1. For the instructor

This is a ready-to-run 75-minute classroom session on utilization versus wait time — why pushing a single resource toward 100% busy does not get you a little more output for free, but instead makes the line of waiting work explode. Students leave able to explain, in plain numbers, why a system loaded to 95% waits several times longer than the same system at 80%, and able to defend a sensible capacity/utilization target against a manager who only sees “idle time we’re paying for.”

It is built for a wide, mixed-ability university room: it is the operations bridge for engineering and CS students who are comfortable with numbers but have no business background. Every term is defined the first time it appears. The only formula is a single division, small enough to do in your head, so nobody is stranded and no prep is required from you.

You can teach this cold. This pack contains everything: the case (section 3), a minute-by-minute run of show (section 4), the concepts you need and nothing more (section 5), a group exercise (section 6), a full facilitator answer key with the trade-offs (section 7), debrief prompts (section 8), a printable student handout (section 9), a stretch task for fast tables (section 10), and a slide deck you can present straight from (section 11). Read it once and you are ready.

How to run it in a mixed room. Put students in tables of 3-4 and mix confidence levels at each table. The core call is reachable by everyone; the stretch in section 10 keeps fast tables busy. Your job during the exercise is to circulate, ask the steering questions in section 7, and resist giving the answer — the learning is in the argument at the table.

One honest line to say out loud at the start: this is teaching material, not a certification and not a credit-bearing course. It is a session that leaves students able to reason about load and wait and defend a utilization target. That is the whole promise.

Deeper background and the self-serve version of this material live in the anchor Decide course, utilization-vs-wait (see section 2).

A note on the clock. The run of show below is a tight 75 minutes with little slack — in a 30–40 student room budget ~85 minutes in practice (set-up, table-forming, and report-backs always run long). If you fall behind, cap report-backs at two tables and cover two of the discussion prompts. Protect the group exercise and the answer-key debrief — those are the session.

2. Session at a glance

Item	Value
Audience	Engineering/CS and applied students; no business background; the ops bridge
Class size	12-40
Total time	75 minutes
Difficulty	4 / 8
Format	Instructor-led; tables of 3-4; one group exercise with a single defensible call

By the end students can:

Compute utilization as the arrival rate divided by the capacity, and read it as “how full the server is” rather than “how many people are in the room.”
Explain the non-linear jump — use the wait factor rho / (1 - rho) to say why 95% full is not “a little worse” than 80% but several times worse, and refuse the “we’re only at 90%, push to 98% for efficiency” argument in numbers.
Defend a capacity/utilization target for a real resource, naming what each rejected option would have cost.

Further reading (the anchor Decide course): utilization-vs-wait — the self-serve version students can work through on their own afterward. This classroom session reuses a composite teaching case in the same spirit, adapted for a live room.

3. The case

Nimbus is a composite (invented) company — a small software firm that sells a scheduling app. Every figure below is illustrative, chosen to make the reasoning clean; no number here describes any real firm.

When a customer hits a problem the front-line team cannot fix, the ticket is escalated to Nimbus’s one senior support engineer, who works a single queue of these hard tickets. “Service rate” below is how many escalated tickets she can fully resolve in an hour when she is working; “arrival rate” is how many new escalations land per hour.

Item	Figure
Engineer’s capacity (service rate)	6 tickets / hour (one every 10 minutes)
Escalations arriving now (arrival rate)	4.8 tickets / hour
Proposed “efficient” arrival rate	5.7 tickets / hour
Service-level promise to customers	first reply within 45 minutes

The head of support looks at the dashboard and sees the engineer is busy 80% of the time. “That’s 20% of a salary sitting idle. Route more of the queue to her and get us closer to 100% — we’re paying for the whole hour, let’s use it.” Rerouting would push arrivals to 5.7 tickets/hour.

The support engineer pushes back: “Every time we’ve loaded me up, the wait times don’t creep up — they blow up, and we miss the 45-minute promise.” Nobody in the room can say why a small change in how busy she is would swing the wait so hard, or what target they should actually aim for.

You have to make the call: how full should Nimbus run this one engineer, and is hiring a second one worth it? The trap is that the idle 20% looks like money left on the table, while the wait it is quietly buying stays invisible on the dashboard until, suddenly, it is not.

4. Run of show

8 min — Hook: pose the Nimbus situation and the head-of-support’s “push her to 100%” plan (section 3). Ask the room to vote by show of hands: push to 95%, hold at 80%, or hire a second engineer — before any teaching. Record the split on the board; don’t comment.
10 min — Teach the core idea: utilization and the wait factor rho / (1 - rho) (section 5, first two points). Walk the wait-factor table once, out loud, and let the fivefold jump from 0.8 to 0.95 land.
7 min — Set up the group exercise: hand out the worksheet (section 9), form tables of 3-4, and read the task aloud so every table starts at the same line.
20 min — Group exercise: tables work the call and fill in the worksheet (section 6). Circulate and use the steering questions from section 7; do not give the answer.
12 min — Report back: two or three tables state their call and their reasoning. Put the competing answers side by side on the board.
10 min — Teach the rest: why some slack is efficient, and how to turn the 45-minute promise into a utilization ceiling and then a cap on arrivals (section 5), tied back to what the tables just found.
8 min — Debrief and close: run the section 8 prompts, land the one-sentence takeaway, and revisit the opening vote to see what changed.

Total: 75 minutes.

5. Teaching points

Teach only these, in this order — each is defined on first use, and together they are exactly what the call in section 7 needs.

Utilization. Written rho (“row”), utilization is the arrival rate divided by the service rate — how full the server is. At Nimbus, escalations arrive at 4.8 per hour and the engineer can resolve 6 per hour, so rho = 4.8 / 6 = 0.8. She is busy 80% of the time; 20% of the hour she is idle. The head of support reads that 20% as waste. Hold that thought — the idle time is doing a job you cannot see. Two rules keep utilization honest. First, rho must be below 1 for the queue to be stable: if work arrives as fast as it can be cleared or faster (rho at or above 1), the line grows without limit and the “wait” is not a number, it is a backlog that never clears. Second, rho is a ratio of two rates, not a headcount — “80% full” is about flow through time, not how many tickets are open right now.

Why the wait explodes near full capacity. Here is the relationship the dashboard hides. For a single server, the expected time a job spends waiting before it is picked up, measured in units of one service time, is:

wait factor = rho / (1 - rho)

The (1 - rho) on the bottom is the idle fraction — the slack. As rho climbs toward 1, that denominator shrinks toward zero, and dividing by a number near zero sends the wait toward infinity. It is not linear. Walk it up (service time here is 10 minutes per ticket):

Utilization rho	Idle (1 - rho)	Wait factor rho / (1 - rho)	Expected wait at 10-min service
0.50	0.50	1.0	10 min
0.70	0.30	2.3	23 min
0.80	0.20	4.0	40 min
0.90	0.10	9.0	90 min
0.95	0.05	19.0	190 min
0.98	0.02	49.0	490 min

At Nimbus’s current 0.8, the wait factor is 0.8 / 0.2 = 4, about 40 minutes — just inside the 45-minute promise. Push arrivals to 5.7/hour and rho = 5.7 / 6 = 0.95; the factor is 0.95 / 0.05 = 19, about 190 minutes — over three hours. The head of support added 15 points of utilization and multiplied the wait by almost five. That is the whole trap: the last few points of utilization are the most expensive ones you will ever buy.

Why some slack is efficient. The counter-intuitive lesson: that idle 20% is not waste — it is what keeps the wait sane. Tickets do not arrive in a tidy stream; they bunch (three land in five minutes, then a quiet spell). The slack absorbs the bunching so the queue drains between bursts. Drive the slack toward zero and there is nothing left to absorb a burst, so it piles into a queue that takes hours to clear. The same engineer resolving the same number of tickets delivers them in 40 minutes at 80% and in over three hours at 95%. So the efficient operating point is not the fullest one — for a single server, past roughly 85-90% each extra point of utilization buys a sliver of throughput and a mountain of wait.

Turning a promise into a target. Run the wait factor backwards. The 45-minute promise, at a 10-minute service time, is a wait factor of about 45 / 10 = 4.5. Set rho / (1 - rho) = 4.5 and solve: rho is about 0.82. So the promise is really a utilization ceiling of ~0.82, which caps arrivals at about 0.82 x 6 = 4.9 tickets/hour on one engineer. A wait-time promise is secretly a statement about how full you are allowed to run. Add a second engineer and the two of them share the load — each sits far down the flat part of the curve (near rho = 0.48 if they split 5.7/hour), where waits are minutes, not hours.

6. Group exercise

The task. At your table, decide how full Nimbus should run its one support engineer — push to 95%, hold near 80%, or hire a second engineer — and be ready to defend the call in two minutes. Use the worksheet in section 9.

Steps (about 20 minutes):

Find today’s load. Compute utilization rho = arrivals / capacity with today’s numbers. Write it down, and use the wait-factor table to read off roughly how long a ticket waits now. Does it meet the 45-minute promise?
Test the “push to 95%” plan. Recompute rho with the proposed 5.7 arrivals/hour. What is the new wait factor, and roughly how long is the wait now? Does the promise survive?
Find the ceiling. The promise is a 45-minute wait. Using the table (or rho / (1 - rho) = 4.5), what is the highest utilization that still keeps the promise on one engineer? What arrival rate does that cap allow?
Make the call. Pick one: push to 95%, hold near the ceiling, or hire a second engineer. Note what each rejected option would have cost — in wait time or in a broken promise.
One free move. Before spending on a hire, name one thing Nimbus could do to shave the wait without more staff (smooth the arrivals, cut the service time, or protect the slack).

Every table should leave with a single call, a utilization target, and a one-line reason.

7. Facilitator answer key

The call: do not push the single engineer to 95% — either hold her near the ~0.82 ceiling the promise implies, or (the stronger answer if escalations are genuinely rising) hire the second engineer. The recommendation turns on one fact: at rho = 0.8 the wait factor is 4 (~40 minutes, inside the 45-minute promise), and the head-of-support’s push to rho = 0.95 sends the factor to 19 (~190 minutes) — the same engineer, a change that looks like “15 more points of a salary we already pay,” and a wait that is almost five times longer. That is the defensible core: utilization is linear, wait is not.

What each option costs. Push to 95% buys a little more throughput and breaks the promise badly — ~190 minutes against a 45-minute commitment — while looking efficient on the dashboard; this is the trap, not a real option. Hold near the ceiling (~0.82, about 4.9 arrivals/hour) keeps the promise on the current headcount but leaves no room for growth: one busy week tips rho past 0.82 and the wait runs away, so it is right only if volume is flat. Hire the second engineer costs a salary but drops each server near rho = 0.48 — deep on the flat part of the curve, waits in single-digit minutes — and is the honest answer once escalations are trending up, because it is the only option that both keeps the promise and leaves slack for bursts. Name the free moves first: smoothing arrivals and trimming the 10-minute service time both lower the wait before any hire, because they move you left on the same curve.

Common wrong turns. Tables accept the “we’re only at 80%, push to 95%” framing because 15 points sounds small — steer with “read the wait factor at 0.8 and at 0.95; is that a small change?” Others treat “the queue is stable” (rho below 1) as “the wait is fine” — remind them stable only means the line does not grow forever, not that anyone is served quickly. If a table freezes, have them fill one row of the wait-factor table by hand first; the non-linearity does the teaching.

8. Discussion & debrief

Run these after the report-back:

Our opening vote split across push-to-95, hold-at-80, and hire. What made “push to 95%” tempting — the word “efficiency,” the small-looking 15 points, or the idle time on the dashboard?
The idle 20% looked like wasted salary. What job is that slack actually doing, and what happens to the queue the moment you spend it?
A wait-time promise (45 minutes) turned out to be a utilization ceiling (~0.82). Why is a promise about time secretly a rule about how full you run?
The queue at rho = 0.95 is still “stable” — it does not grow forever. Why is “stable” nowhere near good enough for the customer?
Suppose escalations doubled overnight. Would holding at 80% still be possible on one engineer? What has to change first — the arrivals, the service time, or the headcount?

One-sentence takeaway: The last few points of utilization are the most expensive you will ever buy, so the right target holds deliberate slack rather than chasing 100%.

9. Student handout

Nimbus — how full should we run the support engineer? (All figures are illustrative; Nimbus is an invented company.)

Escalated tickets arrive in one queue and are resolved by one senior engineer.

Item	Figure
Engineer’s capacity (service rate)	6 tickets / hour (one every 10 minutes)
Escalations arriving now	4.8 tickets / hour
Proposed “efficient” arrival rate	5.7 tickets / hour
Promise to customers	first reply within 45 minutes

Utilization rho = arrivals / capacity. Wait factor = rho / (1 - rho). Wait (min) = wait factor x 10-minute service time.

rho	0.50	0.70	0.80	0.90	0.95	0.98
wait factor	1.0	2.3	4.0	9.0	19.0	49.0

Work it out:

Today: rho = ____ / ____ = ____. Wait factor ____, so wait is about ____ minutes. Promise met? ____
Push-to-95 plan: rho = ____ / ____ = ____. Wait factor ____, so wait is about ____ minutes. Promise met? ____
The 45-minute promise is a wait factor of about ____ . The highest utilization that keeps it is rho = ____ , which caps arrivals at about ____ tickets/hour on one engineer.
Our call is: ____ . The options we rejected would each have cost ______________.
One free move before hiring: ______________.

Our one-line reason: ________________________________________________

10. Stretch

For fast tables who finish early:

The exact ceiling. Don’t read the table — solve it. Set rho / (1 - rho) = 4.5 and find rho algebraically (rho = 4.5 / 5.5). Then back out the exact arrival rate the promise allows on one engineer. How far below today’s 4.8 is it?
The bursty week. Escalations are not steady: mornings spike to 6/hour, afternoons drop to 3.6/hour, averaging 4.8. If Nimbus plans for the 4.8 average, why will the real waits be worse than the average-based plan predicts? (Hint: the wait curve bends upward, so the pain of the busy morning is not cancelled by the quiet afternoon.)
The hardest one — pooling. Two engineers each run at rho = 0.9. Is the wait shorter if they share one queue, or if each has a private queue of half the tickets? Sketch why pooling the queue beats splitting it, and what that says about one shared line versus two separate ones.

11. Slides

Slide 1 — Running at 100%

Why loading a system full blows up the wait
Nimbus: one support engineer, an escalation queue, a 45-minute promise
Presenter note: Say the honest line — teaching material, not a certification.

Slide 2 — The case & the plan

One engineer resolves 6 tickets/hr; escalations arrive at 4.8/hr; promise: reply in 45 min
Head of support: “she’s only 80% busy — route more, push to 100%” (arrivals up to 5.7/hr)
Presenter note: Take the vote now — push to 95, hold at 80, or hire. Record the split; don’t comment.

Slide 3 — Utilization, plainly

rho = arrivals / capacity = 4.8 / 6 = 0.80 — how full the server is
rho must be below 1 or the queue grows forever; it’s a ratio of rates, not a headcount
The idle 20% looks like waste — hold that thought

Slide 4 — Why the wait explodes

wait factor = rho / (1 - rho); the bottom is the slack
0.80 -> factor 4 (~40 min) · 0.90 -> 9 · 0.95 -> 19 (~190 min) · 0.98 -> 49
Presenter note: 15 points of utilization, almost 5x the wait. Not linear.

Slide 5 — Your table’s call

Find today’s rho -> test the push to 95% -> find the ceiling the promise sets -> make the call
Name what each rejected option costs; one free move before hiring
Presenter note: Circulate; ask “read the wait factor at 0.8 and at 0.95 — small change?”

Slide 6 — Slack is not waste

The idle fraction absorbs the bunching so the queue drains between bursts
Same engineer, same tickets: 40 min at 0.8, over 3 hours at 0.95
Past ~85-90% each extra point buys a sliver of output and a mountain of wait

Slide 7 — A promise is a ceiling

45-min promise = wait factor ~4.5 = utilization ceiling ~0.82 = ~4.9 arrivals/hr on one engineer
Add a second engineer -> each near rho 0.48 -> waits in minutes, with slack for bursts
Presenter note: Tie back to the opening vote — the “small 15 points” was the trap.

Slide 8 — Takeaway

The last points of utilization are the most expensive you will ever buy
The right target holds deliberate slack — don’t chase 100%
Further reading: the utilization-vs-wait Decide course

12. Sources & license

Sources. See SOURCES.md in this folder for full provenance.

Data honesty. Nimbus and every figure attached to it are composite — an invented company with illustrative numbers, built from ordinary, realistic support-desk dynamics for clean teaching. No number or claim here describes, or is drawn from, any real company or real data. The single-server queue is the simplest standard model; treat the minute figures as approximate, directional teaching numbers, not an exact prediction for any real system.

License & disclaimer. This classroom material is free for instructors to use and reproduce under the project’s classroom-use license — the canonical wording is maintained in company/legal/classroom-license.md; refer to it, and do not substitute other terms. In plain English: this material is provided as-is, it is not a certification and carries no guaranteed outcomes, and it is teaching material for a live classroom session — nothing more is promised.

Instructor teaching material, provided as-is. Not accredited, not a certification, and not affiliated with or endorsed by any university. Uses composite (invented) companies and illustrative figures.