The Not-So-Expert Experts.

I’ve always had a healthy amount of respect for anyone who’s dedicated a significant part of their life to becoming well versed in some area of knowledge. From things like the intricacies of woodworking to the complex mathematical modelling of 2 black holes meeting each other¹ there’s something to be said for following something to the point that few ever attempt to do. I’d like to think I’m pretty well versed in the world of IT and general technological matters and few would disagree. What’s been getting my goad up lately however is those who think along the same lines yet are completely clueless about the things they believe they are the experts in.

Now this particular gripe stems from a specific scenario so you’ll have to stick with me here. Currently I’m in charge of moving a whole bunch of systems (current count is 73, it used to be 150) from the old network to the new network. On the outside it looks pretty simple as I’m just changing the address of the system and maybe its physical location, nothing more. The service these systems provide will not be changed in the slightest, save for it appearing on another address. The technically inclined amongst us would be thinking “No worries, DNS (the thing that takes human readable names and turns them into machine readable names and vice versa) should take care of most of your issues” and you’d be right, it should. However there are always hard coded references to certain things and some software vendors think it’s a great idea to tie the licensing to the IP address. So in the course of moving the 77 odd systems I’ve managed to break a couple things along the way, but the trouble began long before things started breaking.

You see I’m not the one who developed, implemented or even (for the most part) supported any of these systems. Naturally I sought out the experts for these systems because I’d rather not break something if I have a chance to avoid it. Unfortunately it seems that many of the so called “experts” were far from it, falling into one of two very distinct categories:

• The Scapegoat: Now I can’t really lay too much blame on these people, as in the past they probably had only a passing association with the system they’re now responsible for. Through some twist of fate these guys were lumped with the sole responsibility for their system and 99% of the time they have no idea of how anything works in it (past straight rote memorization of some features). They wouldn’t be an issue if they said this beforehand as most seem to act like an expert up until something breaks. There after they then absolve themselves of the situation by announcing their scapegoat status, leaving me to look like I’m responsible for the whole mess.
• The Dangerous Idiot: The one who says they know everything but is nothing more than a glorified super user. These guys are far more common especially those who are not from within the ranks of IT. More often than not they’re in charge of some archaic system that they’ve managed to hold together thanks to various “tricks” they’ve learnt over the years but should something that they’ve never encountered before happen they’ll instantly throw the towel in. Whilst I’m usually able to perform some impressive CYA maneuvers to ensure that all blame for an ensuing mess is placed on their shoulders (as it rightly should) it doesn’t stop it from happening in the first place, which is why I was consulting with them in the first place.

Thinking about this idea this morning I came to conclusion that it was in fact our education system that was to blame for these people. You see much of the core curriculum is based around rote memorization and regurgitation. Very little is dedicated to developing critical thinking and fact checking, meaning that for the most part people are trained to operate in a very set way. That means that when thrust into the workplace people who have a high level of memorization for certain things are usually held up as experts which, to a point, they are. However the problem comes in when the unexpected occurs which, unfortunately, falls to me when its related to IT.

There’s also that nasty social aspect that comes into play. When you’re considered an expert on something you don’t want to admit you don’t know something about it. You can usually pick up on this though as the answers to tough questions (like “is this license tied to IP?”) are met with vague answers peppered with shoulds, coulds and I think so’s. Usually a scapegoat won’t pretend to know something they don’t (since they’ve got nothing to lose usually) and it’s precisely why I labelled the second type the dangerous idiot. Their answers could very well lead to everything falling in a crying heap.

I’d love to say that this problem was confined to the public sector as well but unfortunately its not. Many of my friends who’ve worked in some of the smaller IT consulting shops have told me they’ve been forced into the role of the dangerous idiot because their company has marketed them as such. Granted I’d trust them more than I’d trust any other dangerous idiot but the fact remains that they were trotted out as an expert in things they may have never touched before. The private sector isn’t immune to legacy systems either and with them comes many of those not-so-expert experts.

Maybe I just have a low tolerance for this sort of thing thanks to the not-so-closet skeptic that’s been cultivating in me for the past year, but it doesn’t seem to be an isolated phenomenon. I guess the only thing I can take away from this is that I shouldn’t trust any expert wholly and make sure that I’ve done enough CYA work to ensure that should everything blow up in my face the blame is squarely levelled at the experts. Still it won’t stop me from bitching about it every so often, nor using other people’s idiocies as blog fodder 😉

¹I actually studied under Bartnik for a semester. It was both awe inspiring and completely confusing, I did however learn a heck of a lot.