Every Value Stream Is A Queue

There is a body of thinking about delivery speed that has been quarantined inside technology departments for about twenty years, and the quarantine has been expensive. The ideas arrived with agile, they were explained using software examples, and so everyone outside engineering reasonably concluded they were about software. They are not. They are about queues, and your organisation is made almost entirely of queues.

The central result is Little's Law: average cycle time equals average work in progress divided by average throughput. It was proved in the context of stochastic processes, it has been applied to motorway traffic, hospital emergency departments, call centres, bank branches and container ports, and it holds regardless of what is sitting in the queue. It does not know whether the items are purchase orders, job candidates, invoices, legal contracts, campaign assets or supplier onboarding forms. If work arrives, waits, is processed and departs, the law applies and the arithmetic is not negotiable.

This matters because the instinctive management response to slowness is almost always aimed at the wrong term. When something takes too long, the reflex is to add people, exhort people, or convene a meeting to prioritise better. Each of those attacks the processing time — the actual work — which in most knowledge-work value streams is a small minority of the elapsed time. The large term is the waiting, and waiting is a product of structure rather than effort.

If you run a function outside engineering, the argument below is not a metaphor being borrowed from somewhere else. It is the original argument, stated in its general form, with software as one instance among many.

What a value stream actually is

A value stream is the sequence of activities that converts a request into something a customer can use. The word "customer" is doing real work in that sentence and is where most mapping exercises go wrong. The customer is whoever experiences the delay. For a hiring value stream the customer is the hiring manager and the candidate. For a month-end close it is whoever needs the numbers to make a decision. For procurement it is the budget holder who cannot start until the contract is signed.

Two properties define a value stream and distinguish it from an org chart.

It crosses functions. Almost no value stream lives inside one department. A new supplier passes through the requesting team, procurement, legal, security review, finance and back. An org chart shows where people report. A value stream shows where work goes. They agree almost nowhere, and the gaps between them are exactly where the queues form.

It has a clock that starts before anyone is working. The customer's clock starts when they make the request, not when someone picks it up. Any measurement that begins at pickup is measuring your department's convenience rather than the customer's experience, and will systematically hide your largest queue.

Where the calendar actually goes

Mapping one without a consultant

You do not need a workshop, a specialist tool or a week. You need one real item that has already completed, and someone willing to reconstruct its history honestly.

Pick a recent, unremarkable, completed request. Not the disaster everyone remembers and not the one that went suspiciously well. Then walk it backwards from completion, and for each step record three things: what happened, who did it, and the timestamp. You will get most of this from email, ticket systems, calendar invitations and document version histories. Where the record is missing, ask the person; they usually remember within a day or two.

Then draw it as a line, and mark every interval as one of two states. Touch time is any period where a named human was actively doing the work. Wait time is everything else — sitting in an inbox, waiting for a committee that meets fortnightly, waiting for a signature, waiting for someone's return from leave, waiting for the next batch run, waiting for a decision that nobody has been asked to make yet.

Total the two columns. The ratio of touch time to total elapsed time is flow efficiency, and it is the single most diagnostic number available to you.

The number nobody expects

In most organisations that have never deliberately attacked queueing, flow efficiency in a cross-functional process sits somewhere in the low tens of percent. Frequently lower. It is not unusual to find a process with a stated duration of eight weeks containing three or four days of actual work.

Sit with the implication rather than moving past it. If a supplier takes eleven weeks to onboard and four days of that is human effort, then doubling the productivity of everyone involved — an outcome no training programme, tool or reorganisation has ever reliably produced — saves you two days out of seventy-seven. The other seventy-three days are untouched, because they were never work.

The waiting is produced by four structural things, and only four.

How much is in flight at once. Every request in progress competes for the same finite approval capacity, the same specialists, the same committee agenda slots. Doubling the number of live requests roughly doubles how long each one waits, by Little's Law, with no change in anyone's effort.

How many handoffs a request must survive. Each handoff is a queue, and each queue adds a full waiting period rather than a marginal one. A process with nine approvals has nine queues, and the sum of nine small waits is not a small number.

How large the batches are. Work that moves in batches waits for the batch to fill. A weekly review meeting imposes an average delay of half a week on everything, whether the item needed reviewing or not. A monthly close imposes up to a month.

Where the binding constraint sits. Every value stream has one step that limits the whole. Improvements anywhere else produce nothing except more inventory piling up in front of the constraint. This is Goldratt's Theory of Constraints, and it is the reason that local efficiency drives so often make the end-to-end number worse.

The four instruments

