Learn it → Apply it → Save as Skill
The number of things sitting in a system equals how fast they arrive, multiplied by how long each one stays. That one identity holds for a call queue, a hospital ward, a software backlog, or your own to-do list — and once you know any two of the three numbers, the third is no longer a guess.
Dr. Wallace's Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
The average number of items present in a system (L) always equals the average rate at which items arrive and are accepted (λ) multiplied by the average time each item spends inside (W). It holds for almost any stable system, regardless of how arrivals are spaced out, how long individual items take, or how many people or servers are working it.
L = number in the system • λ = arrival rate • W = time in the system
Important: you cannot move one of these three numbers without moving at least one of the others. Cutting how many things are "in progress" (L) while arrivals (λ) stay the same mechanically cuts how long each item takes (W) — that is not a motivational trick, it is the arithmetic.
The model is most useful whenever you can point to a flow of things entering a system, spending some time inside it, and eventually leaving — tickets, patients, orders, stories, requests, or tasks on your own list.
Proved by the operations researcher John D. C. Little in 1961. It applies to almost any stable system — no assumption is needed about how arrivals are spaced, how long each item takes, or how many servers are working in parallel.
The long-run average count of items present at any moment — people in a waiting room, stories in progress, requests being handled right now.
How many items enter and are actually accepted per unit of time, on average — not raw demand, but what the system actually took in.
The average time a single item spends between entering and leaving — wait time plus service time, start to finish.
It works whatever the arrival pattern, whatever the service-time distribution, and however many servers are running — the only requirement is a stable system measured over a long-enough window.
Enter any two of the three values in matching time units and solve for the third.
Open a use case to see what the model changes.
Check work-in-progress (L) against throughput (λ). If L has crept up while λ stayed flat, cycle time (W) has mechanically gotten longer — capping L, not adding more in-flight work, is usually the faster fix.
Use the forecast call-arrival rate (λ) and a target hold time (W) to compute how many calls (L) will typically be in queue or being handled, and check current staffing against that number directly.
L here is literally the units sitting between stations. If shipping rate (λ) hasn't changed, a growing pile means time-in-system (W) is growing with it — a kanban-style WIP cap is a direct lever on L.
λ is the patient arrival rate, W is length of stay, and L is beds occupied. The identity shows whether the real fix is faster discharge (lower W) or more capacity (more beds) — "work harder" changes neither.
Given an expected request rate (λ) and an average session duration (W), L tells you the expected concurrent load to provision servers, licenses, or seats for.
L is how many things you're personally holding "in progress" at once. If your own throughput (λ) is roughly fixed, cutting your personal work-in-progress is the one lever that reliably shortens how long any single thing takes to finish (W).
This is an illustrative example designed to teach the method; the numbers are for demonstration only.
Expand for the model's origin, its precise formal claim, and an honest look at how it's often misapplied.
John D. C. Little, an American operations researcher, published the formal proof in 1961 as "A Proof for the Queuing Formula: L = λW" in the journal Operations Research (volume 9, issue 3). The relationship had been informally proposed earlier by the physicist Philip M. Morse, who reportedly challenged readers to find a counterexample; simpler proofs followed from Jewell (1967) and Eilon (1969).
In a stable, steady-state (stationary and ergodic) system, the long-run average number of items present equals the long-run average accepted arrival rate multiplied by the long-run average time an item spends inside. Remarkably, no assumption is needed about the arrival process, the service-time distribution, the number of servers, or the order items are served in — which is what makes it useful far beyond classical queueing problems.
It is an accounting identity about long-run averages, not a causal explanation: it tells you what must be true, not why wait times are currently what they are. It can mislead if applied to a short or non-stationary window (a launch spike, a holiday surge, a system still ramping up), if the arrival rate used is raw demand rather than what the system actually accepted, or if λ and W are expressed in mismatched time units. None of those are flaws in the law itself — they are the usual ways people apply it to data that doesn't yet meet its (modest) requirements.
Using a weekly arrival rate with a time-in-system measured in days (or vice versa) is the single most common error. Convert one before solving, every time.
A single busy afternoon or one slow sprint is not the long-run average. The identity only holds reliably once the measurement window is long enough to settle.
If some requests are blocked, dropped, or turned away, λ must reflect only what the system actually took in, not everything that tried to arrive.
A launch-day spike, a holiday rush, or a system still ramping up has not reached a steady state. The identity describes settled behavior, not a transient in progress.
Solving for W tells you what the cycle time is given L and λ — it does not explain which specific step is actually slow. That question belongs to Theory of Constraints or Bottlenecks.
Lowering L only shortens W if throughput (λ) holds steady. If a tighter cap leaves people idle or starves a later step, λ itself can drop, and the predicted improvement won't show up.
you need to know why a specific step is slow, not just how the three averages relate. Theory of Constraints or Bottlenecks will point at the actual limiting step.
the system isn't in a steady state — a one-time launch, a shutdown, or a ramp-up period. The Law describes settled long-run behavior, not a transient still unfolding.
you need a worst-case or percentile guarantee (a service-level agreement on the slowest 5% of cases), since this identity only gives you the mean, not the tail.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Little's Law, what questions to ask, what evidence to seek, what mistakes to avoid, and how to structure its analysis.
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
The proof doesn't track individual arrival or service patterns at all — it works directly with the long-run average area under the "number in system over time" curve, which always equals total time-weighted presence, and divides that two different ways. Because the derivation never relies on a specific distribution, it ends up holding for almost any stable system, including ones with wildly irregular arrivals.
You can measure W directly if you have timestamped data for every item. Little's Law becomes valuable precisely when you don't have that: if you know how many items are typically present (L) and how fast they arrive (λ), you can derive W without ever timing an individual item end-to-end, or cross-check a directly measured W against what the other two numbers imply.
Only if throughput (λ) survives the change. A WIP cap helps because it stops a system from carrying more unfinished work than its own throughput can justify, which shortens the time each item waits behind everything else already in flight. If the cap is so tight that workers go idle or a downstream step starves, λ itself can fall, and the shorter W the identity predicted will not actually show up.