The One Queue Rule: If there are two backlogs, the org runs on escalation

The No-Surprise IT Playbook (Operator Insights)

• Chapter 1: The Side Door Problem

If there are two backlogs, you’re managing narrative, not work.

Growth companies don’t usually struggle to explain what’s happening in Sales, Ops, or Customer Success. The numbers may be ugly, but the mechanisms are legible: pipeline, throughput, churn. You can argue about priorities, but you can at least agree on what “in flight” means and what moved this week. IT loses that clarity faster than most functions for a predictable reason: work doesn’t enter through one channel, and it doesn’t wait patiently in one place. Once you start routing side doors into a hub, the next failure mode shows up immediately. Most organizations are already operating on more than one backlog, and the hub simply makes the split visible.

There’s the official backlog: tickets, project plans, and the work that gets names and airtime. Then there’s the shadow backlog: Slack threads, DMs, inbox asks, escalations, vendor pings, and “quick favors” that bypassed intake because it felt urgent, political, or simply easier to route around the system. Two backlogs don’t just create overhead. They break truth, because they allow the organization to tell two different stories about what’s “really happening” depending on which channel you ask.

Why two backlogs turn status into theater

When there isn’t one authoritative work list, reporting stops being a readout and becomes translation. Teams spend time reconciling “what’s in the system” versus “what’s actually happening.” Leaders hear different versions of reality depending on who they ask and where they ask. Loud work moves first, but it moves invisibly, so the official plan stays intact until it suddenly doesn’t. The gap gets filled with meetings, dashboards, templates, and carefully worded updates, which can improve presentation while the work system remains split.

This is the part most companies misdiagnose. They treat it as a reporting problem and invest in reporting: more cadence, more structure, more “better status.” If work is fragmented, the reporting layer becomes the product. The work becomes secondary.

The One Queue Rule

The fix is blunt: a single total ordering of work. Not categories and not buckets, an actual sequence. One authoritative list that includes planned work, unplanned work, vendor work, escalations, and the “quick favors” that consume capacity and create delivery risk. If it isn’t on the list, it isn’t real. If it’s real, it competes with other real work in the same ordering.

This is the point most operating models dodge, because it forces scarcity into the open. It forces trade-offs into the open. It also forces someone to own the ordering, which is where most “alignment” systems quietly fail. If nobody owns the ordering, the ordering still happens. It just happens via escalation, favors, and who can create the most discomfort.

Why priority buckets fail under load

Priority buckets are not an ordering. They’re labels. When volume is low, buckets feel fine. When volume is high, buckets become permission slips for escalation. “High” turns into a political category, not an operational one.

When everything is “high,” the real ordering is determined by who escalates, who asks in the right channel, whose deadline feels scarier, which vendor is noisy, and who has the ear of leadership. At that point, you are not managing work. You are managing competing narratives about what matters most.

What “one queue” looks like in practice

A real one-queue system has three properties: one authoritative list, one ordering, and one owner of the ordering. “One list” means everything that consumes capacity routes into the same queue even if it starts elsewhere. That Slack escalation about vendor access still becomes a real work item with an owner, a definition of done, and an expiry or follow-up date. It gets ordered against other work, and if it moves up the list, something else moves down.

“One ordering” means a real sequence, not buckets. If something jumps the line, the displacement is explicit. The organization stops pretending it can do everything at once and starts naming the trade it was already making silently.

“One owner” means there is a named person or function accountable for maintaining the ordering and forcing explicit trades when urgency shows up. Not a committee that “aligns” once a week and then watches side channels override the decisions.

If you want to sanity-check whether you actually have one queue, ask whether the hub can answer three questions without a performance: what’s next, what moved, and what got displaced because something else jumped the line. If those answers require interpretation, side conversations, or a special meeting, you don’t have one queue. You have a negotiation.

The win condition

The goal is not bureaucracy. The goal is to make the truth cheap. When the work system is singular, you can get honest answers quickly: what the org is doing, what it is not doing, what changed, and what it cost in displacement and time. That restores progress visibility without turning status into a performance.

Simple principle: one queue, one ordering, one owner.