Volume
1, Issue 9, September 1997
Copyright (C) 1997 by Steve Litt
Volume
1, Issue 9, September 1997
How many Troubleshooters does it take to screw in a lightbulb? Usually Two. One to describe a no-light condition, when it started, what else happened at the time. And the other to narrow the problem down to the burned out lightbulb and replace it.
Sometimes three. One customer to describe the condition, one electrician to troubleshoot in the house, and one power company employee to check the lines to the house. As long as they work together to solve the problem, everything will be fine.
But what if the electrician and the power company employee point at each other and say "it's his problem"? And what if the customer says "I don't have time to describe the symptom, that's your job"? Troubleshooting is a team sport, and like any team sport, star players aren't enough. They must play well together to win.
This issue of Troubleshooting Professional Magazine is devoted to teamwork in Troubleshooting. So kick back, relax, and read this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!.
The deadline loomed, and my Borland Turbo C program acted flakier than ever. Extensive troubleshooting revealed that the problem could be toggled on and off by loading and unloading the Microsoft mouse driver. The mouse driver appeared to work with everything but Borland Turbo C, and Borland Turbo C had no problems with anything but the mouse driver. Your basic incompatibility. I emailed both Microsoft and Borland. Borland wrote me back with a place I could download an corrected mouse driver. Problem solved.
Microsoft wrote back saying it was "Borland's problem", and Borland must solve the problem. After all, their mouse driver worked with everything else. They conveniently forgot to notice that the converse was also true -- Turbo C worked with everything else on my computer. It's called "hot-potato-troubleshooting", and it wastes billions.
"Hot potato" is a kids game. They throw a ball to each other, pretending it's a potato freshly removed from the barbeque. The object is to get rid of it quick as you can. Kind of like a help-line employee with a ten call per hour quota. "Oh, it doesn't work with Turbo C? It's Borland's problem". "Oh, it happened when you installed a new printer? It's a hardware problem". "Oh, you have an aftermarket alternator? That's the problem". Just get rid of the problem fast!
Hardware/software hot-potato is a cliche. The hardware guy runs a few on-site tests and declares it a software problem. The programmer goes through his code, runs a few tests, and declares it hardware. The customer screams. The hardware guy comes out and draws the same conclusion, followed by the programmer, then the hardware guy, then the programmer. One month and thousands of dollars later, upper managment comes in, threats are made, and finally it's solved.
Wouldn't have been easier for the hardware guy, the programmer, and the customer to make solving the problem a priority, rather than trying to dodge the potato? Working together, with the same set of tests and experiments, they could have solved it the first time. No second third and fourth visits, no threats, no letters of explanation. Just a quick, reliable solution.
As troubleshooters, sooner or later we each work with an expert who is a hot-potato-player. Then the only way to solve the problem is to take responsibility for the solution. Trouble is, when we take responsibility for the solution, it can look like we're taking responsibility for the problem. Nobody wants to look "at fault". Sometimes it's tempting to play hot-potato right back, but of course that's counter-productive. The customer will simply dump both experts. So what's the best way to handle it?
Bring the customer in as a full partner in the Troubleshooting process. Explain every step -- why it's done, what it proves. Ask the customer for input. Make sure he knows and understands exactly how the scope of the problem is being narrowed. If you can't rule out a part of the system because the other expert needs to conduct the test, make sure the customer sees that first hand. The customer will drag the other expert back, kicking and screaming, all the while understanding that the other expert is responsible for the test, no matter whose "area" the root cause is in. Finally, the problem will be solved. If it's in your "area", the customer will fully understand the thorough and high quality job you did, and will show his gratitude to you and your company. And if the root cause turns out to be in the other expert's area, boy won't he look silly. And with an informed customer as a witness. What are the chances that he'll play hot potato with you again?
But sometimes the customer himself plays hot-potato. Read on...
If you want to show disrespect for a troubleshooter, just give him a symptom description like this.
John, what operating system? What kind of hardware? What screen saver? What other installed software? Does it happen with all screen savers, or just this one? What clock freezes? Some clock app? The computers internal clock? Exactly where are these "multiple cd rom icons", and what makes you think they have anything to do with the clock freeze? Does it happen all the time, and what must you do to reproduce it? When did you first notice it? What other things changed around that time?
Sadly, this is based on a symptom description actually sent to me at Troubleshooters.Com. Sadder still, it happens quite a bit. John couldn't take the time to issue a real description -- he just hot-potatoed it to me. Users and customers play hot-potato too, and their favorite ploy is the inadequate symptom description. "I don't have time to type out a description. Let the techie figure it out on his own time".
What's the correct response to a symptom description like this? It depends on the situation. If the Troubleshooter's job is to help technically challeged people, the Troubleshooter smiles, knowing he's doing his job, and questions the user into making a complete and accurate symptom description. If it's a fellow technical person who should know better, the Troubleshooter asks him for the necessary information and lets him know next time he expects this info given the first time. If it happens again, I would seriously consider letting his boss know there's a problem, and offer to give a 1 day course on symptom descriptions to correct the problem. However, please note that different companies have different politics, and my suggestion could backfire. You are responsible for handling the situation, and the consequences.
And then there are those (thankfully a minority) who hot-potato free services like Troubleshooters.Com. You'd think they'd express gratitude for the free service by taking the time to issue a good symptom description, but noooooooooooo... Troubleshooters.Com has decided that our goal if to help those with truly difficult problems, so we've created a form letter reply for inadequate symptom descriptions.
My response: Every problem is soluble, but some aren't worth solving. I'd suggest you upgrade your equipment.
My thoughts: If the customer isn't committed enough to purchase modern equipment, why should I spend my time (and time is money) to help him make his obsolete equipment perform to modern standards? Even if he pays me, would he be satisfied with the result?
My response: Looking at it is free. I've just looked at it, and you're right, it's not functioning correctly. Our prices for diagnosis, parts replacement, and refused estimate charge are listed on this sign. We've found that diagnosis is 90% of the job and that replacement of parts is the easier part of a repair. We're the best diagnosticians in town, and if you'd like to have a professional diagnosis, we'd be glad to do it for our standard fee.
My thoughts: It never ceases to amaze me how people earning $70,000 can, with a straight face, suggest that a commission-payed technician or a small shop owner work for free.
My response: If I can get away with it, ignore it. Otherwise, call back, and either interview them, or if I need to leave a message, request that the symptom description be emailed to me. If I interview them I request that next time the description be emailed.
My thoughts: Is the customer incredibly stupid, or incredibly inconsiderate? Do they have any idea how difficult it is to repeatedly rewind the message to glean info (if rewinding is even possible)? Do they stop to think that they're really asking me to transcribe the message? Do they think I'm a stenographer?
My response: Depending on the politics of the situation, I'll either send a form letter about "inadequate symptom description", or query them for an adequate one and request next time they submit a description as outlined in http://www.troubleshooters.com/ustep2.htm.
My thoughts: If I'm being paid to handhold newbees, I'm happy that I'm doing a good job. If the submitter is someone who should know better, or if I'm helping for free (as on Troubleshooters.Com), how dare they ask for my valuable time when they're too lazy to write down the exact text of the error message, the reproduction sequence, etc.
My response: Please click help, then about, and read me the version number.
My thoughts: Unless this person is on my development staff, how could they possibly know what's the latest version? And latest what? Release? Beta? Alpha? Vapor?
It's irrefutable evidence that Troubleshooting Process Training is a vital to every company and in public school. Every Troubleshooter experiences the above symptom description inadequacies on a regular basis, both from the population at large and from technical personnel who should know better. Each inadequate description, with its phone tag and/or email tag, adds minutes, hours or days to the resolution of each problem. Figure the average time increase, multiply it by the number of problems, factor in the salaries of everyone held up by the delay, and you can put a dollar amount on it.
A major component of teamwork is a simple "thank you", and I'm happy to say THERE'S ABSOLUTELY NO PROBLEM HERE! On the contrary, my experience as a consultant and as webmaster of Troubleshooters.Com shows that almost everyone gives a genuine "thank you" for my help, even if it doesn't resolve the problem. Here are some "thank you's" I've received in Troubleshooters.Com email:
Team Troubleshooting is definitely alive and well when it comes to "thank you"s.
The idea behind Troubleshooting Professional Magazine was to provide a forum for discussion of the best ways to bring Troubleshooting Process to the masses, and preventing commercialism from eclipsing the truth. I anticipated others writing the articles. With only a few exceptions, that hasn't happened. Frankly, I'm running out of ideas.
Also, Troubleshooting Professional Magazine is not nearly as well visited as Troubleshooters.Com's Windows 95 pages, automotive page, or Universal Troubleshooting Process page.
So here's the question. Do you find Troubleshooting Professional Magazine valuable on an ongoing basis, or would you be satisfied with my keeping the 9 issues already made on the site, but making no further issues. Please email me at Steve Litt's email address to vote. Thanks.
We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.
All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com.
Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):
After that paragraph, write the title, text of the article, and a two sentence description of the author.