<

Are You a Bad Expert?  A case study of an asker in distress.

Published on
17,722 Points
4,322 Views
39 Endorsements
Last Modified:
Awarded
Community Pick
I've recently had a problem where I needed to ask for help.  I didn't come to Experts-Exchange to ask my question because it had to do with a vendor product and the issue was pretty clearly a bug in their code.  So only the vendor was capable and authorized to fix it.

However, my experience is potentially the same thing that could happen to an asker here or on any help site.  It could just as well apply to face-to-face situations of professional tech-consulting or helping a friend trying to save their wilting garden.


Discovering the problem and starting a question

First, I identified an issue in my program, I tried for hours and then days to get it to work assuming I had made a mistake.  I will admit I am not an expert in this particular feature.  Fortunately, the vendor product has excellent instrumentation which let me see what they were doing with my data, and it became quite clear that what I passed in was not what they were processing.  Their own logs showed me the problem.

So, I begin the question process.  I log in to their help site and click to open a new request.  Immediately I'm confronted with the problem, how do I classify my problem?  I imagine this might be similar to what some people think trying to pick an EE Zone.   I have a very specific problem but my categories to choose from are very broad.  None of the choices seem to fit perfectly but I picked as best I could and then left a comment about why I had picked the category. Maybe I was lucky  but I was directed to somebody that seemed to know what I was talking about.  So, whether I picked correctly or if I was internally "re-zoned", I don't know; but things seemed to start out well.

Additionally I was thrust through a series of stock questions.  What's your version?  Is this new?  Does the system continue working after the problem?  Is this an emergency? etc.  I don't think there is an exact parallel to this at Experts-Exchange,  I'm not sure if that's good or bad.  From the vendor standpoint I can see why the stock questions exist, but for me, I had a very specific problem and most of the questions didn't seem to apply.

The Moron Filter

Next I entered what I call "The Moron Filter".  Imagine your neighbor is having trouble with their computer and your first question is "Is it plugged in?"  Again, I can see why the vendor's support team does this.  They have thousands of customers and I'm sure they get lots of calls, emails and help requests from people misusing and abusing their product. And, to their credit, their product is good, that's why I use it.  So there is a reasonable assumption that any problem coming in is likely because of the user (in this case, ME) and not actually their application.

Similarly, this happens on EE.  If the asker's problem is vague or even if specific but could have multiple possible causes you have to do some basic interrogation.  I work in the Oracle Database zones, so I frequently ask people to post some sample data. Not only does it help me build a test case, but before I dive too deeply into the problem I want to see if their SQL even applies to what they are querying.  Are they trying to query a date that is really an alphanumeric-string? Typically these trivial opening questions move along pretty quickly.  Either the problem really is that simple and the asker thanks you for the quick response, or you clear the basics and move on to the more meaty and interesting parts of the asker's problem.

This, unfortunately, is not what happened to me and my question.  Due to network security and regulatory issues it would have been difficult to expose my live system to the internet for the vendor to examine directly.  So, I posted the parameters I was using, the output I expected and what I was really getting from their logs.  Furthermore I constructed a simple plug-n-play test case that demonstrated the same behavior but didn't require any of my internal systems or applications to function.  They could run the code on any of their own systems and see the same issue.

First response back was surprising but fair.  Between the time I had installed this add-on to the vendor product and the time I reported this error the product had been upgraded.  But, the upgrade didn't apply to the add-on, only the base product.  So I had to uninstall the old version and reinstall the upgraded version of the add-on.  Fair enough, I was running an unsupported combination of product and add-on.    That's my fault, so I posted the results of the add-on upgrade log (successful) and then reran my sample.  Same error, and posted the results demonstrating the problem still existed.  I also tested my internal application as well, just in case it somehow worked, and the error, as expected, was replicated there as it was in the sample.

And then the tide turns...

Here things start to really fall apart.  

I was asked if I had tested the example.  Yes, of course I had. Not only had I tested, but I had posted the results!  Hadn't they read my replies?  

