How Executives Create Queues

Nearly every behaviour in this article is a virtue in isolation. Responding to new information is good. Maintaining oversight of significant commitments is good. Caring enough about a piece of work to follow it personally is good. Expecting an efficient use of expensive capacity is good. Wanting a credible date before committing to a customer is good.

The argument here is not that these instincts are wrong. It is that each of them has a queueing consequence that is invisible from where you sit, that the consequence is frequently an order of magnitude larger than the benefit, and that in almost every case there is a version of the same instinct that gets you what you actually wanted without the delay.

The reason this stays invisible is structural rather than personal. You experience your intervention as a short conversation. The organisation experiences it as a change in the state of a queueing system, and queueing systems respond non-linearly to small changes near full load. The gap between those two experiences is where most organisational slowness lives, and no amount of delivery maturity at the team level closes it, because the cause is upstream of the teams and none of them can address it.

What follows is the specific list. Read it as mechanics rather than as criticism — the useful response is to recognise the mechanism, not to feel bad about having used it.

Reprioritisation mid-quarter

The most expensive single behaviour available to a senior leader, and the one most likely to be described as agility.

Something changes. A competitor ships, a customer escalates, a board member asks a question. You decide that the thing the organisation is working on is less important than the new thing, and you redirect. This is presented as responsiveness, and sometimes it genuinely is.

Here is what it costs. The work in flight does not pause cleanly; it is abandoned mid-stream, so the investment made so far converts from partially-complete inventory into waste unless someone returns to it later at the cost of re-acquiring decayed context. The teams switch, which costs days rather than hours because knowledge work context is deep. The new work jumps every queue, delaying everything already in those queues, not just the work it replaced. And the organisation learns that the plan is provisional.

That last effect compounds. Teams redirected twice in a quarter begin to hedge: they start more slowly, avoid irreversible commitments, and decline to invest in the durable version of anything because it might be cancelled. The behaviour looks like a lack of urgency and is a rational response to observed volatility. You will read it as a delivery problem and apply pressure, which increases the hedging.

The cheaper alternative is not to freeze the plan. It is to hold the cadence and change the content at the boundary. If the shortest available boundary is a quarter, shorten it — plan in six-week increments, or pull the next item when capacity frees up. Then a genuine emergency costs days of wait rather than a mid-flight abort. Responsiveness is a function of how often you can legitimately change direction, not of how willing you are to interrupt.

Being the single approver

You approve things because you are accountable for them, and because approving is how you stay informed. Both reasons are legitimate. The consequence is that you have installed yourself as a single server in front of a queue with a high arrival rate and a calendar that is booked three weeks out.

The arithmetic is unforgiving and has nothing to do with how hard you work. A server at ninety percent utilisation has a far longer queue than one at fifty, and your calendar does not run at fifty. Everything routed through you waits, and the wait is largely insensitive to urgency, because urgency does not change the queue discipline unless you expedite — and expediting is itself a disruption that delays everything else.

There is a second, less obvious cost. When approval is centralised, people batch. Rather than bring you three decisions as they arise, they hold them and bring a bundle, because access to you is expensive. That increases the age of each item and reduces the quality of the decisions, because you are considering three things in the time one deserved.

The alternative is not to stop caring about outcomes. It is to separate the decision from the visibility. Delegate approval with an explicit boundary — spend below a threshold, changes within an established architecture, hires against an approved plan — and require decisions to be recorded where you can read them. You get the information without being in the path. Manufacturing settled the difference between sampling and inspecting every unit a long time ago.

The pet project

You have an initiative you care about personally. Perhaps you sponsored it, perhaps it came from a customer conversation you were in, perhaps you simply find it more interesting than the rest of the portfolio. You ask about it regularly. You are available for its decisions quickly. When it needs something, it gets it.

The project does well. This is taken as evidence of focused leadership.

What is not visible from your seat is the wake. Every resource it received came from somewhere. The environment it got was the one another team was waiting for. The senior engineer it borrowed left a gap. The decisions you answered within a day were answered ahead of decisions that had waited three weeks. And because you ask about it regularly, everything else is deprioritised whenever the two conflict — not by any decision you made, but by a hundred small judgements from people correctly reading which work has your attention.

The compounding effect is on the signal rather than the resources. A single visibly favoured initiative reorganises the informal priorities of a whole division, and nobody will tell you, because from each individual's perspective they are simply being responsive to leadership.

The alternative is not indifference. It is to make the prioritisation explicit rather than gravitational. If the project genuinely is more important, say so, fund it accordingly, and accept what it displaces. If it is not, your attention to it is a distortion, and the honest fix is to ask about it in the same forum and at the same frequency as everything else.

