Listening is one of the more critical diagnostic skills you can practice.

At one company I worked with, the support team kept getting tickets for their fax modem banks… busy signals, dropped connections, intermittent failures across the document ingestion system. The issue could last for hours if not longer at times.

And every time it happened, the team would review the hardware. They would check the intake software that controlled the modems, restarting the software controllers. They would pull logs and look for errors. Even testing equipment by running extensive self-checks. They usually found nothing wrong.

Then the problem would go away on its own, and apparently this had been going on for months.

One day it happened while I was in the room. I listened to the troubleshooting for a few minutes and asked one question:

“Has anyone called the number to hear what it’s doing?”

Blank looks.

I picked up a phone and dialed the line. Fast busy tone. Beep beep beep.

“The problem isn’t here. It’s at the exchange. Call the telco.”

An hour later the carrier opened a service investigation and found intermittent hardware failures on their end.

Months of tickets. Hours of internal troubleshooting per incident, and the final fix was simply getting it to the right people. Granted one of the guys asked me later how I knew what that kind of beep meant. I referenced past work at an ISP (oh, the skills you pick up over a career).

The instinct when something breaks is to look inward. Check your code, check your hardware, check your config. But sometimes the problem isn’t in your domain at all. And no amount of expertise applied to the wrong layer will get you there.

The diagnostic that matters most is often the simplest one nobody thought to run.