FUD for troubleshooting

I have witnessed many companies and politicians making very good use of "FUD" in public relations. (see FUD)
In my line of work I see a correlary in action far too often in the area of troublehooting or worse, in root cause investigation. Since I love a good TLA (three letter acronym) I will manufacture one to describe it. SIR = Superstition, Ignorance, and Rumor.

This problem is vaguely familiar (I can't be sure because I never put that much thought into problem definition. So, really, almost all of them are vaguely familiar.) So, I should immediately launch into "what fixed it last time."
Although I make enthusiastic use my good fortune on days when my superhero underpants are working in my favor, I can't really respect this as the basis of troubleshooting. When your job is to be the final point of escalation for major enterprise issues in an organization you really need to THINK BEFORE YOU ACT. Even greater a pox upon you if you are a support engineer for a worldwide company to whom enterprise customers pay $100K per year for support. In this case you must obey me when I tell you to ESCALATE ME NOW. (Or I will be forced to declare my help call a critical incident and waste everybody's resources because you are stupid.)

I am the subject matter expert and this is my answer. By definition I am right.
There is no shame in not knowing something. Indeed we all must accept that no single person can ever know everything that might be relevant to figuring out my problems and so I expect ignorance. However, I cannot abide someone without the common sense and humilty to admit that they are not the all-knowing god of [insert product/technology here.] When a solution is presented based on a 20-something's omniscience and I don't think it will help I will often ask questions which get a patronizing answer. When I get tired of being called "dude" and tell him to ESCALATE ME NOW. It never works. I have to call his boss. I am embarrassed for these people when even though the investigation goes another direction and it's pretty obvious they were on the wrong track, they will continue to interject excuses or reasoning why they thought the way they did long after it is relevant.
Even when it's not taken that far, IGNORANCE--leading to a lack of motivation to GATHER ALL THE FACTS--feeds a frenzy of SUPERSTITION and RUMOR in a dysfunctional troubleshooting environment.

They are having a network problem.
Lack of problem definition and detailed investigation will often lead IT Management (and, ugh, even sometimes USER Management) to pigeon hole problems/systems/people on a snap judgement of the cause of a problem based faulty or lack of investigation to define problems. This failure is manifested in management decisions for project direction, purchasing, and professional development are not based on fact. The root of this phenomina information gathered by the IT first contact person with the user who has the problem (Service Desk.)
RUMOR also feeds back into SUPERSTITION
When this phylosophy is deeply entrenched in the culture of the organization users don't even report their problems they tell the helpdesk that "the DNS server is having that problem again" and so the service desk opens a ticket to the same group that "fixed it last time." Too bad that the job of the service desk person is going to have to be done by an engineer who has to call the user back (and possibly play phone tag first) to get further details about a problem only to find out that (surprise!) the user was wrong about the diagnosis of their problem and it has to be requeued to the correct resources. The time wasted by this activity aggravates the user and often makes the real problem harder to diagnose. So when the lucky top tier engineer has to call the user for additional information about the problem the user is either to angry to be helpful or has forgotten any useful details.

No comments: