Organisations of a certain size employ IT people and harness them into a role. Those people take on the mantel of the role, learning whatever script that has been put before them. As long as the problem doesn’t deviate from the script then they effectively resolve problems.
However no plan survives contact with the enemy, and in IT, that enemy is the combination of unique circumstances that can add up to a symptom that looks like problem A but turns out to be problem B.
If the newly ensconced IT engineer has got a some small modicum of learning under their belt then they can sometimes falsely assume they know the answer to something and not fully investigate the support call and then give nasal decongestant to an amputee so to speak.
I recently had an interaction with my hosting provider which demonstrated what an acquaintence called “Classic Inexperienced Engineer Behaviour”. I was getting intermittent mysql connection failures. The engineer that handled my support request said “I’ve regranted permissions to your users to your databases” and “the problem is fixed”. I replied that a grant issue on databases would be indicated by it either it working or it not working when repeating the same operation, but my mysql problem was intermittent.
So another 2 days go by and they have had the long awaited Eureka moment and are now investigating “network issues”. My point being—if a 1st level engineer can diagnose correctly and early then the problem can be escalated to the top of the support tree where remedial action can be taken and hopefully with some speed.
Sadly a 1st level engineer that can diagnose correctly and early, will probably be moved to 2nd or 3rd level leaving the next generation of 1st level people to annoy their requestors with tardy mis-diagnosis and mistakenly assuming all users are idiots (a large percentage are but… that’s another story). Users aren’t necessarily stupid, they just don’t know how to describe the problem to the satisfaction of the engineer. Add to this situation a web based job submission system that gives zero interaction between the requestor and engineer and you get… an engineer fixing something that isn’t broken because of having to make assumptions about the problem, and a requestor who is frustrated by the problem not being resolved.
Back to the scripts… These are put in place because engineers can’t be trusted to make intuitive leaps to the answer all the time, sometimes they miss simple basics that could resolve the problem (I have done my share of head slapping because of forget the 3 R’s of Microsoft IT. Reboot,Reboot,Reboot). But the scripts also take the user through, in their mind … “useless steps”.
So how do IT people bridge the gap between plodding script following and intuitive leaps that take them straight to the real root cause of the problem? EXPERIENCE.
I think good support engineers that progress have many attributes. Here is a small list that I have written as a prompt for the time next I have to interview a candidate.
- They will learn away from work, anything and everything about their work
- Detail focus. Asking the right questions. Filtering and sorting the important from the inane
- The ability to infer from limited information what the support request is really asking
- The ability to ignore irrelevant details. During a major outage everyone is ringing with their little stories of individual woe. You don’t visit a desktop when you know the cause is a back hoe cutting the cable down the street
- An interest in system architecture. Understanding the structure helps when you have to fix a part of it
- Go beyond the framework of the call. Fix, repair, tidy. Continuous improvement
- Caution – Before every action assess the risk and only act deliberately. Haste causes mistakes
- Ability to sandbox problems. Virtualisation means you can model complex environments on a single desktop do it and learn
- Use Google, support.microsoft.com, ubuntuforums.org. While it can be fun staring at your navel. Navel gazing doesn’t help resolve problems when you are at the limit of your knowledge. Someone somewhere has probably had a similar issue. Find that needle in the haystack!