Group C, and why you should fear them.

Ok, normally I find dividing people into groups is evidence of muddy thinking, but provided you don't start assuming that people won't move groups daily, it at least lets you get a handle on the situation. sometimes. its like triage, but for tech support :)

So lets define three groups.

Group A - These are the technophobes. Seriously. A light switch is a dangerously complex item to them, checking something is actually plugged in requires a tech support visit. In fact, almost everything requires a tech support visit, even answering "yes" to a "can a technician remote control your desktop" dialogue appears dangerously difficult, despite the fact they seem to universally click on "yes" for every webspite presented dialogue they ever see, usually faster than the text can render. They are maybe 40% of your workload, can be safely assigned to a junior to deal with, and rarely log problems that require more than a reboot or (at worst) resetting the application back to default. Typical "advanced" problem here would be a MDI subwindow that lacks a scrollbar - of course, it doesn't, its just larger than the MDI frame and the scrollbar is offscreen - now try explaining that over the phone.

Group B - The majority of your users, and pretty much your target audience 90% of the time. They will usually do what they are told to do, when told to do it (remembering for a future occasion is optional, but sometimes happens; a significant fraction of calls will be caused by them inappropriately repeating the "fix" that worked "last time" - when "last time" was different software with a different error, and sometimes on a different OS). Group B will apply for a place on training courses if offered them, but not actually request them, and sometimes will even learn from them. A shiny certificate is the goal though, not the actual knowledge.

Group C - Ostensibly your least problematic group, but the cause of unexpected and unpredictable explosions, often with little or no foreshadowing. Group C are frequently ahead of the curve; they rarely feel they need training, often know about new releases of products before you do, and generally don't kick up a fuss - if there is a major outage of something on the network, they are least likely to log a call on it, preferring to work around the issue or simply aware that eight other people in their office have already logged it and a ninth is not likely to make the process of repairing the issue any faster.

If a department has a "go to" guy to ask about techie issues before logging a call (especially if your company has an internal accounting scheme where the number of calls per department is logged and reported upstream) they will invariably be Group C - and often called Joe, for some reason (if anyone knows why, let me know; personally I think they should be called Dave but that's just me). Your typical "joe" can get something to work when it currently doesn't; often, he will get something to work when it definitely shouldn't, and sometimes when the manufacturer would have given up and told you to replace it. Exactly what combination of bailing wire, spit, and an improvised tool made from two wooden blocks and a dead meercat is required varies from person to person, but invariably he gets at least as good results as the IT department would, and you can always call them if he fails, yes?

If you started out life in another department, and moved into IT support, I am probably talking about you. I hope at least you have gotten some formal training and learned to document now :)

A Group C person often has some weird walt-goldberg assembly of excel macros (why is it usually excel? another good question), saved SQL queries (which often can't be edited because the MS editor either can't find a component table or the beast was typed in raw sql but can't be re-opened in that mode), text files, and strange "rule of thumb" decision trees that, for no readily discernible reason seem to give the right answer despite lacking half the input and most of the rules the corporate system would use to find that answer. You may only find out that this beast exists when half a department depends on it for a weekly report, and have started asking why it isn't "officially supported".

Which brings us to our actual point which is - what happens when it doesn't seem to work any more? because that's often the first warning you have that things are about to go horribly, horribly wrong for you, your team, and often big chunks of the company. That spreadsheet is not giving an answer, is giving last week's answer, is giving a wrong answer in subsection a(4) but is otherwise correct. Assuming you can find where it is actually getting the data from, you find an obscure text file on shared storage (lets hope its still there) with no visible way to be updated, but which contains a combination of raw and cooked data (unlabelled) which, if corrected, will lead to the solution starting to work again. At this point, you are already trying to find out why they are using this nightmare of random operations, and invariably, the answer is because it works - or did.

"Joe" wrote it. Joe either is on holiday, has retired, or can't figure out why it doesn't work either - the latter option being the scariest at this point, as you can't figure out how it ever worked. Often, Joe can put it back the way it was, but that brings us to our next little timebomb - when the one that joe wrote is still working fine, but some other user or department decided they needed one, too. If you have adopted sharepoint, you are going to find this to be a great source of departmental pride - invariably, they will stick something like this on it and call it a "Dashboard" - it will have pretty graphs, it will have data points, it will have big numbers and important names, and in many cases actually show some useful information - but that's secondary to the main goals of looking impressive and making the department look good.

which is fine, really. at least, it doesn't cause too much pain for IT Support, except when they overload sharepoint by trying for five second refreshes on a 10K data set.....

The pain comes when you get orders from On High. Department X requires one too - it must be flashy, it must look better than Department Y's, it must.... well, in short, they want one because Department Y has one, but their Joe doesn't know how to make one or is at least claiming ignorance as he doesn't actually want to do it. Or Department X wants a spreadsheet that tells them all about their activities for the last two months, with graphs and everything, because the one Department Y has does that.

Does Department X even have the right data for that? Nobody knows, nobody cares, that's your problem now, not theirs.....

anyhow, enough rant for now :)