Professional troubleshooting is what we call the third key for our HCLSoftware support team. What do we mean by professional troubleshooting? It is quite simple: finding a balance between “proving yourself right” or “proving yourself wrong.”
We strongly believe that you, our customer, expect the technical support engineer you are working with to be a troubleshooter. When you scream “help” you expect this engineer to help you. When your server “crashes” you expect this engineer to help you overcome that crash. When the application is not doing what it is expected to do, you require this engineer to help you overcome that gap.
A swimmer that screams “help” is asking someone to pull them out of the water. The onlooker does not have to think before taking action to solve the problem: Jump in the water and pull the swimmer out!
Troubleshooting a tech issue can be compared to a doctor assessing a patient. A patient that visits their General Practitioner with stomach cramps, except for maybe some pain killers no immediate action may spring to mind. But should those cramps not respond to treatment or get worse, then some diagnostic questioning needs to be done. When do the cramps happen? What is the intensity? Where is the pain? Some tests may be performed to understand the exact nature of the malaise.
When you have an application “hang,” the initial response of restarting the application could seem simple and effective. It might also be very costly due to potential data loss. A second similar “hang” in the future could make you think twice. Do I need to do a root-cause analysis? Depending on the cost and the frequency of the hangs, a root-cause analysis might be the appropriate step.
Depending on the situation, we might need to “jump into action,” do some basic tests, or do a deeper analysis. All might be relevant and necessary, depending on the circumstances. At HCL Technical software support, we will work with you to identify the required approach and recommend the appropriate action.
In a series of blogs, we have been discussing HCLSoftware’s philosophy of professional troubleshooting using a series of medical analogies.
Like it or not, we all have experience with doctors. Imagine yourself sitting in the consultation room explaining the symptoms of an unknown condition. Through your explanation the doctor works to get a proper diagnosis and treatment. If you pay attention to the doctor, you will probably notice a methodology behind the questioning. “Where is the pain exactly?” is asked to understand the precise location. “When did the pain initially occur?” is trying to establish a timeline. “Is the pain getting worse?” aims to assess trends. They are trying to get from the general — ‘”I have stomach pain” — to the more specific: “My stomach pain to the right side of my tummy just below my ribs, appears suddenly, a couple of times a day, and I have had this for the last 3 months.”
Just like in assessing someone’s illness, in assessing what needs to be resolved in software support words and methods do matter. The two authors of this blog recently had to accompany family members to a hospital.
Says one of the authors: “The thing that struck me was the apparent lack of verification of one doctor when taking over from another. The surgeon who was asked to take out a gall bladder did not seem to care about the ultrasound scan that indicated a gall stone. He was focused only on his task: take the gall bladder out. He seemed to have little interest in the context of that task.”
The surgeon might be comparable to a developer that fixes defects. If the ask to this developer is to fix defect x or y, he will probably just do that. In this analogy, the sonographer is the debugger.
However, it would have been emotionally expensive for the patient if the analysis had been incorrect. Where a GP connects the dots between the medical specialists, the support engineer does a similar job in the software world.
The other author tells us: “One of the things that struck me about the medical team assisting my father-in-law was how well they collaborated; bouncing ideas off one another, questioning each other, even questioning superiors. They were frequently ruling out theories — “the blood tests rule out that diagnosis,” “How does this diagnosis explain that symptom?” and “The x-ray doesn’t rule out another, let’s get a CT scan.” The team spent much of their time eliminating what was ailing their patient.”
Here is an excellent video from Derek Muller’s Veritasium channel illustrating the power of proving yourself wrong.
Through our partnership with Kepner-Tregoe we teach our technical support engineers to recognize when action or analysis is needed. We teach them how to use their experience and intuition but also how to question their assumptions. To trust professionals when trust is warranted, to question if there is a slither of doubt, but also to prove themselves wrong before acting. In essence, to be professional troubleshooters.
How do you prove you are right? By removing the gall bladder? Quite an expensive and emotionally loaded test approach! In our software world we might not have to remove gall bladders, but a full reinstallation or a complete upgrade could be an expensive and time-consuming operation as well. Since taking action might be expensive, in many situations you want to think before you act. This cautious and considered approach is what we try to put into practice at HCLSoftware support. So, we can all say “Boo yeah! Up top! We nailed it!”
PS: You can read about
The “three keys” to HCLSoftware success here,
the “first key” here
and the “second key” here.