Utilisation targets

Somebody reports that engineering is running at seventy-two percent billable, or that a team has capacity, or that a function's people are not fully loaded. The instinct is to fill the gap, because idle expensive capacity looks like waste.

This is the single most durable misunderstanding in delivery management and it is argued fully in why busy teams are slow teams. The short version: utilisation and speed are opposites past a certain point, the point is lower than anyone expects, and the variability of knowledge work moves it lower still. A system run at ninety-five percent utilisation has enormous queues in front of every station, and the enormous queues are not visible in a utilisation report, which is precisely why the report is dangerous.

There is a subtler version worth naming. Utilisation targets also destroy the organisation's ability to absorb variation. When something urgent arrives at a fully loaded system, there is nowhere for it to go except in front of something else, so its arrival causes a cascade of displacement. Organisations that complain most about firefighting are usually the ones running highest on utilisation, and the causation runs from the second to the first.

Goodhart's Law finishes the job. Once utilisation is targeted it will be met, and the cheapest way to meet it is to start work rather than finish it. You get your number and your throughput falls.

What you asked for	What you got	What you actually wanted
Higher utilisation	More work started, longer queues	More work finished
A status report	A week of preparation, a curated number	To know whether to worry
Certainty on a date	A padded estimate defended as fact	A commitment you can plan against
Everything prioritised	Nothing prioritised	The top three, honestly ranked

Asking for a status report

You want to know how something is going. You ask for a report. This seems close to free — it is one email.

Downstream, a request from a senior person becomes a small programme. Someone collects information from four teams. Those teams stop to answer. Somebody builds a deck because a document felt insufficiently serious for the audience. It is reviewed by two layers of management, each of whom sands off an edge. By the time it reaches you, roughly a person-week has been consumed, the information has passed three filters that each removed a degree of bad news, and the result is less accurate than the dashboard you could have opened.

The fix has two parts. Make the real state permanently visible so that the answer to "how is it going" is a link rather than an exercise; if the flow data is live and trusted, the request disappears. And be explicit about the effort you are authorising: "a paragraph by Thursday, no deck, no review chain, it does not need to be polished" produces a different cost. People otherwise assume the maximum, which is the safe assumption when a request comes from above.

Demanding certainty that can only be manufactured

You need a date. The team gives a range. The range is wide because the work has genuine uncertainty in it. You push for a single number, because a range cannot be communicated to a board or a customer.

What follows is predictable. The team converts the range into a single number by padding it and presenting the high end as a commitment. You now have certainty that is manufactured rather than discovered. The padded date becomes the plan, and the work expands to fill it. The team defends the number rather than the outcome, because they will be held to it. And when something genuinely changes they are reluctant to tell you, because revising a commitment looks like failure.

The alternative is harder than asking for a date: learn to consume a probabilistic forecast. A forecast whose eighty-fifth percentile is the second week of March is more useful than a date, not less, because it tells you what you can promise and with what confidence. It also degrades gracefully — when throughput changes, the forecast moves, and the movement is information rather than a failure event.

That is a genuine skill and takes a leadership team a couple of quarters to acquire. It is worth the effort, because the alternative is an organisation that has learned to give you the number you want, which means you no longer have any instrument at all.

Just one more thing

The small request at the end of a conversation. It will only take a couple of days. You are not asking anyone to change their plan; you are adding something modest.

Additions to a loaded system are never modest. A two-day task added to a team at full utilisation does not cost two days of elapsed time — it joins a queue, competes for review and environment capacity, and delays several items by more than its own size. And because it arrived informally, it never appears in any prioritisation conversation, so the displacement is attributed to the team rather than to the addition.

Volume matters more than any single instance. A leadership team of eight, each making one informal request a week, generates around thirty-five unplanned items a month with no owner, no priority and no visibility. That is frequently a larger volume than the planned work, and it explains a roadmap that never progresses despite everyone being fully occupied.

The alternative is to route it through the same queue as everything else. If it is genuinely important it wins on merit, and if it will not survive that comparison it was not worth the displacement.

What to do on Monday

Pick one week and keep a private tally of four things: every time you asked for something outside the normal planning cycle, every decision that was waiting on you, every time you changed a priority, and every report you requested. Do not change your behaviour during the week — you want the baseline, not a performance.

At the end of the week, take the tally to the person who runs delivery for you and ask a single question: what did each of these cost downstream. Do not defend the items. Just listen. The answer will contain at least one number that surprises you, and that number is the beginning of the only feedback loop that makes any of this correctable.