Fast support is not always the win

The message came in right after lunch. A report was wrong, and a team on the other side of the office couldn't finish their work.

Two of our engineers were on it within minutes. They found the problem, patched it, and replied before their coffee went cold. The other team sent a thank-you. Our engineers walked back to their desks a little taller.

Three days later, the same kind of message. Same quick reply. Same fix. Same thank-you.

Then it happened again.

Good, bad, ugly... and treasure

Every six weeks, the team runs a retrospective. The format isn't mine. I picked it up somewhere and loved it. It's named after the old western The Good, the Bad and the Ugly, with one extra pile:

• The good: what good things happened?
• The bad: what bad things happened?
• The ugly: what could have been better?
• The treasure: what treasure are we working toward?

Then we turn it all into follow-up actions. One rule matters most: focus on improvement, not blame.

At the next retro, the support work landed under good. Fast replies, happy teammates, lots of thank-yous. I moved it to ugly.

Not to blame anyone. The engineers were fast, kind, and genuinely happy to help. But fast support feels like a win, and that's exactly why nobody questions it. Fixing the same kind of problem every few days isn't great service. It's a loop, and everyone in it is too busy being helpful to notice.

Being quick is good. Being needed for the same thing again and again is nothing to celebrate.

Fix the loop, not the ticket

A fast reply is good. A problem that never comes back is better.

So the question changed. Not "how quickly can we fix this?" but "why did this happen at all, and how do we make sure it can't happen again?"

We will never catch every case. Software breaks in ways nobody imagined. But we can make one promise: when something breaks, we should be the first to know. Not the user. Not the other team. Us.

Tools make this easier than ever. Error trackers like Sentry or AppSignal catch crashes the moment they happen, with enough detail to fix them. On a good day, the problem is gone before anyone outside the team even knew it existed.

The treasure

So this is what went into our treasure pile, the thing we're working toward:

The best support is no support. If the issue never happens, nobody has to ask for help, nobody has to explain it, and nobody has to wait.

Be proud of your fast fixes. Then be even prouder of the day they stop being needed.