TrenchOps 🐎

Insights from the tech trenches

Cover Image

The Day I Grew Our Backlog by 2000% Without a Single New Ticket

SupportTrenches Systems, Processes & Resilience 5 minutes

One saved filter hid a decade of ghost customers - and my reward for finding them was being asked to hide them again

Years ago, at a very large company with a very mature support organization, I picked up a side project: reduce our Mean Time To Resolution (MTTR - the average time from ticket opened to ticket solved). Standard stuff. Analyze the tooling, tighten the workflow, present slides, collect polite applause.

Instead I found a black hole.

The workflow was textbook. Customer opens a ticket, engineer resolves it, engineer closes it. Every engineer used the same saved filter - documented in the onboarding wiki, inherited by every new hire since roughly the invention of the smartphone: "Show my open tickets."

While rebuilding our views, I changed one line. My filter now read: "Show my open tickets AND closed tickets with an inbound customer message."

Hundreds of tickets appeared out of nowhere.

Most were harmless. "Thank you again for your support!" Lovely people, talking politely into a void. But scattered between the thank-yous: "This issue still exists, please help." "I would like to reopen this case." "Is anyone there?"

Hundreds of customers, across years, who came back after closure and received the corporate equivalent of a dial tone.

The part that actually matters: a state with no owner does not exist

Nobody was lazy. Nobody was cynical. I worked with genuinely excellent engineers 🐎 who would have crawled through broken glass for those customers - if they had ever seen the message.

Here is the mechanism, and it applies far beyond support: your queues are your real org chart. Not the one in the HR system. The set of views your people open in the morning is the complete list of things your company is capable of noticing. Anything living in a state that no view displays has no owner, and anything without an owner does not exist as work. It exists only as damage.

Conway's Law - the observation that systems end up mirroring the communication structure of the organization that builds them - is usually quoted about software architecture. It runs in reverse too, and harder. Our tooling had a state called "closed with new customer input." Our organization had no role that owned it. So the tool won. Ten years, one direction.

And notice how the fence got built: nobody built it. Chesterton's fence says don't tear down a fence before you know why someone put it there. The uncomfortable corollary nobody quotes is that some fences were never put there by anyone. They accreted. A default filter written by a person who left in a previous decade, copied into a wiki, blessed by repetition, and eventually mistaken for policy. There was no reasoning to respect, only sediment.

The inversion is what still makes me wince. If you asked me to design a support organization that quietly destroys renewal revenue while every dashboard stays green, I would do exactly one thing: I would route the customer's most desperate follow-up into a state that no report queries. That's it. No incompetence required. No villain. One filter.

Why management's first reaction was a fire drill

The backlog jumped by something like 2000% overnight, and I was asked - with real urgency - to revert whatever I had done.

Think about that instinct. The problem was ten years old. The only new thing in the building was visibility. But visibility is not neutral: for a decade, MTTR had been an honest answer to a dishonest question. The measure never lied. It just never counted the misery, because the misery had been filtered out before the query ran. Fix the map and suddenly the territory looks like it grew teeth.

This is where good engineers lose. I walked in with data. Data reads as accusation. What I should have led with - and what eventually worked - was framing: this debt already exists, it has existed since before most of us joined, and we are the first team on earth able to see it. Same facts, completely different emotional shape. Logic moves nobody who is currently calculating how this makes them look.

We worked the pile. Apologized generously and without excuses, which customers forgive far more readily than silence. Wrote the filter into the daily routine and the wiki. Roughly ninety days later our Customer Satisfaction score was up about four points. No AI initiative (which didn't exist back then anyway), no reorg, no seven-figure tooling migration. One line in a filter definition, later rolled out to every support team in the company.

My reward was a handshake. Management's reward was, let's say, more liquid. I've made peace with it. Mostly.

πŸ‘‰ Audit your default views like you audit production code. For every object in your system, list the states it can occupy, then check which of those states appear in somebody's morning view. The states that appear nowhere are your black holes, and they are always the ones containing your angriest customers.

πŸ‘‰ A metric is a query plus a filter. Everyone argues about the metric. Nobody reads the filter. The filter is where the lying happens, and it usually lies by omission written years ago by someone who meant well.

πŸ‘‰ Before you switch on the lights, script the sentence. "This is not new damage, it is newly visible damage" buys you a working session instead of a witch hunt.

πŸ‘‰ The cheapest satisfaction win is almost never a new capability. It is stopping an ongoing insult you didn't know you were delivering.

Every organization has customers screaming into a state nobody owns. The healthy ones can name that state. The rest have a very impressive dashboard.

πŸ‘‡ Which states in your systems have no owner - and who would find out first if a customer got stuck in one?

This article is also available in German.


Corporate CultureCustomer SatisfactionCustomer ServiceIncentivesManagementDocumentation

0 comment(s)

No comments yet. Be the first to comment.

Leave a comment

0 / 1000