The Self-Imposed Blind Spot

17 Dec, 2018

One of the great lessons I learned while serving in the U.S. Air Force was about the self-imposed blind spot and how it can derail the troubleshooting process.

One of the tasks our team had to do was set up an airborne radio relay network, so that we could facilitate long-distance communication without relying on any ground-based communication systems. Several aircraft would be dispatched in a chain between the two locations that needed to communicate.

Each plane, equipped with radios, would receive and then retransmit the signal to the next plane and form a relay. The communications signal would continue from plane to plane between the two locations.

This chain of aircraft connected by radios was a highly complex network, and there were thousands of little things that could go wrong. One plane could be sending the signal with too little power (or too much), and it would throw off the entire system.

Whenever we were setting up these long-range networks, there was nearly always a break in the chain—somewhere the signal was lost—and the team had to troubleshoot.

Most often, the issue would look like one specific airplane in the chain, and we’d hear over the radio, “Plane 8, it looks like you’re not retransmitting to plane 9. Can you confirm?”

The operator in plane 8 would answer, “I’m not receiving anything from plane 7,” and almost immediately, plane 7’s operator would say something to the effect of, “I’m definitely retransmitting the signal. It’s not me.”

Plane 8’s and 9’s operators would then both recheck their systems and settings, and the rest of the network would sit idle while they troubleshot.

The operators on plane 8 and 9 would work diligently, but no matter what they’d try, they couldn’t seem to get things to work. The operator in plane 7, the one who said confidently, “It’s not me,” would also be sitting idle, waiting for aircraft 8 or 9 to get their systems configured appropriately.

As you’ve probably surmised, it nearly always turned out to be the operator who had supreme confidence that it “wasn’t me” who was not retransmitting properly due to an incorrect setting.

I’ve seen this scene repeat itself over and over in a multitude of contexts. Once it is decided that “it’s not over there,” inevitably it turns out to be “over there.”

I believe these are self-imposed blind spots—places we are confident are “good” but really could use a second or even third look at all the details.

The next time you’re in a troubleshooting scenario, especially if it has a significant impact and you’re working with a team of others, don’t discount any area that could be causing the issue as “that can’t be it” or “it’s not my stuff.” A great strategy for this is to say, “I don’t think it is me, but I will take a look over all the settings again and make sure they are all set correctly,” and actually do that. This action will save you and your team a lot of grief and frustration while looking for the culprit in your complex troubleshooting scenario.