Volume
1, Issue 1, January 1997
Copyright (C) 1997 by Steve Litt
Volume
1, Issue 1, January 1997
Welcome to the premier issue of Troubleshooting Professional Magazine. Troubleshooting Professional isn't for everyone. It doesn't look like an online mag. No time for aesthetics. (Please cut us some slack on this -- it is a premier issue). Also, it won't help one bit if you're looking for a solution to a specific problem (see Troubleshooters.Com for that). And it's kind of political. Even the article titles have a political sound to them. What's up with that?
Does this sound familiar? You've been in the trenches a few years. You have a process by which you troubleshoot. Trouble is, management, customers, and many co-workers don't want to hear it. Just fix it now -- we don't have time for no damn process. Firefighting feeds the flames.
And when the fire gets out of hand, management's right there with a fix. Send you back to school to learn even more arcane details about the machine. Or hire a bunch of phone clerks and throw them on the help lines. Or get yet another piece of software promising to turn any old dummy into a troubleshooter. Or fire the whole staff and outsource customer service. THERE'S GOT TO BE A BETTER WAY!
Given today's attitudes toward troubleshooting and troubleshooters, that Better Way is nothing short of revolution. A violent clash of ideologies (or lack thereof?), with victors and vanquished, patriots and turncoats, soldiers and politicians.
So those of you interested in a better way -- write letters to the editor, or write articles for publication in Troubleshooting Professional. Do it! You'll be writing history.
It's coming. Can you feel it? Can you sense the change? These are the final years of old-style Troubleshooting, and things will never be the same.
-----------
The most rewarding part of being Webmaster of Troubleshooters.Com is finding out I'm not alone. There are other voices out there. Voices like mine, who know Troubleshooting as a Process, not as a property of the machine, nor as something you "just do". They're devoted to the vision -- a vision they've kept through years of rejection. Their time is coming -- they can feel it.
I hear them in my email. Some just say "you're right Steve, good luck". Some go on for pages, talking of six step processes and eight step processes so similar to mine it's spooky. They curse that most obnoxious phrase, "troubleshooting what?". And the blank stare you get when you answer "anything" (and if you've read this far you know that blank stare). And of the compromises they've had to make to pay the rent and feed their families.
And they're all saying the same thing. People finally are starting to listen. People who count, with the money and power to force the change. People fed up with bad press about hour-long waits for inept tech support. Fed up with lemon law losses. Fed up with doctors who can't diagnose. Fed up with day-long network outages. Can you see it just beyond the next hill? It's coming. And you're leading the charge.
How do we, the early advocates of Troubleshooting as a Process, guide it correctly into the world's common consciousness? It's a problem. But of course, problem solving is our business. Here's the approach I'm using:
I remind myself that Troubleshooting as a Process will prevail because I've seen how well it works when consistently and correctly applied. I remind myself I'm not in it alone, and talk with others knowledgeable in Troubleshooting Process, and trade success stories. When the going gets tough, I remind myself I must be ready, willing and able to make the sacrifices necessary to become a teacher and coach, not just for the few megacorporations with big training budgets, but with everyone. The money will come soon enough.
I must consistently brush up and refine my knowledge and understanding of the Troubleshooting Process. I (and those I'm in contact with) continue to develop an accurate (or as accurate as possible) Mental Model of the populace and the business community as they relate to Troubleshooting. What makes them tick? How do they interact? What incentives move them?
The symptom's pretty easy to describe. People don't "get it" when you tell them. When you talk Troubleshooting, they say "troubleshooting what?". When you say "anything", they give you the dreaded blank stare. Meanwhile, help-lines and service departments are more backed-up and less effective than ever.
Make sure you don't make it worse. I have a policy that I won't become part of a training situation or program I can't handle or might lose control of. When dealing with large companies, have a plan to keep control in the face of politics. And above all, I vow to teach unadulterated Troubleshooting Process.
That's easy. Go to a few service departments and call a few help-lines. The industry doesn't matter -- cars, consumer electronics, computer hardware, computer software. The result is the same -- untimely and inaccurate diagnosis. Talk face to face with managers of those inadequate facilities, and watch most of their eyes glaze over when you tell them of Troubleshooting as a Process. Listen politely as they tell you of the new diagnostic tools they've ordered to fix the problem, or how they'll be sending all their techs to learn *even more* about the machine to be fixed, or how you "just can't find good help", or how "you can't learn troubleshooting, you have to be born with it", or the granddaddy of them all, "my people can troubleshoot, they do it every day".
Yes, it's pretty easy to reproduce the symptom.
I look and act professional. I talk Troubleshooting every chance I get, and become more fluent with time. I continue to maintain my Troubleshooting acquaintances and gain new ones, because this is a job I can't do alone.
This step has been troublesome, partly because of an inadequate Mental Model. How to motivate individuals and groups? Smarter people than me have been debating this for centuries. I have narrowed it to a small degree
It seems my best successes come with customers for whom I do programming. After months or years of seeing me troubleshoot software problems they can't fathom, they begin to believe "Litt must know something I don't", and take my Troubleshooting Course. It's obvious that an element of disbelief has been overcome.
That leads me to a hypothesis I must test in the next few months (and hopefully I'll gain info from the tests of others). The hypothesis: that common-sense is the cause of the disbelief.
Looking deeper, it's apparent that "common sense" is to blame in at least three ways:
Ever notice that the majority seems to determine what's common sense? For a while it was "just common sense" that you pay employees peanuts and work them to death for maximum profit. Then it became "just common sense" that you'd get more from employees who were paid well to do a good job. Now it's "just common sense" lay off a large percentage of your staff to slash your payroll, and let the survivors pick up the slack. Note that if this is the root cause, the solution will come as an "avalanche" as folks storm the bandwagon.
It was once "common sense" that the Earth was flat. After all, you don't feel like you're walking on a basketball. No, it feels more like you're on a dinner plate, or maybe a dinner plate with pools of water and mounds of food. Imagine trying to tell a disbelieving world you're really walking on a sphere, when common sense says it's a flat plate. You can tell them, you can show them evidence, but they'll believe it's flat as long as the majority thinks its flat.
In the same way, today's "common sense" says that since you must know something about the machine to be fixed, troubleshooting depends [solely] on your knowledge of the machine and your "skill". You can show them the steps to troubleshooting process, even show how quickly it can unravel the nastiest problem, but "common sense" tells them the solution lies in ever more arcane knowledge of the machine. If this is the root cause, I think the solution lies in *unconditionally disproving, with complete documentation in the press*, the "common-sense" theory of machine dependence.
It's also common sense that it's quicker to "just find the problem" than to go through a ten step process. Once again, the solution is a "shootout".
A more insidious problem occurs when people see Troubleshooting Process as common sense, but don't practice it. They won't buy common sense. "I know that", or "I already do that" is a common response. Yet one look at the nations help lines and repair facilities tell another story.
The hucksters and snake-oil salesmen have a ready-made patch. Easy. To that nice, simple, profound and elegant Troubleshooting Process checklist, they add gobs of fluffy buzzwords, wizardly incantations, and a (un)healthy dose of machine-specific information. Now that it's not common sense (nor Process) anymore, they can sell it like the autumn leaves.
To test this hypothesis, do as the hucksters and contaminate the course, BUT IN A WAY THAT LEAVES THE TROUBLESHOOTING PROCESS STRUCTURALLY SOUND. Teach it and see if the "fluff" increases sales and acceptance. If it does, then you know this was the root cause. Then, the last half hour of the course, emphasize the process as the main idea (so you're still ethical).
I can't say much about this until I know the root cause(s).
Here's how I propose to test the solution:
When the above tests indicate success, I'm going to throw a party, with Troubleshooting Process Pioneers worldwide invited. We'll brag about our victory, discuss where we were brilliant and where we could have done better. We'll each tell our success stories, and brag about where we're going next. And for a night, we'll relax and enjoy.
See the next article, Come the Revolution.
"We won't get fooled again". In their song of that name, The Who describe the futility of revolution. Futile because once the fighting is over, self-serving hacks replace the zealots and the new regime becomes as bad as the old. The plot of films and Twilight Zone adventures, it's true enough to have become part of our collective consciousness. And it could happen to the Troubleshooting Movement.
If you think it far fetched, think again! It killed the American Quality Movement. That's right! Remember when America belatedly embraced Quality in the early 90's. Carpetbaggers, hucksters and snake oil salesmen (excuse me, consultants) bastardized the work of Deming and his peers, who spent their lives developing and evangelizing workable Quality methodologies. The spasmodic series of "programs of the month" produced by the carpetbaggers led to the slash-and-burn backlash, complete with massive layoffs and 16 hour days for the survivors. We *better not* get fooled again.
My email indicates American adoption of Troubleshooting as a Process is around the corner. And we know that when it happens, the carpetbaggers will be there. With their empty promises voiced in puffed up language from fuzzy concepts, they'll complicate and obscure a beautifully simple process. They'll do this because they don't understand the profundity of the process, and they believe they can't sell common sense.
So they obfuscate. And if they do much damage, the backlash surely will follow. Less support reps with even less training. Resurgence of "decision support" systems promising to make any phone operator into a support person (yuk yuk). "Diagnostic" hardware and software that promise to replace humans entirely (yuk yuk yuk). And multi-hour waits on the customer's nickel.
If we start now, we can stop the carpetbaggers. We need to define a set of standards for what Troubleshooting Process is, what it isn't, who is qualified to teach it, and where it interfaces with other systems like overall quality, business process, decision support, manufacturing and sales, and equally important, *where it doesn't*. With such a standard in place, would-be carpetbaggers will have no choice but to teach the right stuff the right way, or find some other area to peddle their snake-oil. Either way is fine.
We early advocates have a choice. We can go along for the ride, or we can shape the future. The former offers a couple years of wealth and fame, followed by a lifetime of regret (talk to some former Quality people if you think I'm voicing this too harshly). The latter offers a lifetime of wealth and satisfaction, and the knowledge that our work benefited everybody. We're the early advocates, and the choice is ours.
And it's never too early to begin to choose.
Here's where letters to the editor will go. Obviously the premier issue can't have letters to the editor. All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, etc.).
These first few issues, we'd greatly appreciate feedback type letters. Especially valuable are balanced letters, mixing suggested alternatives with criticism, or mixing areas of improvement with praise. Flames for flames sake or sycophantic praise aren't as valuable.
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.
We anticipate five to eight articles per issue, with issues coming out monthly. The next few issues we'll be looking for articles on how to bring the Troubleshooting Process to all areas of business and society. This can be done as an essay (like the three articles above), with humor, or with a case study. A Troubleshooting poem would be nice. We are *not* looking for ultra-technical or system-specific articles in the next few issues. Submissions should be between 250 and 2000 words long.
All submissions become the property of the publisher (Steve Litt). 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:
After that paragraph, write the text of the article.
http://www.troubleshooters.com is author Steve Litt's website.