Then I was asked to try to keep to a single topic per question.  If my issue was really with a "perceived bug" or if I needed consultation on how to properly use their add-on.  Maybe the parameters I was using were erroneous and I needed proper instruction on how to format the inputs.  To be fair, the vendor doesn't know that I had spent days trying to get this to work before finally giving up and contacting them.  On the other hand,  I gave them a self-contained test case.  All they had to do was run it.  If they get the same results I do then the problem is fairly self evident.  If they get different results, they can post those and it's obvious that something is different in my system and we can try to pursue that route.

So, even if I have no idea what I'm talking about, I have at least given them something to look at.  If it's ludicrous they can have a laugh at my expense and then explain what is wrong with my test case.

I've provided the logs of everything I've tried.  My question all along has been.  "I pass in parameter X,  their logs show they are processing Y."   My claim is their code is manipulating my input.    Of course, it's possible I'm misinterpreting their logs;  but I have provided what I'm reading, as well as what I think they are saying.  If I'm wrong, they can again laugh at me if they want but then explain what I'm not seeing.

Of course I don't want to be laughed at for my mistakes, and I don't know if they would anyway. But my point is I  provided what "I" thought was adequate information.  If it was incomplete tell me.  If it was wrong, tell me.  If I misinterpret what is right in front of me,  tell me.  But that's not what happened.  Instead of really looking at what I  provided I was stuck in their Moron Filter.

If this article seems like one-sided whining, or if it sounds like a fair explanation of a question gone bad.  That's fine,  either interpretation is good. That's the whole point of why I'm writing.    This is supposed to be about what I think went wrong with my question.  This is supposed to be one-sided. My side.  The asker's side.

From the asker's perspective he or she is doing what they think is right and are providing what they think is correct and complete information.  I'm willing to believe I was wrong above; but I supplied what I thought was good info with all due diligence applied to investing the problem on my end and gathering useful feedback.  My complaint isn't that I was asked for more information.  My complaint is that I was being asked for information that doesn't take into account what was already provided.

Of course, there are bad askers, but there are plenty of articles, thread comments and expert profiles ranting and/or explaining good asker practice.  Having been on the other end of the question spectrum I want to remind myself and others that when we agree to help someone there is an implicit agreement to actually be "helpful".  To listen to what is said, to take what is given and make whatever we can of it.  If the asker feedback is incomplete, erroneous, disconnected or otherwise failing... use what you can of it and ask for more; but first "look" at what was given and try to see the context of the asker.   When you, the expert, run somebody through your own "Moron Filter" remember they may already be at their wits end with the problem you just saw 2 minutes ago.  Your innocent question may be the one that finally pushes the asker over the edge to frustrated hostility.

39
Comment
Author:sdstuber
24 Comments
 
LVL 38

Expert Comment

by:younghv
sdstuber:
Did I ever enjoy reading this!

One of my all-time pet-peeves is to log onto a Help Session/Chat function...describe (fully) the specific OS and the steps I have already taken to resolve the problem - then get back the first response from the Helpless Desk: "What OS are you running?". As you have described, it goes rapidly downhill from there.

Thanks for a good read.

"Yes" vote above.
0
 
LVL 73

Expert Comment

by:Qlemo
Certainly, it is something very interesting to be "at the other side", but also it's frustrating. Everyone being part of a support team himself will arrive at that point some day - you are calling a "help" line, and they treat you as a fool, even if you indicate knowledge and describe in detail you already have done anything they do or will suggest. I know for sure that it is veeeery difficult to estimate the knowledge of someone else you do not work with all day, however, I'm trying at least ;-)

This article is something everybody should have in mind every time they are called in a support scenario. It's happening on EE, it's happening in "real life". Many of us are both victim and offender.

Good article, gets my vote.
0
 
LVL 12

Expert Comment

by:Joshua Titsworth
Every person that registers as an 'expert' should be required to read this. Thanks for sharing.
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
LVL 40

Expert Comment

by:evilrix
I love this article. Been there, done that and wore the "I hate help desks" t-shirt :)

Gets my yes vote.
0
 
LVL 74

Author Comment

by:sdstuber
younghv, Qlemo, seiko_08, evilrix and the mystery #5 vote

