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

AID: 2742
  • Status: Published

9190 points

  • By
  • TypeGeneral
  • Posted on2010-03-26 at 09:23:49
Awards
  • Community Pick
  • Experts Exchange Approved
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.

Asked On
2010-03-26 at 09:23:49ID2742
Tags

expert ask help question

Topic

Consulting

Views
2001

Comments

Expert Comment

by: younghv on 2010-03-26 at 16:53:12ID: 11965

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.

Expert Comment

by: Qlemo on 2010-03-26 at 18:55:39ID: 11972

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.

Expert Comment

by: seiko_08 on 2010-03-26 at 21:35:23ID: 11980

Every person that registers as an 'expert' should be required to read this. Thanks for sharing.

Expert Comment

by: evilrix on 2010-03-27 at 04:55:25ID: 11995

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

Gets my yes vote.

Author Comment

by: sdstuber on 2010-03-27 at 07:09:41ID: 12002

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

Expert Comment

by: RunningGag on 2010-03-28 at 11:43:36ID: 12042

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.

Expert Comment

by: GreatGerm on 2010-03-29 at 08:05:50ID: 12108

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

Expert Comment

by: nappy_d on 2010-03-30 at 03:44:07ID: 12314

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".

Expert Comment

by: grtraders on 2010-04-01 at 23:02:19ID: 12567

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.

Expert Comment

by: knightrd on 2010-04-12 at 21:08:45ID: 13059

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.

Author Comment

by: sdstuber on 2010-05-03 at 12:43:53ID: 14048

RunningGag, GreatGerm, nappy_d, grtraders, knightrd


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

Expert Comment

by: Geert_Gruwez on 2010-07-22 at 01:22:57ID: 17330

Great article.

Got my "YES" vote

Author Comment

by: sdstuber on 2010-07-22 at 04:54:43ID: 17335

Thanks Geert_Gruwez!

Author Comment

by: sdstuber on 2010-08-16 at 09:29:25ID: 18237

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.

Expert Comment

by: Geert_Gruwez on 2010-08-17 at 07:45:15ID: 18297

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 !!!

Expert Comment

by: Bajwa on 2012-03-11 at 07:49:49ID: 45264

A very good article for my Yes vote.

Add your Comment

Please Sign up or Log in to comment on this article.

Join Experts Exchange Today

Gain Access to all our Tech Resources

Get personalized answers

Ask unlimited questions

Access Proven Solutions

Search 3.2 million solutions

Read In-Depth How-To Guides

1000+ articles, demos, & tips

Watch Step by Step Tutorials

Learn direct from top tech pros

And Much More!

Your complete tech resource

See Plans and Pricing

30-day free trial. Register in 60 seconds.

Loading Advertisement...

Top Consulting Experts

  1. DrDamnit

    27,384

    20 points yesterday

    Profile
    Rank: Genius
  2. leew

    10,763

    10 points yesterday

    Profile
    Rank: Savant
  3. cs97jjm3

    10,110

    0 points yesterday

    Profile
    Rank: Genius
  4. notacomputergeek

    8,436

    0 points yesterday

    Profile
    Rank: Wizard
  5. madunix

    8,320

    0 points yesterday

    Profile
    Rank: Sage
  6. hanccocka

    6,000

    0 points yesterday

    Profile
    Rank: Genius
  7. JZeolla

    5,000

    0 points yesterday

    Profile
  8. thinkpads_user

    4,736

    0 points yesterday

    Profile
    Rank: Genius
  9. nobus

    4,000

    0 points yesterday

    Profile
    Rank: Savant
  10. viki2000

    3,832

    0 points yesterday

    Profile
    Rank: Guru
  11. aburr

    3,600

    0 points yesterday

    Profile
    Rank: Genius
  12. Michael-Best

    3,100

    0 points yesterday

    Profile
    Rank: Sage
  13. x_com

    2,800

    0 points yesterday

    Profile
    Rank: Genius
  14. Cyclops3590

    2,800

    0 points yesterday

    Profile
    Rank: Genius
  15. breadtan

    2,800

    0 points yesterday

    Profile
    Rank: Genius
  16. limjianan

    2,800

    0 points yesterday

    Profile
    Rank: Genius
  17. Russell_Venable

    2,668

    0 points yesterday

    Profile
    Rank: Wizard
  18. dvt_localboy

    2,664

    0 points yesterday

    Profile
    Rank: Sage
  19. aarontomosky

    2,650

    0 points yesterday

    Profile
    Rank: Genius
  20. Tymetwister

    2,350

    0 points yesterday

    Profile
    Rank: Master
  21. mlmcc

    2,100

    0 points yesterday

    Profile
    Rank: Savant
  22. DavisMcCarn

    2,100

    0 points yesterday

    Profile
    Rank: Genius
  23. chakko

    2,100

    0 points yesterday

    Profile
    Rank: Genius
  24. stone5150

    2,080

    0 points yesterday

    Profile
    Rank: Guru
  25. sedgwick

    2,000

    0 points yesterday

    Profile
    Rank: Genius

Hall Of Fame