Why a process contains a stage that appears to do nothing

The gap between two visible events

Follow almost any process from outside and you find a stretch where nothing appears to happen. The application is received on Tuesday and assessed on Friday. The order is confirmed and then sits, unchanged, for two days before anything is dispatched. The decision is made and the letter arrives a week later. The interval is real, and it is almost never the interval it looks like.

From outside, an empty stage looks like a queue, and it sometimes is one. But three other things produce exactly the same appearance, and they behave very differently when you push on them. Telling them apart is the difference between a sensible chase and a wasted phone call.

Checking is invisible whenever it passes

The first is verification. A great deal of work in any organisation consists of confirming that something is as it claims to be, and confirmation that succeeds produces no visible output at all. A second member of staff reads the file and agrees. A figure is compared with the figure held somewhere else and matches. A name is run against a list and is not on it.

Because a successful check leaves nothing behind but a tick in a box, the stage seems empty in a way an unsuccessful one never does. Checks are also frequently sampled rather than universal, which means two people with identical cases can experience quite different timelines without either being treated differently in any meaningful sense. One case was drawn for review and one was not.

Batching turns continuous work into scheduled work

The second is the batch. Many steps are not performed when they become due but at fixed points — overnight, at the end of a shift, on a set weekday. Anything arriving after the cut-off waits for the next run, which is why the same task completed twenty minutes apart can differ by a day in outcome and why processes have a peculiar relationship with afternoons.

Batching survives because the fixed cost of running something is often far larger than the cost of the individual items in it. Printing and posting, payment files, updates sent to another organisation, reconciliations: all of these are cheaper and safer performed once against a settled set of records than continuously against a moving one. The waiting is a genuine cost, and it is a cost somebody decided was worth paying.

Some delays are themselves the control

The third kind is deliberate. A period during which nothing happens can be the safeguard rather than an obstacle to it. A window in which an instruction can be withdrawn before it becomes irreversible, a settling period before funds can be moved on, a gap between a decision and its effect so that anybody affected has notice — in each case the delay is the mechanism, and removing it removes the protection.

These are the stages most likely to be described as pointless and least likely to be shortened for an individual, because shortening them for one person defeats the purpose for everybody. It is also the category where an explanation helps most, since a delay that is understood as a safeguard is experienced very differently from one that looks like inattention.

Waiting on somebody else looks identical from outside

The fourth is dependency: the case is with another organisation, another department, or a person who has been asked for something and has not yet replied. From the outside this is indistinguishable from an internal queue, and from the inside it often is not much better, because the only signal is the absence of a response.

This is the stage where chasing does the most good, and where it works best if it is aimed at the right place. A case waiting on a third party is not moved by pressing the organisation holding it. It is moved by whatever produces the missing response, which may well be something in your own hands rather than theirs.

Which stages can be hurried and which cannot

The distinctions matter because they predict what pressure achieves. A queue can occasionally be jumped, and a dependency can sometimes be resolved directly. A batch cannot be run early for one item, and a safeguard period will not be waived, so a request to expedite either of those is being addressed to a mechanism that has no capacity to respond.

Which suggests a better question than asking how long something will take. Asking what has to happen next, and what it is waiting on, produces an answer that people can actually give, and the shape of that answer usually tells you which of the four you have landed in. A batch has a named time. A check has a person. A dependency has somebody else’s name on it.