Thank you all for the kind words.  
I'm glad you enjoyed it.

Hopefully it'll help others as well
0
 
LVL 4

Expert Comment

by:RunningGag
You run across this kind of complaint on a fairly regular basis.  Most of the time it applies to service providers and big box store techs.  I think people who are in an expert position when they call for help need to understand that the person on the other end has to follow a procedure; they have to assume that you are a complete dunce.  So when they ask you if you managed to unplug your computer / modem / router / etc., its because they've seen it more times than they can remember and they want you to check before they start more advance diagnostics.  Its a CYA situation.  They don't have the option of assuming that you know what you are doing.

On the other hand, it doesn't help their case when they ignore information that they're given, as in the example above.

Yes vote.
0
 
LVL 17

Expert Comment

by:GreatGerm
This was a great read and a point of view that I think occasionally forgotten by experts on this site (myself included).
0
 
LVL 32

Expert Comment

by:nappy_d
I absolutely agree.  When I first started in IT, it was the days of only the telephone and I had to visualize what the customer was seeing.  There was no WinVNC or WebEX sessions, it was your brain.  You had to learn to listen and decipher what was being asked or relayed to you.  Times have changed.

At the same time, as much as those who are seasoned IT veterans, when responding to questions asked, it may be annoying to the asker's on EE or when speaking to software vendors but I think asking the most rudimentary questions(even if the asker does not think it applies, is necessary).

I myself have been burned by not asking the very basic questions and trying to jump into the "glitzy" assumed resolutions, so I can see the vendor support side but also understand the frustration of the asker.

Maybe, when registering at EE a one question test should be involved for comprehension, I think those in EE's case help weed out the "bad expert".
0
 
LVL 18

Expert Comment

by:Ravi Agrawal
Very good article,

Worth a read.

I have myself been at many Support calls trying to explain a problem only to figure out most of the time that the person attending the call has in most cases direct my call to his superior. Of course, there is a wait period and you have to always face that. This is because most of the time, the calling party is indeed a fool. This being quite true, first you have to make yourself clear that your are not one of those fools. :-)

Moreover most of the help-desk support configured in a way to think that their product is perfect. So there is no bugs section, I have seen it in many places. Every vendor thinks his product is perfect and the end user is using it incorrectly. So they are always trying to correct you in using the product rather than thinking something is wrong on their side.

Ravi.
0
 
LVL 3

Expert Comment

by:knightrd
Nice article - great points. One of the important things to do as a tech is to gauge the technical ability of the person you are talking to. You never want to seem to be talking down to someone, not listening, or not taking them seriously.

I've been doing various types of support for a long time now. There is a flip side to this, but I don't mean that it invalidates anything you are saying because I do agree with you points. I have developed a rule based on past experience troubleshooting difficult problems. If something defies explanation and it seems like every advanced troubleshooting step has been done under the sun, it makes sense to examine again the chain of troubleshooting from the beginning.

When I did help desk work earlier in my career, I was "burned" by bad information from customers that wanted to provide me a lot of data or assumptions up front. That's not to say that I just disregarded what they told me, but there were cases where troubleshooting would go on over the phone for 1-3 hours... just to find out that I was given some bad information in the beginning.

Over time any type of support person or analyst should develop of intuitive sense of whether something is moving in the right direction. Sometimes the simple answers are right, but in any case testing various things through a logical POE (process of elimination) should narrow the cause down.

It may be that they have an excellent product and need to improve their support process. A good support process allows for various levels or tiers of expertise, but at the same time the process to the correct level of support should be sensible. I've seen environments that make getting to the right support person very difficult and that is sort of what it sounds like.
0
 
LVL 74

Author Comment

by:sdstuber
RunningGag, GreatGerm, nappy_d, grtraders, knightrd


Thank you all for reading, glad you enjoyed it, and voted!

0
 
LVL 39

Expert Comment

by:Geert G
Great article.

Got my "YES" vote
0
 
LVL 74

Author Comment

by:sdstuber
Thanks Geert_Gruwez!
0
 
LVL 74

Author Comment