There are dozens of possible measures. Four of them do nearly all the useful work, and they are function-agnostic.

Cycle time, as a distribution. Calendar time from the customer's request to the customer having what they asked for. Never report the average. The distribution of knowledge work is strongly right-skewed — a cluster of clean cases and a long tail of items that hit something — so the mean describes no actual case and supports no actual promise. Report the median and the eighty-fifth percentile together. The eighty-fifth percentile is a commitment you can keep; the average is a summary of a past that has already gone.

Work in progress. The count of requests started but not finished. This is the only one of the three terms in Little's Law you can change by decision rather than by capability, which makes it the cheapest lever in the organisation and the least used.

Flow efficiency. Touch time divided by elapsed time. It tells you whether your problem is capability or queueing, and it is almost always queueing.

Batch size. How much accumulates before it moves. Batch size is set by cadence — the frequency of your meetings, runs, releases and reviews — and cadence is a policy choice that someone made, often decades ago, for reasons that no longer apply.

Here is the same set applied across several functions, to make the point that the instruments do not change when the domain does.

Function	The item	Clock starts	Clock stops	Typical dominant queue
Hiring	One candidate for one role	Application received	Offer accepted	Waiting for interview slots
Month-end close	One reporting period	Period end	Numbers signed off	Waiting for reconciliations and late entries
Procurement	One supplier or contract	Request raised	Contract signed	Waiting in legal and risk review
Marketing	One campaign or asset	Brief approved	Live to audience	Waiting for review and sign-off rounds
Customer support	One customer issue	First contact	Customer's problem resolved	Waiting on another team for the real fix
Invoice to cash	One invoice	Goods or service delivered	Cash received	Waiting for internal approval before issue

Note that the right-hand column is a wait in every row. That is not a coincidence or a selection effect. It is what these systems look like.

Why the instinctive fixes fail

More people. New capacity arrives with negative productivity for its first months, consumes the time of the senior people who are usually the constraint, and — decisively — increases work in progress, because nobody hires someone and then leaves them idle. More people in a queueing system without a constraint fix buys you a longer queue containing more expensive people.

Better prioritisation. Prioritisation reorders the queue. It does not shorten it. Reordering is genuinely valuable when the cost of delay differs sharply between items, and worth very little when everything in the queue is roughly equally urgent, which in practice it usually is by the time it has been sitting for six weeks. Organisations that hold prioritisation meetings weekly and never discuss how much work is in flight have mistaken sequencing for flow.

Working harder. Utilisation and speed are opposites past a threshold. Kingman's formula relates expected wait to utilisation and to variability, and the relationship is asymptotic: as a step approaches full loading, the queue in front of it approaches infinity. High-variability work — and all knowledge work is high-variability — moves the elbow of that curve left. A function running at what looks like a comfortable eighty-five percent loading is already deep into the non-linear region. This is set out at length in why busy teams are slow teams, and the argument transfers without amendment to a legal team, a finance team or a recruitment team.

What you are actually buying

Shorter cycle time is worth money in ways that rarely appear in a business case, because the costs it removes are not on anyone's budget line.

Faster decisions reduce the option value you destroy by deciding late. Faster hiring reduces the vacancies lost to candidates who accepted elsewhere. A faster close means decisions get made on numbers that are still true. Faster contracting means revenue lands in this quarter rather than next. Shorter queues reduce the expediting, chasing, status reporting and escalation that exist solely because things are slow — work that is pure overhead created by delay, and which disappears when the delay does.

There is also a compounding effect that is easy to miss. Shorter cycle time means faster feedback, which means errors are found while the context is still fresh and while the correction is still cheap. Long queues do not only delay outcomes; they degrade the quality of everything that passes through them.

What to do on Monday

Choose one value stream that visibly frustrates people. Hiring, procurement and the close are the usual candidates because the complaints are loudest and the data is easiest to recover.

Pull three completed items from the last quarter and reconstruct their timelines from timestamps. Mark every interval as touch or wait. Total both columns and compute flow efficiency. Do not soften the number for the audience.

Count how many requests of that type are currently open and unfinished. Divide by how many you complete in an average week. That quotient is your expected cycle time in weeks, by Little's Law. Compare it to what your function currently promises. If they disagree badly, the promise is fiction and everyone downstream already knows.

Then find the longest single wait in your three timelines and ask one question about it: what would have to be true for this step to start the day the previous one finished. The answer is nearly always a cadence, a committee or a queue of other work — all three of which are policy, all three of which someone in your organisation has the authority to change, and none of which requires a budget.