methodology

It’s all about methodology

It doesn’t matter if you’re trying to understand why the server has EventID XXXX in the system log, it doesn’t matter if you are trying to identify what process is somesowftware.exe that is crunching your memory, it doesn’t even matter if you’re trying to understand what the user on the phone is trying to say while shouting on the phone “This thing doesn’t work!”. It’s all about methodology, once you have your consolidated path just follow it and this will lead you to the solution.

I’ve just changed job position, before I was an IT overall and I was working on development of vertical solutions for an ERP, design and management of Active Directories, end user support and so on; now I’m a Technical Support Engineer Level 2 and handle specific software’s issues by solving or escalating them. In both cases I do solve problems (Winston Wolfe!!!).

Whenever you have someone or something that shows you a problem always remember:

1. Listen what the problem is
2. Most of the times the user/customer doesn’t even know how to talk about the problem, keep on listening and try to catch the more information possible even if they are said in Aramaic
3. Have every logfile, screenshot or error description that you can from the user/customer
4. Try and reproduce the problem in your labs and try to understand who/what is the culprit
5. Research possible solutions on the internet, knowledge base, co-workers etc
6. Document everything like if you are talking to dummies
7. Solve/escalate the issue

This is my personal path and up to today it took me out of several problems. An example is in this new job position where if I don’t know yet the software I’m providing support for I’m providing support to customers and finding solutions to their problems or simply finding the right person to escalate the problem to.

As I said, it’s all about HOW you do it, sometimes it may be WHEN you do it but remember to seek your personal path and you will have your work done.