The expert also is better equipped to discern whether a situation is unusual, because the expert has seen more.
Very true as well, though I will add the counter-caveat that the expert is usually biased toward concluding that your situation is not unusual. This is why many “tech support horror stories” have a bit where the narrator goes ”… and then, when they finally got it through their heads that yes, I had tried restarting it five times, and no, I didn’t have the wrong settings …”
I suspect there are a couple of things going on there.
One, it’s important to distinguish consulting an expert from consulting a tech support script. Most of the time when you call up tech support, you’re talking to a human being, but not an expert. You’re talking to a person whose job it is to execute a script in order to relieve the experts from dealing with the common cases.
(And yes, it’s in the interest of a consumer tech-support department to spend as little money on expensive experts as they can get away with — which is why when a Windows box has gotten laggy, they say “reboot it” and not “pop open the task manager and see what’s using 100% of your CPU”. They don’t want to diagnose the long-term problem (your Scrabble game that you left running in the background has a bug that makes it busy-wait if it’s back there for 26 hours); they want to make your computer work now and get you off the line. That’s a different case from, for instance, an institutional IT department (at, say, a university) that has to maintain a passable reputation with the faculty who actually care about getting their research done.)
Two, there’s narrative bias. The much-more-numerous cases where the simple fix works don’t make for good “horror stories”, so you don’t hear them retold. Especially the ones where the poor user is now embarrassed because they have to admit they were outguessed by a tech-support script after giving the support tech a hard time.
(Yeah, I like good tech support too; that’s part of why I use the local awesome option (Sonic.net) for my ISP instead of Comcast. I can call them up and talk to someone who actually knows what ARP means. But sometimes the problem does go away for months when you power-cycle the damn modem.)
Very true as well, though I will add the counter-caveat that the expert is usually biased toward concluding that your situation is not unusual.
Well, we don’t know that they’re actually biased in this direction until we know how their assessment of the probability that the usual thing is going on compares to the actual probability that the usual thing is going on.
Yes, there are plenty of “tech support horror stories” where the consultant has a hard time catching on to the fact that the complainant is not dealing with a usual or trivial problem, but for every one of those, there tends to be a slew of horror stories from the other end, of people getting completely wound up over something that the consultant can solve trivially, and failing to follow the simple advice needed to do so.
The consultants could be very well calibrated, and still occasionally be dramatically wrong. Beware availability bias.
Note that cases where the tech tells you that it’s usual problem X, and you deny this, asserting that your thing is a special snowflake, is NOT a case of the opposite bias. It’s just a case of correct identification.
The opposite bias would be if the usual thing was going on, but the tech thought that it was some unusual thing.
Other IT-experienced people are welcome to correct me on this, but in my experience, the latter almost never happens, and when it does, it’s mostly with newbie techies, recent hires/trainees, etc.
This makes it substantially more likely that tech people have “usual problem bias” than that they have “unusual problem bias”, and that they are well-calibrated. The usual problem bias could be small or it could be large, but available evidence is fairly clear that it exists.
The point I was making was not that tech support is likely to have an “unusual problem bias,” but that being correctly calibrated with respect to usual and unusual problems will tend to appear like a “usual problem bias” when you examine in isolation the cases where they’re wrong, because you would tend to observe cases where they need a significant amount of evidence to persuade them of the presence of an unusual problem, but not an unusual one.
If you examine cases where they’re right, you may find a large number of cases where the customer insists that the problem is not addressed by the tech support’s script, only to be proven wrong; these often appear in the horror stories posted by tech support. Thus, tech support may to some extent be rationally discounting evidence favoring unusual problems.
Very true as well, though I will add the counter-caveat that the expert is usually biased toward concluding that your situation is not unusual. This is why many “tech support horror stories” have a bit where the narrator goes ”… and then, when they finally got it through their heads that yes, I had tried restarting it five times, and no, I didn’t have the wrong settings …”
I suspect there are a couple of things going on there.
One, it’s important to distinguish consulting an expert from consulting a tech support script. Most of the time when you call up tech support, you’re talking to a human being, but not an expert. You’re talking to a person whose job it is to execute a script in order to relieve the experts from dealing with the common cases.
(And yes, it’s in the interest of a consumer tech-support department to spend as little money on expensive experts as they can get away with — which is why when a Windows box has gotten laggy, they say “reboot it” and not “pop open the task manager and see what’s using 100% of your CPU”. They don’t want to diagnose the long-term problem (your Scrabble game that you left running in the background has a bug that makes it busy-wait if it’s back there for 26 hours); they want to make your computer work now and get you off the line. That’s a different case from, for instance, an institutional IT department (at, say, a university) that has to maintain a passable reputation with the faculty who actually care about getting their research done.)
Two, there’s narrative bias. The much-more-numerous cases where the simple fix works don’t make for good “horror stories”, so you don’t hear them retold. Especially the ones where the poor user is now embarrassed because they have to admit they were outguessed by a tech-support script after giving the support tech a hard time.
(Yeah, I like good tech support too; that’s part of why I use the local awesome option (Sonic.net) for my ISP instead of Comcast. I can call them up and talk to someone who actually knows what ARP means. But sometimes the problem does go away for months when you power-cycle the damn modem.)
Well, we don’t know that they’re actually biased in this direction until we know how their assessment of the probability that the usual thing is going on compares to the actual probability that the usual thing is going on.
Yes, there are plenty of “tech support horror stories” where the consultant has a hard time catching on to the fact that the complainant is not dealing with a usual or trivial problem, but for every one of those, there tends to be a slew of horror stories from the other end, of people getting completely wound up over something that the consultant can solve trivially, and failing to follow the simple advice needed to do so.
The consultants could be very well calibrated, and still occasionally be dramatically wrong. Beware availability bias.
Note that cases where the tech tells you that it’s usual problem X, and you deny this, asserting that your thing is a special snowflake, is NOT a case of the opposite bias. It’s just a case of correct identification.
The opposite bias would be if the usual thing was going on, but the tech thought that it was some unusual thing.
Other IT-experienced people are welcome to correct me on this, but in my experience, the latter almost never happens, and when it does, it’s mostly with newbie techies, recent hires/trainees, etc.
This makes it substantially more likely that tech people have “usual problem bias” than that they have “unusual problem bias”, and that they are well-calibrated. The usual problem bias could be small or it could be large, but available evidence is fairly clear that it exists.
The point I was making was not that tech support is likely to have an “unusual problem bias,” but that being correctly calibrated with respect to usual and unusual problems will tend to appear like a “usual problem bias” when you examine in isolation the cases where they’re wrong, because you would tend to observe cases where they need a significant amount of evidence to persuade them of the presence of an unusual problem, but not an unusual one.
If you examine cases where they’re right, you may find a large number of cases where the customer insists that the problem is not addressed by the tech support’s script, only to be proven wrong; these often appear in the horror stories posted by tech support. Thus, tech support may to some extent be rationally discounting evidence favoring unusual problems.