The five-minute triage that saves an afternoon
A small habit I picked up on the ramp at Luton that translates almost perfectly to IT support — and to my homelab.
Tuesday morning at Luton, around 7am. We had a 737 due out in eighteen minutes and the tug we needed to push it back had gone dead five metres from the nose. The captain wanted answers, the gate next door needed our stand, and the agent next to me had never seen a tug fail before.
You don't get an hour to read the manual on the ramp. You triage.
Three questions, before anyone touched anything:
- Is the tug actually dead, or has someone left a switch flipped? (Spoiler: someone had.)
- What changed in the last shift? Ours had been swapped in from another stand half an hour earlier.
- What's the smallest test I can do? Try ignition. If it cranks and won't catch, that's one diagnosis. If it doesn't crank at all, that's another problem entirely.
Two minutes later we were pushing back. The aircraft made its slot.
I now do the same thing at a desk.
The three questions, rewritten for IT
When a ticket lands, before I touch a single setting, I write down:
- What is the user actually trying to do? Not what they reported — what they want to be true at the end. "Outlook is broken" almost always means "I can't send the email I need to send right now."
- What changed in the last 24 hours? Updates, password resets, network moves, new hardware, a colleague who "just clicked something."
- What does the smallest reproducible test look like? If I can shrink the problem to a single repeatable step, I can solve it. If I can't repeat it, I'm chasing a ghost.
It sounds obvious. It rarely is. During my internship at Sir Robert McAlpine I shadowed a few infrastructure tickets where the answer turned out to be "the user moved desks and is now sitting two metres further from an AP than yesterday." Hours of guessing could have been one floor-plan check.
Why this works on the ramp, the helpdesk, and at home
Triage is deliberate slowness at the start, so you can be fast for the rest of it. That trade is almost always worth making.
I run my homelab the same way. Pi-hole stops resolving DNS at 11pm? I don't reboot the Pi yet. Did I push a config change earlier? Did the upstream resolver go down? Did the SD card actually mount? Five minutes of asking, then five seconds of fixing — versus an hour of restarting things at random and breaking the bits that were already working.
The bonus, in any service-desk context: you've already written half your ticket update before you've started working. Future-you, and whoever picks the ticket up next, will thank you.
The fastest engineer I worked with at Luton had a phrase for this: "Slow is smooth, smooth is fast." Probably stolen from somewhere military. Still true.