Two teams, same CI speed, wildly different cycle times. One lets ten PRs stack up before anyone reviews them. The other doesn't. Swap the units and the pattern holds exactly: two sales teams, same close rate, wildly different revenue, because one lets qualified leads sit for a week before the first call goes out.

Same engine, same speed, different queue depth. That's the whole post.

The queueing-theory minimum

Little's Law, informally: cycle time is roughly everything currently in the system, waiting or being worked, divided by throughput. Worth being precise, because a technical reader will notice if you're not: it's items in the whole system, not just the ones waiting their turn. But the point stands either way. Queue length, not station speed, is usually what dominates.

None of this is new to operators, even if the name is. It's the same logic behind WIP limits on a kanban board, or a sales team capping how many open deals one rep is allowed to carry at once.

A real caveat here — and not just about who's studied what. Little's Law's best-established home outside manufacturing is call-center staffing: the Erlang-C models behind workforce management, surveyed in Gans, Koole, and Mandelbaum's 2003 paper on telephone call centers. There isn't solid published research applying it to a sales funnel the way there is for a support queue. And the math assumes something a phone queue mostly gives you and a sales pipeline doesn't: a steady flow where almost everything that goes in eventually comes out. A call gets answered. Every time. A lead sitting in "proposal sent" for two months usually doesn't turn into a deal — it turns into a dead record nobody closed out, still counted as "in the queue" on a report that says the pipeline looks healthier than it is. That leakage breaks the clean math, even if the basic instinct — a longer queue behind a stage means slower average time-to-close — still holds directionally. Treat the sales-pipeline version here as a useful, structurally sound analogy, not a rigorous application of the theorem.

Applying it up the whole ladder, in both languages

A test suite that runs in 30 seconds is worthless if nobody runs it until 40 commits have landed. A weekly pipeline review is just as worthless if 40 deals sat untouched in "proposal sent" the whole time. Engineering and revenue just found the exact same way to waste a fast tool.

A weekly business review sitting on a month of unprocessed customer feedback looks like a cadence problem. It's really a queue problem wearing a scheduling disguise. Same story for a monthly board meeting sitting on a quarter of unresolved churn interviews. The cadence was never the issue. The backlog was.

"Smaller and smaller queues" is the actual target at every rung, not "faster and faster stations." That holds whether the rung in question is a CI pipeline or a support inbox.

Finding the real constraint

It's not the slowest-looking step. It's the one with the longest backlog behind it, and those are often two different steps entirely. A genuinely fast rung can still be the bottleneck if everything piles up waiting on it, whether that rung is a deploy pipeline or a single overloaded account manager who happens to own every enterprise deal.

Prioritization is bottleneck-finding

Before you try to shrink a queue, you need to know why it's backed up. Here the Bottlenecks Institute framing does real work — coordination, talent, cultural, technical, market, regulatory. A technical queue (the CI pipeline itself is just slow) and a coordination queue (nobody actually owns handing leads from marketing to sales) need completely different fixes. Mistake one for the other and you can burn a whole quarter fixing the wrong thing well.

Once you know why a queue is stuck, rank your candidates — code or pipeline — by rough order-of-magnitude value sitting behind them, weighed against how cheap each one is to drain. That's what "estimate the things that are valuable" actually looks like once you attach real numbers to it: dollars stuck in a stalled deal stage against hours stuck in a stalled build queue. Whichever number is bigger wins the quarter. It's rarely the one that felt most urgent this morning.

None of this matters, though, if the thing sitting in the queue shouldn't have been built, or sold, or pursued in the first place. Validation order matters as much as queue size. That's Part 3.

Smaller Queues, Faster Everything