I’ve been working with computers for more than 29 years and in software development on and off, in various roles, for almost 27 years. Working with computers is a love/hate thing. Only total geeks totally love computers.
Partial geeks, like me, both love and hate their computers. You may have noticed that computers can be, well, somewhat frustrating.
All too often, though, what makes the computing experience really unpleasant are the people who are supposed to make the computing experience better 3/4 the technical-support staff. I’ve had the misfortune of spending hundreds of hours during the last almost 30 years on phone calls with people who often know less about the software I’m having a problem with than I do. Yet they are the official conduit between me and the information I desperately need.
Sure there are some good tech-support people. Just last week I ran into some really good people at TZO.com who were able to fix the problems with my Windows Home Server that were caused by advice from some not-so-good people at H-P. However, all too often technical support people have little knowledge and even less common sense. They also tend to be very defensive about the product they are supporting and the company they work for, which leads to a real problem. It’s not just that they are irritating the people they are supposed to help, but they are actually hurting the development of the product they are supporting.
If I ever find myself in charge of a technical-support department, I’ll make one critical change. No, I’m not talking about the daily floggings and occasional executions 3/4 to “encourage the rest” 3/4 though certainly those would be among the modifications. Perhaps the most important change I would make is to teach the tech support staff to change sides. They need to be on the side of the customer, not the company.
Hundreds of times during the last third of a century I’ve tried to help software companies by reporting bugs during technical support calls 3/4 sometimes even very significant bugs 3/4 only to have defensive tech-support people either ignore the report or even deny the issue being reported was a bug. For a professional bug-hunter this is extremely frustrating. Some kid with a couple of years of rather shallow computing experience is telling me, with my years of user-interface-design experience, that the problem I’m reporting isn’t a problem at all.
This just happened yesterday, in fact. I was having problems with an online-backup program. The program won’t back up my e-mail files for some reason. While on the phone I pointed out another small bug I’d noticed. This was not because I really cared but because I figured the developers would probably want to know. The bug was related to selecting files for backup, in a folder “tree” with check boxes next to folder and file names. Sometimes I’d see a grayed-out check in a check box, yet when I looked down to the next level of check boxes 3/4 the subfolders 3/4 nothing was checked. There were neither black nor gray check marks visible. Our discussion went something like this:
Tech Support: “That’s not a bug.”
Me: “It most certainly is.”
Tech Support: “That’s the way it works.”
Me: “But it shouldn’t work that way.”
Tech Support: “That’s the way the programmer programmed it. It’s a feature.”
Wow, how many times have I heard that a bug was actually a feature? As I pointed out to the tech-support guy, if the programmer really intended it to work this way, then it was 3/4 to use a term sometimes heard in the development business 3/4 a “buglike feature.” In fact it wasn’t, it was just a plain old bug. As the head of the development team told me today, it was “a long, pending issue.”
The problem is that while customers are also testers, the information derived from this constant product testing is often blocked from reaching the software-development department by the tech-support department. Why? It’s because tech-support people are defensive about the product they support and company they work for. They see bug reports as criticism, and thus often deny the bug exists or underestimate the importance. While this little bug wasn’t important and was already known to the development team, the e-mail-backup problem I’m currently having is the sort of thing that could get the company into serious trouble. The only reason the developers are now working on it is because I called the PR department and told them that I was working on this article and planned to use the company as an example.
Customers are a fantastic source of information about software products, so software companies need to do two things 3/4 they need to build a formal process for feeding bug reports back from tech support into the development team, and they need to teach their staff to be a little less thin skinned. If a feature doesn’t work, or doesn’t seem to make sense from the customer’s point of view, then it’s probably a bug.
Peter Kent is an e-commerce consultant in Denver. He’s currently working with e-book software company DNAML, www.DNAML.com, to introduce its products to U.S. publishers.