Most of the teams I’ve worked with are good at incidents. Something breaks, people pile on, service comes back, someone writes a summary. That part usually works.
What’s almost always missing is what happens next. The ticket closes, everyone goes back to their day, and six weeks later the same thing happens again. New ticket, new bridge call, same fix. When I ask why, the answer is some version of “we knew about that one.”
That gap has a name. Incident management restores service. Problem management removes the cause. They are different jobs, with different clocks, and when an organization only staffs the first one it pays for the same outage over and over.
The clocks are different
This is the part that trips people up.
- An incident is measured in minutes. The only question that matters is how fast service comes back. Root cause is a distraction during an incident — if restarting the service fixes it, restart the service.
- A problem is measured in weeks. Nobody is under pressure. You have time to actually find out why the disk filled up, and whether it will fill up again on the other forty hosts.
Trying to do both at once is how you get a three-hour bridge call where fifteen people watch two engineers argue about a theory while the business is still down.
What a problem record needs
I keep it deliberately small. A problem record that nobody fills in is worse than none at all, because it tells you the process exists when it doesn’t.
- A trigger. What made this a problem — a repeat incident, a major incident, a near miss.
- An owner. A person, not a team. Teams don’t investigate anything.
- A hypothesis. What we currently think is true, written down so we can be wrong on the record.
- A decision. Fix it, live with it, or accept it until a dependency changes. “Accept it” is a legitimate answer. “Still investigating” nine months later is not.
That last one matters more than people expect. A lot of problem backlogs are really decision backlogs. Nobody wants to say out loud that we’re going to live with a weekly restart, so the record stays open forever and everyone pretends it’s being worked.
How you know it’s working
The metric isn’t how many problem records you opened. It’s repeat incident rate — what share of this month’s incidents are things you’d seen before.
If that number isn’t moving, your problem process is a filing system.
The uncomfortable version of this: for a while, doing problem management properly makes your incident numbers look worse, because you finally start linking the repeats you used to count as unrelated. That’s a reporting conversation to have up front with whoever reads the dashboard, not a surprise to spring on them in month three.