Jackson Bates

Not Every Bug Is a Fire

Last week a customer success manager flagged a bug in a teacher workflow. Bulk renaming classes wasn't working. By the time it reached me, the CSM had already resolved it manually for the customer, and a colleague was asking if I could spare engineers to fix it that day.

I didn't pull anyone off their work. Here's why.

The "Customer" Reflex #

There's a well-worn instinct in product and engineering teams: when a bug comes from a customer (or their representative), treat it as urgent. The word "customer" can short-circuit the triage process entirely. It signals consequence. It implies someone is blocked, unhappy, at risk of churning.

That instinct exists for good reasons. Customer problems matter. But urgency and customer proximity aren't the same thing, and conflating them is how you end up with a team that's constantly reactive, shipping less, and burning out.

Two Questions That Do the Work #

Before escalating anything to my team, I asked two questions:

How urgent is the actual fix? Not how urgent the report feels, but how urgent it actually is. The CSM had already resolved it manually. The customer was unblocked. The "fire" had already been put out.

How often does this actually happen? A bug that affects 40% of your users every week is a different problem from one that affects a rare workflow that most users will never encounter. This one was the latter.

Two questions. Five minutes. Zero disruption to the team.

I wrote a Jira ticket to investigate later and moved on.

What Good Triage Actually Looks Like #

Triage isn't about dismissing problems; it's about putting them in the right queue at the right time. A bug worth fixing next sprint is still worth fixing. It just doesn't need to blow up your current one.

A few principles I come back to:

Resolved ≠ unimportant, but it does change urgency. If the customer is already unblocked, the calculus shifts. You're no longer racing against a live issue. You're scheduling a fix for a latent one.

Frequency is your most underrated signal. Before you mobilise engineers, ask: how many users hit this? How often? A rare bug in an edge-case workflow is not the same as a common bug in a core one, even if the customer report feels identical.

Proximity to the customer isn't the same as impact. A bug that lands in your inbox through a CSM, a sales rep, or a support ticket feels urgent because it has a human face. But that's a feature of how you heard about it, not of the bug itself.

The Real Cost of Over-Escalating #

Every time you pull an engineer off focused work to triage a non-urgent bug, you're making a trade. You might not feel it immediately, but it compounds. Context switching is expensive. Interrupted sprints accumulate. And teams that learn their priorities can change at any moment stop trusting their roadmap, which makes planning harder for everyone.

Protecting your team's focus isn't a nice-to-have. It's part of the job.

Not every bug is a fire. Some are. But before you sound the alarm, ask the two questions. Most of the time, five minutes of triage is all it takes to find out you didn't need to pull the alarm at all.