The network's down, and hour after hour your support people trip over
themselves trying to fix it. Does troubleshooting sometimes seem like
a 1920's cops and robbers comedy? Or a cat and
mouse cartoon? It would be funny if it didn't cost so much in terms of
money, morale and opportunity.
The causes of banana peal troubleshooting are legion. Inadequate
technical training, inadequate diagnostic tools, too few technologists
on staff, and too many interruptions are just a few. But by far the
most common is inadequate understanding of the process of
Your technologists probably have years of training in electronics or
data processing or machine repair, as appropriate. But how much
training do they have on the process of troubleshooting
Typically not even an hour. Sure, after a few years most technologists
learn at least part of this process from the school of hard knocks, but
many don't. Sometimes even senior technologists never learn the process
of troubleshooting. Contemplate that the next time troubleshooting
bungles would be funny if they weren't so costly.
If you'd like to hear more about the process of troubleshooting
, read on...
Who's This Steve Litt Guy?
Once upon a time I was paid commission to fix consumer stereo gear. The
more I fixed, the bigger my paycheck. There was every motiviation to
fix more gear. But it wasn't easy. My intelligence is average, my
memory less than average, and my hands way too big for delicate work.
With no natural talents for fixing stereo gear, my challenge was to
find a way to produce beyond my abilities. That's how the Universal
Troubleshooting Process was born.
It took me almost 9 months to figure out the process
of troubleshooting, but once I had it, my productivity (and therefore my paycheck) doubled.
Years later I got a job as an entry level software developer. My
development productivity was about what you'd expect from a beginner,
but I quickly became the company's best troubleshooter. The exact same
mental process used for stereo repair enabled me to fix any computer problem --
either hardware or software. It became obvious that this mental process could be used to
machine, electronics, computer system or software.
With that understanding, I wrote "Troubleshooting: Tools, Tips and
Techniques" in 1990 and started teaching classes. I created the
Troubleshooters.Com website in 1996 and taught more classes.
I wrote "Troubleshooting Techniques of the Successful Technologist" in
2001, "Manager's Guide to Technical Troubleshooting" in 2005, "Twenty
Eight Tales of Troubleshooting" in 2006, and "Troubleshooting: Just the
Facts in 2007.
Isn't System Expertise Enough?
Most people believe system and technical expertise is enough. They
think if tech support people understand computer programming and
understand how your computer program works, they can quickly and
accurately help users having problems with your computer program.
This belief is widespread:
Technologists, managers, Human Resources, upper management,
clerks and secretarys
believe it. That's why, when your company's troubleshooting starts
resembling slapstick comedy, your technical people are sent to yet
another class to teach them yet more minutae about the system they're
troubleshooting. And you know the result -- nothing!
Most technologists' bottleneck isn't lack of technical knowledge; it's lack of knowledge of the troubleshooting process
Therefore, giving them more technical knowledge doesn't help. What
helps is teaching them troubleshooting process. Typical technologists
haven't had even an hour of training on the process of troubleshooting,
although this is starting to change, in no small amount due to my
courseware and books.
For most of society this is hard to believe. Most of us still believe
in proportionality of technical knowledge to troubleshooting
productivity. An analogy helps dispel this ...
Imagine hiring an expert psychologist. Now train him on all your
company's products. All the features and benefits. Train him on the
wants, whims and desires of your customers. Train him on the features
and benefits of products from your competitors, and the companies of
those competitors. Now send him out to sell. Guess what happens.
Of course he can't sell. He may know everything there is to know of
human motivation, your company's products, your customers and your
competitors. Those are all things that must be known to sell. But he's
missing one thing: Training on the process
of selling. When do you demo your product, and when do you not? At what
point do you perform your first trial close? How do you close the
customer in the least threatening way? How do you evaluate the
customer's intelligence so you don't insult it? When is it best to
admit defeat, at least for today, and go sell someone else? By what
system do you keep your leads and prospects. How do you decide whom to
call each day? How do you set up appointments for the most face time
with the least travel time? How often do you re-contact existing
A person can be an expert on human psychology, your products, your customers, your competitors. But without knowledge of the sales process
, performance will be grim.
Isn't it the same for your Human Resources position?
You can know every employment
law, every health insurance plan, every training and motivation theory,
and every person in your company. But exactly how do you tell John
Jones that his work has been substandard, and he needs to improve, and
make him sign a paper acknowledging the discussion? How do you open
that discussion without really freaking the guy out? How do you
approach one of your go-getters with a possible promotion? Do you
discuss the position first, or their current work first? How do you get
employees to tell you what's really happening, rather than telling you
what they think you want to hear? You need processes
to do these things.
At this point you might say "they'll learn it just by doing their
job.", and you'd be right in most cases. Most people learn relevent
processes on the job, eventually. But wouldn't it be nice to have a
brand new person, fresh out of college, troubleshoot like someone with
ten years on the job?
And don't forget, I said most
people learn relevent processes on the job eventually. Some never do.
How many auto shops have bungled repair of your car? These shops are
owned by pros with years in the business. They never learned. The
customer ennunciates a symptom, the "mechanic" guesses a cause,
replaces a part based on that guessed cause, and doesn't bother to test.
The car still has the same problem you brought it in for.
Troubleshooting productivity is NOT proportional to technical
knowledge. Troubleshooting process is also required. Think of
troubleshooting process training as the key to unlock the power of the
employee's technical knowledge.
What's the Universal Troubleshooting Process?
It's the following ten step process:
- Make a damage control plan
- Get the symptom description
- Reproduce the symptom
- Perform corrective maintenance
- Narrow it down to the root cause
- Repair or replace the defective component
- Take pride
- Prevent future occurrence
That's easy to understand, isn't it. That's why the Universal
Troubleshooting Process course is only two days. When performing step 6 (narrow it
down), the technologist tries hard to conform to the ideal of binary
search, which looks like this:
||As you can see from the graphic on the left, binary search
involves performing a diagnostic test to rule out half the system, then
another diagnostic test to rule out half the remaining system, then another to rule out
half of that remainder, so on and so forth until the root cause is
quickly located. Theoretically, in 16 diagnostic tests, binary search
can find one bad component in 65536, 20 diagnostic tests can find one
bad component in a million.
Binary search doesn't work that perfectly. If it did, Troubleshooters
would get minimum wage. Nonetheless, binary search is an ideal that the
Troubleshooter should always strive for, and if she comes at all close,
it will speed troubleshooting by a large factor. My books and training
materials describe what it takes to get close to this ideal.
Technical troubleshooting training is what I do for a living. I've
created voluminous information on the subject. Here are pointers to
some of that information:
information in this document is information is presented "as is",
without warranty of any kind, either expressed or implied, including,
not limited to, the implied warranties of merchantability and fitness
a particular purpose. The entire risk as to the quality and performance
of the information is with you. Should this information prove
you assume the cost of all necessary servicing, repair, legal costs,
negotiations with insurance companies or others, correction or
In no event unless required
by applicable law or agreed to in writing
will the copyright holder, authors, or any other party who may modify
redistribute the information, be liable to you for damages, including
general, special, incidental or consequential damages or personal
arising out of the use or inability to use the information, even if
holder or other party has been advised of the possibility of such
If this is not acceptable to
you, you may not read this information.
Top of Page
[ Troubleshooters.Com | Email
Steve Litt ]
(C)2007 by Steve Litt. -- Legal