Over the years I’ve noticed I keep solving the same kind of problem.

Too many support requests.

Too many connection failures.

Too many customer escalations.

Too many flaky tests.

The thing itself changes, but the process I use doesn’t change very much. Sometimes it’s handed to me as a quarterly goal, sometimes it’s a problem I inherit, and sometimes it’s something I notice because the people around me keep running into it over and over. However it comes to my attention, the approach is usually the same. Recently, it took support escalations to engineering from 34 a week down to 9.5, a reduction of over two thirds, across a six month period. This is the process I used to get there.

1. Count it

The first thing I want is a baseline, and I don’t much care how I get it. A SQL query, a spreadsheet, a Jira filter I run once a week, an existing dashboard if someone already built one. Any of those will do. Don’t spend weeks building perfect reporting before you start improving the problem, because good enough really is good enough here. All you need is a way to tell whether you’re making things better.

2. Understand it

Next I gather a sample and start looking for patterns. Sometimes that’s the last 30 days, sometimes the last 100 occurrences, sometimes more. There isn’t a magic number. You want enough data that patterns start to emerge, but not so much that categorizing it becomes the project itself.

I usually start by grouping things by root cause. The buckets come out different every time, so I can’t tell you what yours will be. That’s the exercise. And while I’m sorting, I’m already thinking ahead: sometimes several root causes share one obvious fix, and sometimes a single root cause needs several. Either way is fine. The buckets aren’t the goal. Understanding the problem well enough to act on it is.

3. Think about fixes

Once the patterns are obvious, I start asking a simple question of each bucket: what would make this one smaller? Sometimes the answer is a retry with exponential backoff, sometimes it’s a better error message, sometimes it’s documentation or training, and sometimes it’s a real engineering project. Every so often I look at a bucket and realize there isn’t much I can do about it, which is fine too. The goal isn’t to eliminate every bucket. It’s to understand what my options are.

4. Invest

Now I have something I can prioritize. For each potential fix I weigh two things: how much of the problem it solves, and how much work it takes. I’m looking for the highest return on the investment. Sometimes you find something that wipes out a big chunk of the problem for almost no effort, and those are easy calls. Other times you find a massive project that only chips away at a small bucket, and then you have to decide whether it’s worth doing at all.

When two ideas are roughly equal, I lean toward the one I can ship sooner. Getting into production sooner means I start improving the metric sooner, and I find out sooner whether I was right. You don’t need perfect estimates. You’re just trying to make good investment decisions.

5. Keep measuring

This is the one place where I start to care more about automation. If a problem is important enough to spend engineering time on, it’s important enough for a durable tracking system. I don’t want to depend on remembering to run a SQL query every Friday forever. Manual processes have a way of quietly disappearing. So I’ll automate the report, stand up a simple dashboard, or have the numbers posted into Slack every week. Sometimes those reports are absurdly niche, and that’s fine. They exist to answer one question: are the changes we’re making actually working?

The drop I mentioned up top, support escalations to engineering going from 34 a week to 9.5, is what watching that number every week produced. For that one I worked with our data team to model the raw data through DBT and stand it up as a self-updating Sigma dashboard, so the number kept itself current instead of waiting on me to remember. Once the reporting was in place, I could see the weekly volume falling, and see that it kept falling even as we added customers. That second part is why I normalize the number, tracking it per engineer, per customer, and per dollar under management. A raw count can fool you in a growing company. Picking the right normalization is a big part of picking the right metric to drive down in the first place.

6. Repeat

The first time through, you’ll probably end up with a few big buckets and a long tail of odd one-offs. Don’t worry too much about the long tail. If a handful of patterns explain most of the problem, that’s enough to get moving. Fix the biggest things, wait for the changes to take effect, then look at the next batch.

The interesting part is that the buckets almost always shift. The biggest problems from six months ago might barely exist anymore, and some pattern you’d never have guessed has moved to the top. That’s exactly what you want. You’re not trying to produce the perfect taxonomy of every failure. You’re trying to keep making the thing happen less often.

I’ve used this same process for support requests, connection failures, customer escalations, and plenty of other recurring problems. The metric changes every time, but the process doesn’t.