by:sdstuber
In case any of the readers were waiting in suspense for the ending of my tale.

It took nearly 5 months and required 3 vendor attempts at patches, but my problem has been fixed.
0
 
LVL 39

Expert Comment

by:Geert G
Yesterday, i got this phone call:
Hello, I am of company XYZ.  We have very good deals for you to pay less for your mobile phone contract.
We estimate that we can reduce the cost with 25%

I took 5 attempts to explain to this person that i had a company phone, with 0 as cost,
and that it would be impossible for her to beat that offer.  I actually hung up in the end.  Very rude, I know.

I know null/nothing in a database causes a lot of distress with developers.
Now I know it's also outside the database !!!
0
 
LVL 5

Expert Comment

by:Bajwa
A very good article for my Yes vote.
0
 
LVL 111

Expert Comment

by:Ray Paseur
Love this article.  I like to fall back on the SSCCE.  If the asker can read and understand that web page, we can almost always have a well-focused dialog!
0
 
LVL 13

Expert Comment

by:Jeff Darling
Nice Job!    

It is better to give than receive.  Be kind to one another.

I've been working in IT for over 20 years.  I've dealt with all kinds of IT people.  I think IT people need to be held to a higher standard in terms of the patience and compassion that are required.   I have met some really nice IT people, and some mean IT People.

Because of this, I try to be sensitive but not condescending.  This is difficult when you do not understand your customer.  (whether it be internal customer or external customer to your workplace)

This gets even more difficult when the person you are trying to help is more skilled than you in their particular field.  

It's great when I can help people learn how to troubleshoot on their own.  Think of it as teach a man to fish and he won't starve kind of thing.
0
 
LVL 74

Author Comment

by:sdstuber
Bajwa, Ray, Jeff - thank you all, I'm glad to see this is still a popular read.

Thanks too for the votes!
0
 
LVL 26

Expert Comment

by:Nick67
I think we all know that there are some folks whose motivation is not to supply an Answer for the long-run, but gratification in the short-run.  'It takes a great man to be a good listener.'  For the discerning Expert, there is greater satisfaction in reading between the lines and supplying a true solution, rather than 'answering the question'

For folks who are focused on their internal script -- and heavens know I've dealt with enough level-one help-desk 'script Jockeys,' the reward is getting to the end of the script, not solving the problem.

Well-written article.
Thanks,

Nick67
0
 
LVL 55

Expert Comment

by:Scott Fell, EE MVE
This showed up in my feed today and I am glad it did.  Even though old, still current. Articles like this including Jim's http://www.experts-exchange.com/articles/18499/Top-10-Ways-to-Ask-Better-Questions.html should be grouped together in some way.
0
 
LVL 111

Expert Comment

by:Ray Paseur
0
 
LVL 74

Author Comment

by:sdstuber
I'm glad you enjoyed it.  I reread it everyonce in a while as refresher to myself.

Becoming a bad expert is an easy trap to fall into when you see the same error for the 1000th time; but for the asker it might be the first time and while I might be bored of it, it can still be traumatic for the asker.
0
 
LVL 55

Expert Comment

by:Scott Fell, EE MVE
"Bad Expert" or "Bad Asker", both happen and are really just how the other interprets.  

When we find something wrong, we need to look at ourselves and this is what I think you are addressing.  If the Expert asks if you are sure your thing is plugged in, Askers shouldn't take offense as many times it is the smack yourself in the head, "oops" thing that was forgotten.

Many times questions are not clear, and the good Expert will ask questions to help pull out the right question which in turn will probably answer the problem which may be different from the question.  Many times the Asker is sure their question is focused on one specific thing but it is not.  This can cause frustration for both Asker and Expert.  

I have referenced this to my knowledge base and will for sure use this to help others get a hint when needed.
0

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Join & Write a Comment

Did you know PowerShell can save you time with SaaS platforms? Simply leverage RESTfulAPIs to build your own PowerShell modules. These will kill repetitive tickets and tabs, using the command Invoke-RestMethod. Tune into this webinar to learn how…
Basic Overview of office 365 user portal

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month