The other day I was called in to assist with issue that had been open for a few days. The primary reason for my involvement was to confirm network connectivity was permitted as required by a recently installed application. After an initial look, it was apparent that the application wasn’t even trying to access network resources and the error referenced a configuration file. This happened to be one of those typical situations where no one really understood the application and the vendor had been involved for a while.
Like any curious geek, I began poking and prodding one of the configuration files to see if I could see anything obviously wrong for our particular environment. During this entire process, the application vendor’s support technician was watching via a WebEx session. When I started asking questions about the file, the technician proceeded to tell me the file was fine and that it had been part of the install package for years now. Since the application was just installed, the file was not the issue.
The file itself wasn’t my point of concern. The file contained references to variables that happened to be the path to some database files. Those files were also in the error message that we had been seeing. So I wanted to understand how the application derived the path variable that was in the configuration file and accessed the database. I hoped to use this information to confirm the pathing from the system standpoint.
After several rounds from vendor support of—“It’s not the file” and “This is a simple application that just works”, my team became quite frustrated. Vendor support for the application seemed to have no idea how the application functioned or how to troubleshoot it in the cases that it doesn’t work. I think the support technician finally chatted with a colleague in the background. Even though he had watched the application be reinstalled a few times, the technician wanted to do it once more. This time, he changed the installation path from the default location to a folder that housed a companion application. Voila, it worked.
The short story is that we had a supposedly simple application that should just work. When it failed to work, the support technician explained the simplicity of the application while demonstrating their lack of knowledge and ability to make it work. This deficiency came in the form of not understanding the installation process, not understanding the configuration of the product, not understanding the product operation and having little ability to understand or facilitate any required troubleshooting.
There’s absolutely no shame in not knowing the answer to a question or having to escalate a problem to someone with more familiarity with the product. What is frustrating is continually trying the same thing with some expectation of a different result. I also find it frustrating when you deal directly with an application vender that has large knowledge gaps regarding their own products. I can cut an individual technician a lot of slack if he or she isn’t representing themselves as an expert while demonstrating their lack of knowledge.
At the end of the day, those of us in this field will have to work with these types of situations. Those who have a complacent mindset will likely (and often) be recognized for the wrong reasons. It’s much better to dig deep and understand how the products you support work. When you determine that something solves a problem, dig deeper. Ask yourself, “Why does that solve the problem?” Sometimes, that leads to even more questions. The deep understanding you will gain combined with the fact that you are serious about learning will certainly help in your day-to-day work. Applying this technique over time as your role changes will lead to deep and broad knowledge that will certainly benefit you achieve your long-term career goals.