Troubleshooting doesn’t sound glamourous. Most people think it’s just something you do as part of a job. It’s taken for granted. There are more important things like KPIs and deliverables to think about. Troubleshooting is simply not a thing, not something you think to excel, like as if it were a skill.
But is it not actually quite an important skill? Something that is needed to do a job well? Something that is applicable in many areas of life, and not just something in a technical and engineering related job?
I am ranting because this art of troubleshooting seems to be getting lost. We have people who are supposed to be technically competent, but that is only what it appears to be on the outside. Throw a spanner in the works and everything breaks down. They are unable to work. They need step-by-step guidance. If it is not in the book given to them, they don’t know what to do.
These are people whose competency are built on guide books, or being able to Google tutorials and how-to recipes. Good if Google gets you your answers.
I don’t doubt the usefulness of Googling for answers. That, in itself, can be quite a skill. But what if Google doesn’t have your answer? Can you still do your job?
The challenges we face in some technical jobs are often unique enough that Googling for answers may not be productive. You’d be lucky to find something relevant. You should be worried if your job is made up of Googling, or can be replaced by Googling.
For the real jobs out there, you’d find you cannot rely and depend on Google too much. I’m not saying Google isn’t helpful at all, but you certainly don’t get answers handed out on a platter.
To bring in an different nature of job to use as an analogy, consider that of a medical specialist. Is it not his job to troubleshoot your ailment to help you get better? If you have a medical condition that is so easy to diagnose and treat, you needn’t see a specialist doctor. A general practitioner would have sufficed. You might have heard, general practitioners are in danger of being replaced by AI. There are people who go to Google instead of seeing a doctor.
Good troubleshooting skills can be important enough that it’s possible that, even without specific domain knowledge, one can still “fix” problems. Recall the problems with Circle Line signal interference which caused significant train service disruptions in 2016?
GovTech did great work solving a problem with the MRT, when the operator, the manufacturer, and LTA themselves were all stumped. Think about that a moment. The people who run the trains on a daily basis, the people who built the system, they couldn’t solve the problem. Quite amazing that an outside team can do it? I wrote a post about troubleshooting with data back then.
I’m not asking anyone to go solve problems not in their domain of expertise. But, at the least, don’t be an embarrassment to your profession and field of work by being completely inept at troubleshooting problems in your area of expertise?
What GovTech did was to troubleshoot the MRT problems with data. There are many types of troubleshooting. For example, you can troubleshoot by trial and error. Most people know and do this. When any piece of simple consumer tech gadget doesn’t work, try pressing any button and see if it helps. Maybe just turn it off and on again.
This brainless kind of troubleshooting often finds its way into more complicated systems too. When I sometimes ask about the troubleshooting that someone is doing, the scenario plays out like this:
Me: Why are you doing this test?
Other: I don’t know. Just to try something and see.
Me: So what is the expected result?
Other: Not sure. We’ll just see what happens.
Me: So what does it mean if something or other happens?
Other: I don’t know.
Me: Then what is this test supposed to show?
Other: I don’t know.
So the test is just a waste of time. You don’t know the purpose of the test, and you don’t know what to do with the test result. You’re just doing it to appear busy, to make it appear like you know something. It doesn’t matter if you’re getting nowhere. Well done.
Imagine you are flying on a plane. (We all miss flying this year, but just imagine.) There is a problem with the aircraft. The pilots are just going to try random things in the cockpit to see if those random actions will appear to make the problem go away. I know they have checklists, but if a problem is not in the checklist, and the pilots’ only resolve is to do random things, we have a serious situation.
This starts to sound funny when I use that analogy. But such a scenario is not uncommon. (Though, fortunately, I think that’s actually uncommon with flying planes.)
For some people, such technical troubleshooting gets turned into an exercise in office politics. For example, make the problem someone else’s to solve. This helps hide the fact that they are totally clueless and incompetent. Many people are great at this. It is much simpler than doing their real job.
There is also another side of troubleshooting that I do: trying to figure out why something suddenly works, when it didn’t a while ago, although nothing was done, or nothing meaningful has changed. You see, some (maybe most) people, if a problem magically gets resolved, are happy to leave it at that. The problem is gone, they’ve no interest to know why. Perhaps they’re relieved that their incompetency did not come to light. For me, I’ll actually still puzzle over the matter just like before, except now to figure out why the problem is gone.
There has to be a reason why any piece of technology works, or why it doesn’t work. For something to magically not work, or magically come back to work, is not good, and deserves investigating.
However, most people troubleshoot only for the first part, to fix a problem, and then, often only to address the obvious symptoms, without getting at the root causes. They do what’s needed to be done, so that they can get on with other stuff. Troubleshooting just isn’t something they want to do.
View Comment Policy