Summer vacation is over. Time to get back to work with a multi-part series on Troubleshooting. We start by dispelling myths.

I hear the ads on the radio.  “Start your exciting career in Information Technology.”  Or, “learn how to fix airplanes.”  Sure, it’s not digging coal or laboring out in the elements.  But, it’s not a profession you can learn everything with a Doctorate degree.  Fixing things requires a combination of people skills, critical thinking and perseverance. Do you have what it takes?

We will focus on IT, but we could substitute computers, airplanes, dishwashers or people. Ask anyone not involved in IT what IT does and they will say, “they fix the technology when it breaks.”  This is a fundamental understanding of Incident, or Problem, Management.  I prefer a simpler, more direct term: Troubleshooting.

All systems, from toasters to airliners, are prone to problems.  Most systems are built to function in a certain way under specific circumstances.  Any number of situations may arise where the system does not function as it should.  In those instances, troubleshooting skills are a must.

But how does one learn the proper way to troubleshoot?  Many formulas, flow charts and methodologies exist to guide non-technical people through the process.  To the experienced person, some of these are laughable while others simply are not conducive to real-world scenarios. 

Troubleshooting Tools

To know how to troubleshoot, one must understand the purpose and intention of troubleshooting.  Somewhat like The Art of War (Sun Tzu), you need to know yourself and your enemy.  Knowing both will help you size up the situation and know when to ask for help.  The first tool of troubleshooting is knowledge.

Knowledge is required to understand what individual components make up a system and how they should work.  If you know the door handle needs to turn to release the latch before you can open it, you shouldn’t yell at the door for being broken when it doesn’t open for you automatically.

Critical thinking is the next necessary tool and the most important.  If you stand at the door with the knowledge that the knob must turn to disengage the latch, you then must decide what your next logical steps to troubleshoot, test or resolve why the door isn’t opening for you. Much more will be discussed in later posts, including issue identification.

The final step is taking action.  Many people who attempt to troubleshoot don’t test their theories or do so accurately.  If you have knowledge and critical thinking but do not test to confirm, you’ll still be outside the closed door.  This requires an ounce of confidence that comes from practice and experience in the field. 

Myths and Realities

Some will have you believe troubleshooting, especially in IT, requires some God-given gift or hidden talent.  There are many myths perpetrated about troubleshooting. I bet you’ve heard some of these.

MYTH #1 – It takes a certain aptitude to fix things.

Is it for everyone?  No. Could I run a cupcake shop or operate on someone? With the proper training and mindset, yes. It may not be your passion, but if it is something you are good at and it holds your interest, that is what a job should be.  A passion is something you do for fun.  IT can be fun, but it is always work and should be viewed as such or you lose focus.

REALITY #1 – It takes a certain mindset to fix things.

I like to use the terms “nerd” and “geek” because I can relate.  They are not derogatory terms and anyone who believes they are, well, you are neither a nerd nor a geek.  I wear these as badges of honor handed out by those who secretly admire our abilities to understand complex systems and roll 20-sided dice.

Do you need to be a nerd or geek to troubleshoot?  No.  In fact, I have met plenty of extremely smart people who will step into a system failure or join a troubleshooting call and immediately start assuming what is wrong.  I’ve also been humbled by non-IT personnel who will suggest something so basic every “big brain” has to stop and admit they hadn’t thought of that.

I prefer to think of the role of the troubleshooter much like a homicide detective, chasing a serial killer (outage/problem) by reading and researching the clues (events/symptoms).  Yes, it is cheesy.  Let’s not forget we are the same sort of people who dress up as the characters to go the movies.  We might even break out the fishnets for Rocky Horror Picture Show.  The point is a troubleshooter needs to take the role seriously and approach it with the same focus and determination as any other issue.

MYTH #2 – Fixing things is a gift that can’t be taught.

Really?  Is that in the same sense neurosurgery is a hobby?  To be great at anything requires effort.  Troubleshooters aren’t born or assembled in the computer lab.  They are required to learn the systems they support, or they won’t be any good at what they do.

REALITY #2 – Fixing things requires tons of learning.

Remember the first time you played a video game or sport or raised a kid and thought, “this is the hardest thing I’ve ever done!”  After you’ve practiced at it, it gets easier, except raising kids.  In fact, after a few days or weeks, you begin to learn the patterns and intricacies and feel like you’re getting the hang of it.  Meanwhile, neither you, your spouse or the newborn has really slept for days and you’re arguing with a soccer ball over how you parked in the garage.  Aside from raising kids, all things become easier once you understand them better.  I’ll never understand kids, no matter how many Dr. Spock books I read.

MYTH #3 – You learn troubleshooting on the job.

This is a partial myth, only because what you learn on the job are the common faults and solutions of individuals, machines and offices.  If there is a printer on the third floor that always jams because it’s being overused for month-end reports, that’s not troubleshooting.  That’s memory recall. 

A modern proverb tells of a mechanic at a ship manufacturer who retired (or was let go just before retirement).  One day a production system stops working and an entire crew of young guys work for hours unsuccessfully to resolve the issue.  After losing hundreds of thousands in production, the manager calls the old mechanic.  He must be old to further propagate the fact that he has wisdom and knowledge stored from all those years on the job.  He comes out to the factory with just a hammer, walks over to the machine and delivers a single blow to the center of a random panel.  The machine comes to life and works better than ever.

The manager is ecstatic, until the old mechanic hands him a bill for $10,000.  The manager gawks for the simple fix and demands an itemized bill.  The old mechanic pens the following:  “Use of hammer: $25.  Knowing where to hit: $9,975.”

This is an excellent example of memory recall for incident resolution.  These incidents and errors can be cataloged and documented so that anyone with a reasonable degree of motivation can resolve this issue, if and when it arises again.  This is not troubleshooting.  Troubleshooting occurred the first time the problem happened, and a work-around, not a resolution, was found.

Now, as Director of support technicians and engineers, I would initially be pleased that the problem had been resolved so that the system would continue to function.  But, the next order of business would be to determine Root Cause and resolve issues permanently.  A bandage in the form of a work-around is not a feasible replacement to surgery.  We will discuss Root Cause in a later post.

REALITY #3 – Troubleshooting is a combination of knowing how the system works and how it doesn’t work.

I know what you’re thinking.  It’s 5 o’clock somewhere and he already hitting the sauce.  In the next post, I will clarify with an example I call “Morning Toast”.