Ask two people in the same organization what IT is working on this week and you'll get two answers that don't reconcile. Neither person is wrong. They're reading different lists.
There's the one in the system: tickets, project plans, the work that has names and gets airtime. And there's the one that lives in threads, inboxes, escalations, vendor pings, and the favors that never made it into a record. Both are real. Both consume the same people.
Two lists don't just add overhead. They let the organization hold two accounts of what's happening and pick whichever one the current conversation calls for. That isn't dishonesty. It's what having two sources of sequence produces.
Systems of record and orderings are different things
This is where the rule usually gets misread. People hear "one queue" and picture a migration: every request into one tool, one backlog, one interface, and a project to get there.
That's not it, and insisting on it usually kills the idea before it does any good. Plenty of organizations run several systems of record for good reasons. Incidents live in one place, engineering work in another, vendor and procurement work somewhere else, and each of those systems fits the work it holds.
One queue means one authoritative sequence. The lists can be federated as long as they feed a single ordering that says what comes next. What can't be federated is the sequence itself. When there are two sequences, something has to arbitrate between them, and the thing that arbitrates is almost always escalation.
Escalation is what fills the gap
When no shared ordering exists, the organization doesn't stop prioritizing. It prioritizes through whoever is loudest, closest to leadership, or under the most visible deadline. Work moves because someone made it uncomfortable not to move it.
I want to be careful here, because this is the point where the diagnosis usually turns into blame. A leader who escalates to get something moving isn't playing politics. They're using the only mechanism the system gave them for changing sequence. If you take escalation away without providing an ordering that responds, you haven't fixed anything. You've removed the one lever that worked.
The behavior is a symptom of a missing mechanism. Build the mechanism and most of the behavior goes away on its own.
Priority labels don't answer the question
Categories look like an ordering and aren't one. High, medium, and low sort work into groups. They say nothing about what happens first inside a group, which is exactly the question that matters once there's more than a couple of items in the top one.
Under real load, the top category fills up. At that point the label has stopped carrying information and something else is deciding sequence. Usually that something else is escalation again, now operating inside a structure that appears to have priorities.
An ordering answers a narrower and more useful question: of these two things, which one moves first, and what happens to the other one.
Three questions that show whether the ordering is real
There's a test I use early in almost every engagement, because it takes about a minute and the answer is difficult to fake.
Ask what's next. Ask what moved since last week. Ask what got displaced because something else jumped ahead of it.
If those answers come back quickly and from one place, the ordering exists. If answering requires someone to check with two other people, reconcile a private list against the official one, or convene a short meeting to establish what actually happened, then the ordering doesn't exist yet. What exists is a reconciliation habit that produces an answer on request.
The third question is the one that gets skipped. What's next and what moved can both be answered from a list. Displacement can only be answered by something that holds a sequence, because displacement is a statement about the relationship between two items.
Someone has to own the sequence
An ordering needs an accountable owner or a defined route for changing it. Not a committee that aligns weekly and then watches side conversations override the outcome between meetings, and not a tool that maintains itself.
This is the part organizations resist hardest, because owning the sequence means being the person who says what doesn't move. That's uncomfortable in a way that "we're aligned on priorities" never is. It's also the only version that survives contact with a busy quarter.
The owner doesn't need authority over every input. They need one clear route by which the sequence changes, so that a change is a decision somebody made rather than an outcome that emerged.
When the answer requires reconciling private lists and side conversations, prioritization is already happening through escalation. The meeting where you reconcile them is not the fix. It's the cost of not having done it.