How it works

The invisible queue

Why your best people can't do their best work — and what to do about it.

Every company runs on a hidden traffic system, and almost nobody can see it. It's not in your project tracker, your org chart, or your sprint board. It lives in the gaps between people — in who is waiting on whom. We call it the invisible queue, and it's the reason your most capable people often produce the least of their best work.

Work is a web of queues

A network of team members connected by arrows, with small stacks of work waiting on several of the connections.

Zoom out from any team and the work stops looking like a to-do list and starts looking like a network. Design hands to backend, backend to platform, platform to QA, QA to release. Every arrow is a request waiting on a person. Each of those waits is a tiny queue — and a company has thousands of them, forming and clearing every hour.

This is normal. Queues aren't the problem. The problem is what happens when you can't see them.

The queue is invisible

The same network, but the queues of waiting work are drawn as faint dashed outlines an observer can't see.

The queues are scattered across DMs, threads, tickets, and people's heads. No dashboard shows them. So from the outside, everything looks fine — work is moving, people are responsive, Slack is busy. The pile-up is real, but it's invisible, which means no one can manage it.

You can't manage a queue you can't see.

And an unmanaged queue doesn't distribute itself evenly. It routes by who you know can do it — not by who has capacity.

Your best people become the intersection

Many waiting team members with arrows all converging on one central, overloaded person marked Slammed, with work piling onto them.

Guess who everyone knows can do it. Your strongest engineer, your sharpest PM, the person who "just gets it." Because the queue is invisible, demand quietly converges on them. They become the intersection every lane merges through.

And here's the cruel part: each request arrives as an interruption, and great work is the one thing that needs unbroken stretches of time. So the people most capable of doing something excellent get the least room to do it. They spend their day looking collaborative — answering, unblocking, context-switching — while the work only they can do sits and waits.

One overloaded node stalls the whole line

A pipeline where work flows into an overloaded bottleneck, then only trickles onward while the downstream people sit idle, waiting.

It gets worse, because a bottleneck doesn't just slow itself down — it slows everything downstream of it. Work piles up in front of your overloaded node, while the people after them sit idle, waiting on output that never comes. The whole line moves at the speed of its most overloaded person.

And because leaders can't see the bottleneck either, they do the natural thing: pile more onto it. "They're the best — give it to them." Which makes the line slower still. This is the counterintuitive heart of the Theory of Constraints: past a point, adding work to the bottleneck reduces total output.

Relieve the constraint, and the whole line speeds up

The same pipeline after relief: the bottleneck is protected for deep work, the queue is small, and everyone downstream is flowing again with wait time down 42 percent.

The fix isn't a faster person or a louder standup. It's visibility. Once you can see where work is piling up — who's slammed, what's stacked behind them — you can do the one thing that actually works: protect the constraint. Route around it, pre-qualify what reaches it, and give it room for deep work.

Relieve the bottleneck and the queue drains. Wait time drops, and throughput rises — that's Little's Law, not a hope. Counterintuitively, less work at the bottleneck means more total output, and your best people finally get to do their best work.

That's what Currant does. It makes the invisible queue visible, right inside Slack.

Do your best work, with fewer interruptions.

Async work, human pace.