Skip to content
The part of the process nobody writes down
What Nobody ExplainsThe part of the process nobody writes down

Queues & Waiting

The queue you cannot see is rarely first come, first served

Work waiting inside an organisation is ordered by rules that have nothing to do with arrival time, and the pile on a desk is the clearest illustration of it.

By Zoya Rahman3 min read

Black and white image capturing motion blur of people in a busy urban train station.
Photograph by thorl5 via Pexels
Editorial note. Independent reporting and analysis. Nothing here is sponsored or paid for. How we work.

A queue with nobody standing in it

A line of people polices its own order, because everybody in it can see everybody else and objects to being overtaken. Work waiting inside an organisation has none of that. Nobody in the pile can see the pile, no item complains, and the order is therefore whatever the process, the software or the person picking things up decides it should be.

This is why the fairness intuitions built up while standing in queues transfer so badly to anything submitted by post or online. Arrival time is one possible ordering among several, and in a great many back-office queues it is not the one being used.

The physical pile is honestly last in, first out

The plainest example is a tray or a stack. Items are added on top and taken from the top, which serves the newest arrival first and leaves the oldest at the bottom indefinitely. Nobody chose this. It is a property of stacking, and it survives because it takes deliberate effort to work from the bottom of a pile.

Electronic versions inherit the same shape wherever a list is sorted with the newest first. A shared inbox displayed in that order is worked from the top, so the messages most likely to be answered are the most recent ones. That is why a chase can produce a fast reply to itself while the original enquiry stays exactly where it was, several screens below.

Sorting by urgency or by deadline is deliberate

Where the ordering has been designed, it is usually built around whatever the organisation is measured on. Items with a target date are worked in date order, so something submitted later with a nearer deadline goes first. Items are grouped by type so that one person can work through similar cases without switching context. Cases at risk of breaching a target are pulled forward.

Each of these is defensible and each produces overtaking. Working to deadlines rather than arrival is straightforwardly better for meeting deadlines, which is what the service exists to do, and it means an ordinary case submitted early can sit while urgent cases submitted afterwards pass it. That is the design working, not failing.

Quick items first is a policy with a real cost

A common approach is to clear the short tasks first, which lowers the average wait across everything in the queue and produces a satisfying fall in the number of open items. It is the back-office relative of an express lane, and it has the same drawback in a much less visible form.

The cost lands entirely on the long cases, which can be overtaken indefinitely as new short ones keep arriving. Well-run queues counter this with an ageing rule that promotes anything waiting beyond a threshold, and the presence or absence of such a rule is the single biggest difference between a queue where a complicated case eventually gets done and one where it does not.

Assignment turns one queue into many

Most work is not held in a single pool. It is allocated to teams, to individuals, or to whoever has a matching skill, which converts one queue into dozens of small ones. Small queues are much more variable than large ones, so an item can wait an unusual length of time simply because it was allocated to somebody who then had two weeks of something else.

This is the mechanism behind the case that goes quiet for no reason and moves the moment somebody looks at it. Nothing was reconsidered. It was sitting in one person’s allocation rather than in a shared pool, and the review that produced the movement was a review of the allocation rather than of the case.

What this changes about chasing

It suggests that the useful question is not where you are in the queue, which frequently has no answer, but whether the item has been allocated and what ordering the queue uses. Those two facts predict far more about the timing than any position would.

It also explains why chasing sometimes works dramatically and sometimes does nothing. A chase into an unallocated pool is a new item on top of a stack. A chase into an allocated case reaches a person who can act. And a chase against a deadline-ordered queue changes nothing at all, because the order is set by dates rather than by attention — which is, in fairness, exactly what anybody waiting on a genuinely urgent case would want.

Common questions

Why did a later enquiry get answered before mine?

Because internal queues are rarely ordered by arrival. Lists sorted newest-first are worked from the top, and deadline or urgency ordering deliberately promotes later items with nearer target dates.

Does chasing move a case up the queue?

It depends on the ordering. In a shared pool sorted by recency it can genuinely help, in an allocated case it reaches somebody who can act, and in a deadline-ordered queue it changes nothing because the sequence is set by dates.

Why do complex cases wait so much longer?

Because clearing short items first lowers the average wait and looks good on the open-item count, while long cases are overtaken by every new arrival. Queues that avoid this use an ageing rule to promote anything waiting beyond a threshold.

Queues & Waitingqueuesworkfloworderingrecords
Zoya Rahman
Consumer editor, What Nobody Explains

Zoya has written about behind the counter, paperwork, queues & waiting for most of the last decade and thinks most subjects are more interesting once you know how they work.