Work that has no end state
Most work has a finished condition. A project ships. A design gets approved. A migration completes and the thing that consumed six months stops existing.
Operations has none of that. The queue is not a backlog to be cleared; it is a rate. Tickets arrive because the estate is in use, and the arrival does not slow down because you got faster. On the best day of your career you close more than arrived, and the next morning the queue is there again, and nothing in the interface distinguishes that day from a bad one.
That is not a complaint about ticketing systems. It is the defining structural feature of the work, and almost everything else in this article follows from it.
No completion signal, so no rest signal
Finishing something produces a small, real, physiological release. Work that never finishes never produces it.
So people in operations rest without the feeling of having earned it, which is a different and worse kind of rest — the weekend spent with the vague sense of being behind, the evening that does not quite land because the number is still there. Nobody is behind. There is no ahead. But the queue does not say so, and the count sitting at the top of the screen looks exactly like a debt.
The fix is not a mental trick, and pretending otherwise is where most advice on this goes wrong. It is to have some other signal that does complete: a thing finished today, written somewhere that is not the queue. A runbook rewritten, one recurring fault permanently killed, one page of documentation somebody will find. The queue will not give you the feeling. Something else has to.
What it does to judgement
This is the part that shows up in outcomes rather than in morale.
Closing outranks resolving. Depth is the visible number, so the incentive attaches to touching a ticket rather than to ending the problem. That is the mechanism behind a large share of what the recurrence later has to untangle — not carelessness, but a measurement pointing one degree away from the goal.
The loudest wins, and that is a queue effect rather than a judgement failure. With forty items and no time to read forty, attention goes to whoever escalated most recently. Triage exists to counter exactly this, and it only works if somebody is protected long enough to do it.
Context switching is more expensive here than elsewhere. An investigation lives in working memory — the ruled-out list, the shape of the hypothesis, the thing you were about to check. Dropping it to answer something urgent costs the reload, and the reload is not free the way answering an email is. Two half-investigations cost more than two whole ones.
What actually helps
Small things, and none of them are attitude:
Batch by kind, not by arrival. Six certificate questions answered consecutively cost a fraction of six answered between other things, because the context is already loaded.
Protect one block. An hour where the queue is somebody else's problem is worth more than three hours of availability, and it is the only way a hard ticket ever gets finished rather than repeatedly restarted.
Count what you ended, not what you touched. A private list of problems that will not come back is the only score in this job that behaves like a score.
For whoever manages a queue
Queue depth measures arrival rate. It is a property of the estate, the customer base and the change calendar — and only marginally a property of the people working it. Managing the number by pressing the people converts a capacity signal into a morale problem while leaving the capacity unchanged.
The two numbers worth watching instead are reopen rate — which says whether closing is standing in for resolving — and how much time goes to things that have been seen before, which is the real, fixable, recurring load. A queue full of first-time problems is a busy team. A queue full of familiar ones is an unpaid debt, and it is the estate's debt rather than theirs.