Your Backlog Is a Leadership Problem
Every support and services leader I know has had the conversation. The backlog is growing. Cases are aging. SLAs are slipping. The team is working harder than ever and still falling behind. And the request that goes up the chain is always the same: we need more people.
Sometimes that’s true. Sometimes you’re genuinely understaffed, and the only fix is headcount. But in my experience — across multiple organizations, multiple scales, multiple industries — the backlog is almost never a staffing problem. It’s a symptom of something upstream that’s broken, and adding people to a broken system just means more people working inside a broken system.
I learned this the hard way when I inherited a support organization with a backlog that had been growing steadily for eighteen months. The team was talented and hardworking. Management was doing everything they could to keep up. And the ask had been the same every quarter: more headcount, more headcount, more headcount. Each time, a few new positions were approved. And each time, the backlog kept growing.
By the time I arrived, the backlog was at an all-time high and the team was demoralized. Not because the work was hard — because no matter how hard they worked, they couldn’t dig out. That’s a particular kind of exhaustion that leads good people to quit, which makes the backlog worse, which makes more people quit. It’s a death spiral.
Diagnosing the real problem
The first thing I did was stop looking at the backlog as a number and start looking at it as a story. Not “how many cases are open” but “why are these cases open?”
The analysis revealed three root causes that had nothing to do with headcount:
Repeat contacts. Roughly a third of the backlog consisted of cases that were variations of the same issue — a known product defect that hadn’t been prioritized for a fix, a configuration problem that kept recurring because the documentation was wrong, a process gap that caused customers to call back because their issue wasn’t actually resolved the first time. We weren’t dealing with a thousand unique problems. We were dealing with a hundred problems, many of which were coming back two, three, four times.
Unclear ownership. Another large chunk of the backlog was cases that were technically open but not actively being worked — because they were stuck between teams. Support had done their part but needed engineering input. Or the case required a decision from product management. Or the customer had been escalated to an account manager who hadn’t followed up. These cases weren’t backlogged because the support team was slow. They were backlogged because nobody owned the end-to-end resolution.
Misrouted work. A surprising number of cases in the backlog weren’t even support cases. They were billing questions, feature requests, sales inquiries, and other issues that had landed in the support queue because there was no better place for them to go. The support team was spending time triaging and routing work that should never have reached them in the first place.
None of these problems would be solved by hiring more support analysts. More analysts would handle more of the incoming volume, but the repeat contacts would keep coming, the ownership gaps would keep stalling cases, and the misrouted work would keep consuming capacity. The backlog would plateau at a new level, and six months later, the ask would be for more headcount again.
Fixing the inputs
Instead of requesting headcount, I spent the first quarter attacking the root causes.
For repeat contacts, I built a “top ten” list of the issues generating the most case volume and took it to the product and engineering teams. Not as a suggestion — as a business case. Here’s how many cases each defect is generating. Here’s the cost in analyst time. Here’s the customer impact. Some were fixed within weeks. Others took longer. But over the course of six months, we eliminated the defects and documentation gaps responsible for roughly 30 percent of our case volume.
For ownership gaps, I implemented a single-owner model for escalated cases. One person, accountable for driving the case to resolution regardless of how many teams were involved. That person had the authority to pull in resources, set deadlines, and escalate blockers. Cases that had been sitting for weeks started moving within days — not because the work was easier, but because someone was actually responsible for the outcome.
For misrouted work, we rebuilt the intake process. Better categorization at the front door. Automated routing for common non-support requests. A clear handoff process for cases that needed to go to other teams. This was operational plumbing — not glamorous, but it freed up significant capacity that had been wasted on work the support team shouldn’t have been handling.
The results
Within six months, the backlog was cut in half. Within a year, it was down to a sustainable level that the team could manage without heroics. We did eventually add some headcount — but targeted hires in specific skill areas, not a blanket request for more bodies. The total investment was a fraction of what had been repeatedly requested, and the results were dramatically better.
The team’s morale turned around too. The feeling of drowning — of working as hard as you can and still falling behind — was replaced by a sense of control. Cases were being resolved. The work they were doing was actually support work, not administrative overhead. And when they escalated something, it actually got addressed instead of disappearing into a void.
The backlog wasn’t a staffing problem. It was a system problem. And fixing the system was cheaper, faster, and more sustainable than any amount of hiring would have been.
The technology trap
One of the other responses I see when backlogs grow is the technology pitch. “If we implement this new tool, we’ll improve efficiency by 30 percent and the backlog will come down.” I’ve been sold this story more times than I can count, and it’s true about as often as the headcount story — which is to say, sometimes, but usually not.
Technology can absolutely improve efficiency. I’ve seen tools that genuinely transformed how a team operates — better case management systems, smarter routing engines, knowledge bases that actually help analysts find answers. But technology amplifies the system it’s deployed into. If the system is broken — if cases are being generated by unresolved defects, stalled by ownership gaps, and inflated by misrouted work — a new tool just helps you be broken faster.
I always insist on process fixes before technology investments. Fix the workflow, then automate it. Not the other way around. Automating a bad process doesn’t make it good. It makes it a bad process that runs at scale.
The leadership failure
Here’s the part that’s hardest to say: a growing backlog is a leadership failure. Not a team failure. The people working the cases are rarely the problem. The problem is upstream — in the decisions (or non-decisions) that leaders are making about product quality, process design, resource allocation, and cross-functional accountability.
When product management deprioritizes known defects because they’re not “customer-facing enough” — that’s a leadership decision that shows up in the backlog. When there’s no clear escalation path between support and engineering — that’s a leadership gap. When the intake process hasn’t been reviewed in three years because nobody owns it — that’s a leadership neglect.
The backlog is the support team’s problem to manage, but it’s leadership’s problem to solve. And “solve” doesn’t mean “approve more headcount.” It means looking at the entire system — from how work enters the queue to how it gets resolved — and fixing the parts that are generating unnecessary volume, stalling resolution, or consuming capacity without producing outcomes.
What I’d ask any leader with a growing backlog
Before you submit the headcount request, answer these questions:
What percentage of your backlog is repeat contacts from known, unresolved issues? If you don’t know, you haven’t diagnosed the problem yet.
How many cases are stuck waiting on another team? If the number is significant, you don’t have a backlog problem — you have an ownership problem.
What percentage of incoming work is actually within your team’s scope? If you’re handling a meaningful volume of misrouted work, you’re subsidizing other teams’ missing processes with your team’s capacity.
When was the last time someone reviewed the end-to-end workflow from case creation to resolution? If the answer is “I don’t know” or “more than a year ago,” the process has almost certainly degraded.
The backlog is talking to you. It’s telling you where the system is broken. The question is whether leadership is listening — or just asking for more people to process the symptoms.
— Bruno