On Monday I asked a simple question: how does your team decide what gets worked first each morning?
I asked because of a pattern I saw many times while leading technology in specialty pharmacy, and in the operations I supported before that.
When work backs up, the first request is almost always for more people.
Sometimes that’s the right answer. But more often than I expected, the backlog was telling us something else. It looked like a capacity problem because a capacity problem is the easiest one to see.
Why capacity gets blamed first
A backlog is visible. You can count it. It grows on a report, it shows up in a meeting, and the people working it are clearly busy.
What a backlog doesn’t show is why the work is sitting there. A hundred open cases can mean a hundred cases nobody has reached yet. They can also mean forty waiting on someone outside the organization, twenty that came back for a second pass, fifteen nobody is sure belong to them, and twenty-five that genuinely need more hands.
Those are five different problems. Only one of them gets fixed by adding people.
Four problems that look like capacity
1. Sequencing. The work is there, and the people are there, but the order is wrong. Oldest-first queues are the usual cause. Urgent work waits behind work that’s older but not urgent, and work that’s blocked takes the same space as work that’s ready. Adding people to a badly ordered queue mostly gets the wrong work done faster.
2. Ownership. Some work isn’t waiting for capacity. It’s waiting for a decision about whose it is. It sits between two teams, or between a team and a system, and each side reasonably assumes the other has it. A new hire inherits the same ambiguity.
3. Rework. Work that comes back is counted as work, but it’s the same case being touched again: missing information discovered late, a handoff that didn’t carry what the next step needed, a correction that didn’t stick. If a meaningful share of the queue has been touched before, the problem is upstream, not headcount.
4. Waiting that’s counted as workload. Cases waiting on an outside party are open, so they look like work. But nobody on the team can move them until something comes back. Counting them as backlog makes the team look further behind than it is, and hides the follow-up discipline that actually controls how long they wait.
How I’d tell the difference
You don’t need a new system to find out which problem you have. You need a week of looking at the backlog differently.
Take a sample of open work, even 50 items, and for each one write down:
- What is it waiting on right now? A person on our team, a decision, information from outside, or nothing (it’s ready).
- Who owns the next move? A named person or team, or “unclear.”
- Has it been touched before? First pass, or returned for another one.
- What happens if it waits until tomorrow? Nothing, a delay the patient or customer feels, or a deadline missed.
Then sort the sample by those answers instead of by age.
If most of it is ready and simply unreached, you may well have a capacity problem, and now you can size it honestly. If most of it is waiting on something other than effort, the fix looks different.
What usually helps more than headcount
A few things I’ve seen make a bigger difference than adding people, when the diagnosis supports them:
- Order the work by what it’s waiting on and what’s at stake, not by when it arrived.
- Separate “ready,” “blocked internally” and “waiting externally” so they stop looking like the same backlog.
- Name an owner for the work that sits between teams, including the exceptions nobody designed for.
- Fix the handoff that keeps sending work back. The returned case is the cheapest place to find it.
- Give external waits a follow-up rhythm, so waiting is managed instead of discovered.
None of these are technology projects to start with. Some become one later, when the team needs the queue to answer those questions on its own instead of in a weekly spreadsheet. But the order matters: diagnosis first, tools second.
One exercise for this week
Pull 20 items from your oldest open work. Ask the four questions above for each.
Count how many are actually waiting for more effort.
That number is the real size of your capacity problem. The rest of the list is where the faster gains usually are.
The other half of this, what I listen for when the fix arrives as a proposal, is in this companion post.