Sometimes, proving that you can solve tech problems just leads to more being brought to your attention.

So, what would you do if you were sent to a remote work location to install a software patch, but after finishing, the team on-site asked you to look at one of their other machines?

Would you let them know that’s out of your league and wait for your flight? Or would you take a look and see if you can fix it?

In the following story, one applications engineer finds himself in this situation and decides to give it a try.

Here’s what happened.

Thanks for the software patch, but can we get you to look at this totally unrelated hardware issue?

I worked at an EDA (Electronic Design Automation) company where I specialized in application tools for place-and-route of printed circuit boards.

As a headquarters applications engineer, my day-to-day job was handling tech support cases for both customers and field applications engineers.

I rarely made customer visits, but if a case became critical, I was sometimes sent out as a smokejumper to fight a fire. This only happened a handful of times per year, and they were usually stressful.

The patch was easy to install.

One such case, I flew in, installed a software patch, then answered all their questions about the specific issue I’d been sent to resolve.

It all went very smoothly, which was a relief. The customer group was a friendly bunch, and they took me out to lunch, and then I had plenty of time to catch my flight home.

While we’re at lunch, one of them says, “Hey, while you’re out here, maybe you could take a look at our Route Engine. It was delivered a couple of months ago, but none of the FAEs have been able to get it to boot.”

He agreed to take a look.

I tell them I’m not a hardware expert, but I’m willing to take a look, as I do know my way around the machine fairly well.

We get back from lunch, and we try to boot the machine. It won’t even initiate the boot process, even with all the boards removed but the CPU board.

After some other debug steps, I suspect that the ribbon cables on the backplane are the issue. I had never dealt with backplane issues, but I had brought a notebook that included the specs for the ribbon cable placement.

All in all, it was a good day.

Sure enough, one of them was misplaced by one pin, so the board-to-board connectivity of the machine was all wrong. I fixed the connector placement, and the machine boots just fine.

So, apparently, this machine was shipped to the customer with zero factory testing, and none of the FAEs had been able to fix it. But I walk in with no particular expertise and fix it in like half an hour.

That was a good day, and I caught my plane home.

Bravo! Now, that’s how to be a team player.

Let’s see how the folks over at Reddit would’ve handled this situation.

This is actually a thing.

Here’s a good point.

… that’s quite a compliment.

It must be an intuitive thing.

They got lucky with him because obviously, not everyone knew how to fix it.

If you liked that post, check out this post about a woman who tracked down a contractor who tried to vanish without a trace.