6.6
Triage — Fix It Or Escalate It
Why this exists
Your check fires at 6:40am. Now what?
This is the decision that defines the job, and almost nobody writes it down. Fix it yourself and you might make it worse. Escalate everything and you're a very expensive alert forwarder. The value is in deciding correctly, quickly, most of the time.
The idea
Two questions. Two minutes. Then act.
1. Do I understand what's wrong? 2. Can I undo what I'm about to do?
| Understand? | Can undo? | Do this |
|---|---|---|
| Yes | Yes | Fix it. Then say what you did. |
| Yes | No | Escalate, with your diagnosis. You know the answer; you don't own the risk. |
| No | Yes | Investigate read-only. Fifteen minutes. Then re-ask. |
| No | No | Escalate now. Don't touch it. |
That's it. It fits on a card and it will be right most of the time.
Escalating is not failing. This is worth internalising early, because the instinct is to prove you can handle it. The person who escalates a payment problem they don't understand is doing the job correctly. The person who quietly tries three fixes first, and escalates at 9am with the system in a stranger state than they found it, is not.
How you escalate matters more than when. Compare:
"The booking sync is broken."
"Booking sync hasn't run since 02:15. The 6am check fired. Last successful run was yesterday. Nothing deployed since Friday. Error says the API key was rejected. I haven't touched anything. I think the key expired — want me to rotate it, or will you?"
Second one takes ninety seconds to write and saves twenty minutes. It's the same three-line format from 0.2 — what happened, what you checked, what you think — with one addition: say what you haven't done. "I haven't touched anything" is enormously valuable to whoever picks it up, because it means the system is in a known state.
There's a third option people forget: contain it. Sometimes you can't fix it and can't wait — but you can stop it getting worse. Turn off the broken automation. Pause the job. That's not a fix and shouldn't be described as one, but it buys time and it's often the right first move. Just be explicit: "I've paused the sync so it stops queuing bad rows. Not fixed, just contained."
One rule that overrides all of it: anything involving money, customer data, or something you can't undo goes to a human. No matter how well you understand it. Understanding isn't the same as being the right person to carry the risk.
Do
- Write the two questions somewhere you'll see them.
- Take three real incidents — from your own week, from the system, or things that have gone wrong before.
- Run each through the grid. Write down which quadrant it lands in and what you'd do.
- For the one you'd escalate, write the actual message. Full thing, as if you were sending it.
- Check it says: what happened · when it started · what you checked · what you think · what you haven't done.
- Write your own
triage.md— the two questions, the grid, and your list of things that always go to a human regardless. - Show it to Callum. If your always-escalate list is missing something, better to find out now.
Step 6's last part is the one to think hardest about. What's on your never-decide-alone list is a judgement about the business, not about your ability, and it should be agreed rather than assumed.
Done when
Never do
Never try fixes on something you don't understand and then escalate. You'll hand over a system in a stranger state than you found it, and the person picking it up now has two problems.
Never decide alone on money, customer data, or anything irreversible. Understanding the problem is not the same as being the person who should carry the risk of the fix.
Never say "fixed" when you mean "contained." They're different, and someone downstream will act on the difference.