Objectivity is the name of the game

As a technician, I'm forced to use many different products from many different vendors every day. Whether I'm deciding to recommend Veritas or BackupAssist to a client, or whether I'm going to be remotely connecting to a computer using DameWare, VNC, or Remote Desktop Connection, for any given problem, there can be quite a few solutions. One of the problems I see with technicians today is the rampant 'fanboyism' that seems to be entirely too common.

What do I mean when I say 'fanboyism'? Well by that I mean that there are people out there who line themselves up behind one company and will support it to its death no matter what happens between now and then. While this seems to be most common in the video card (ATI vs. nVidia) and OS (Windows vs. Linux/BSD vs. Mac) arenas, you can find these zealots in pretty much every facet of our society.

Why is this a problem? As a technician, your primary focus should be on your customer. Not your profit margin, but how satisfied you can leave your client. When you start following a certain company or product without regard to actual quality, you are putting your customers at risk. Risk of what? Risk of not having a superior product. It is a case of the blind leading the blind; they are blind because they don't know better, and you are blind because your judgement is clouded by a logo.

When you are making a decision for yourself, you should feel free to purchase or use whatever product you like; by living in a free country with a free market, it is absolutely your right. When you are purchasing on behalf of your client however, this is no longer your purchase, you are simply and intermediary between a purchaser and their product. Your opinions should stay out of the process unless specifically requested (e.g. if you're asked 'which of our options would pick?' then feel free to weigh in.)

If you have data that can back up your statement (e.g. 'if you goto website W, website X, or website Y and look at their reviews of product Z, you'll see that they unanimously agree that product Z is the superior product') that is great and there isn't a problem. The problem arises when people become so attached to a product line or company that they will recommend it solely on name alone, and not on the performance of the product. Just because a product performed great in the past does not necessarily mean that it will perform well in the future.

While I have no doubt that company N has served you well in the past, whenever you make a recommendation to someone else, they are trusting that you are recommending a superior product. To find out which is the superior product, you should be able to provide the research you've done as to why it's the best option. You should be putting yourself in their shoes, and wondering 'if I was this client, what information would I like to know about this recommended product?'

You won't always be asked to provide references. In fact, the times that you are not asked will probably outweigh the times you are asked about 99 to 1. Regardless of how often though, you should always be prepared to cite netural sources, and by that I mean if you're recommending a search engine to a client, citing a report from searchenginedigest.com is good, citing a report from googlesucks.com is not.

So to wrap things up, you are going to be trusted to make a recommendation to someone sooner or later. You can do the irresponsible thing and recommend something on gut instinct, or you can do the responsible thing and do your homework; find out which of your options is the best not because of loyalty, but because of respect for your clients.

Justin Smith
nexxai@gmail.com

The Zen of Research (Part 1)

This article will be the first in a multi-part series dealing with how to research issues using the internet, other mediums such as books or manuals, and other technicians. This particular article will focus mainly on using search engines as your first line of defense when faced with an issue that you may not be fully ready to tackle.

Inevitably, as a technician you are going to be asked a question that you don't immediately have the answer to. Whether that day is a week from now, or a year from now, someone will ask you about a technology that you just don't have a clue about and you will be forced to do some research.

The problem with research is that there are so many avenues you can take, yet it seems very few people know how to use the tools they have at their disposal effectively. Not to say that they aren't being used at all, but in my experience they aren't being used properly.

Now what do I mean what I say "they aren't being used properly?" Well for example, every technician I know understands that the internet is your best resource for 80-90% of any technical issue you're faced with; they know to load up Google or Yahoo! and that once they find their way around, they'll be able to find the documentation they're looking for. The problem is how they use these tools.

[NOTE]: For the remainder of this article, I will be using Google when I talk about search engines, simply because it is my personal favorite. These tips however are not limited to Google, and will work on the search engine of your choice.

The biggest problem I see with people using Google is the terms they use when they're trying to find documentation or any kind of information on it, really. For example, they know that a user is having printing problems, but they aren't quite sure what to enter in the magic text box that seems to taunt them on the Google home page.

Before we start searching, we need to get a few pieces of information:

- Have there been any changes since the problem first occurred?
This can be tricky as when you ask, you don't want to imply that they were the cause of the problem. A technician who was by their desk earlier who installed a simple word processing application may have inadvertently caused the issue.

- What hardware is involved in the problem?
If we use the broken printer example from above, this would include not only the model number of the printer, but also of the computer, how much ink is left, and how much paper is in the tray

- Are there any warnings or errors being presented?
This not only includes messages on the screen or display that might give you some insight as to the problem, but also any audible warnings (beeping, scraping, etc). Also, the lack of an error message in some cases, can be as useful as no message at all.

- How many people are affected by this issue?
This isn't as necessary in the research phase as it's more of a general troubleshooting question you should be asking, but it's good to have handy either way.

Once you've got the above information, you should be equipped enough to start doing some research into the problem.

How do you do that you ask? Plain English (or thereabouts). One thing a lot of people don't understand about search engines, is that they aren't incredibly intelligent devices. They give us the power to search the internet, but they don't really have any kind of intelligence. How does this affect you? Well, you have to understand that all a search engine does is go to millions (or billions) of webpages, and makes a list of every word found on that page, and then keeps track of where those words were found. It also keeps track of what words are grouped together more often. Knowing that, we can simply enter in keywords of what we know and it will search its own database for pages it found with the words you entered together.

Sounds simple, right? Well it is, but there is a bit of a catch. Search engines will typically only allow you to enter 10 real words (real words being any words other than common ones such as "it", "and", "to", etc.) so you need to be able to look at your problem and pick out at the very most 10 words than accurately describe the problem you're having.

Using the broken printer example above, let's say that there were no changes made to anything, it's a Dell Optiplex GX280 PC connected to an HP 3380 All-In-One printer via a USB cable, there is an error on the printer that says "Unable to Communicate with HP scanning software", and there is only one affected user.

Looking at that description, it can seem a bit intimidating but it really shouldn't be. My very first search on Google would be: "gx280 hp 3380 usb unable communicate" I'm sure the first thing you're asking is 'Why didn't you put the word "Dell" in front of GX280?' The reason is that 'GX280' is a fairly uncommon string and while adding the word Dell may remove a few non-Dell entries, it's not going to be significant enough to warrant it. 'GX280' is obviously a part/model number so it's pretty specific, however '3380' could apply to anything and as such, we want to make sure we're clearly defining it as an 'HP' product.

After running this search at Google, there are no results. Should this be surprising? Absolutely not; you won't always get the perfect search the first time. Now, you should start looking at your search string and figuring out what may too specific. My first removal would be the 'GX280'. At this point, I would be assuming that there are no known issues with those two devices and should be ready to accept that this is an accepted configuration.

After running a search of "hp 3380 usb unable communicate" on Google, the first reply is a forum post on the HP website with some troubleshooting steps and multiple possible fixes. This is a great starting point as forum posts are often frequented by users themselves, and while they may not be official support, they usually have some pretty helpful advice.

Being able to pick out only the most important words in a bunch of geekspeak may be difficult at first, it only gets easier with time. Just remember to keep as much detail about the problem in the search while not getting so specific that you end up excluding relevant documents from your search. Personally, I find it easier to run a search that's too specific and widen my search parameters from there.

In our next installment, I'll be speaking about how to use hard copy documentation to its maximum potential. I'll be explaining how to obtain documentation from the vendor, and how to use it without wasting anyone's time.

Justin Smith
nexxai@gmail.com

How-To: Speak to your client (Part 2)

As we discussed in part 1, communication is as big a part of your job as a technician as the technical know how. No longer are the days where the IS or IT departments are holed up in a bunker some 20 floors beneath street level, or put in a 3 foot by 5 foot closet and expected to never speak to anyone. As a current technician, you are going to be forced to interact with your users directly. Whether that means being on a SPOC (single point of contact) such as a helpdesk or technical support line and speaking to the users on a regular basis, or being a second/third level technician who needs more information about an issue and must contact that user, you will be speaking to someone outside of the IT department eventually. How easily you can adapt your conversation to the user's knowledge level will determine how much confidence the user will have in you, as well as what kind of leeway they will give you should the resolution take longer than expected.

This article focuses on the soft skill (or people skill) techniques you can use to communicate more effectively with your client which will let you focus on the more technical part of your job. We will go over things like how to determine your user's technical competency, how to explain issues to a non-technical person, and in a forthcoming article, how to politely refuse a client's request.

Before you even begin to think about explaining an issue to a user, you must first determine their technical competency. By jumping the gun and explaining in minute detail how a particular server's file system crashed to a non-technical person could make that person feel inept or stupid which could lead to more problems during the duration of the issue, and conversely, telling a technically-inclined person that 'the smart TV box needed a nap' could invoke the reaction by the listener that you are the dumb one. So, the question you're probably asking is: 'How do I determine what a user's technical competency level is?' Unfortunately, this is something of a soft science and can't be precisely defined. There aren't any hard and fast rules to determine how skilled your user is, but there are some things you can listen for that might give point you in the right direction:

- Does the user seem to be forcing you to do all the work?
Example: You're asking them to do something simple like a few mouse clicks and they still want you to come to their desk and do it for them?

This could be because the user just doesn't feel comfortable doing something that they haven't done before. I know personally, if I'm learning a new procedure, I like having someone watch over my shoulder the first time I walk through it, just to make sure that I'm doing it right. If I can get through it with nothing breaking, I'm a happy camper and won't have any problems doing it again by myself. The user may find themselves in the same boat: they want to have someone watching over their shoulder to ensure that they aren't causing any more problems. Now this doesn't necessarily mean that this person is completely green, but if you have this request multiple times from the same user, a little light should go off in your head that this user may not have the skillset you do.

On the other hand having a user that really loves to work the KB and mouse does not indicate that they are either competent or willing to learn. I've often experience this as a power user wanna be. A very dangerous position to be in, this user often has lots of questions and seems to know the lingo. It will take some time to determine if the user really is on the ball, a statement like "Should I reinstall the TCP/IP stack?" clearly shows that someone has learned to do something but doesn't really know what it does. In case you aren't sure the answer is always "NO" if the TCP/IP stack needs to be reinstalled, you do it and NOT in front of the user.

- Does the user say the word 'thing' a lot?
Example: 'That computer-thing is making a lot of noise?' or 'The thing I just clicked on went away.'

99% of all people have an innate desire to show off/brag/etc. as often as possible. Why does that matter? Because if they knew the term, they would use it to try and impress you (or perhaps simply themselves). Instead, the user is trying to let you know that they are manipulating a certain object but don't know how to explain or describe it any better. Hearing the word 'thing' a lot usually gives me the impression that the person does honestly want to help you help them, but don't have the know-how to do so.

As well as I touched on above, a use of correct technical terms is not a clear indication of capability either. What you are really looking for here is more the ability of the user to articulate and be comfortable in their environment. You may have a user that says "I'm using program and trying to process when I get error." This isn't proof that the user knows what's going on, it simply indicates that the person can explain things to you accurately.

These are just two of millions of subtle nuances you should be listening for when speaking to a client explain an issue; little hints that should give you a fairly good idea of what kind of person you're speaking with. You have to remember that you shouldn't only be listening to what a user says, but also how they say it. Like you probably know, something like 70% of face-to-face communication is through body language. Why does that matter? Because even if you're not face-to-face with your user, you can still hear different movements. I know that you're probably thinking that I'm crazy, but the next time you're on the phone, I bet that without a doubt you could at the very least be able to tell if the person you're speaking with is smiling. That's a physical action, but it's incredibly easy to pick up on if you actually listen for it.

The next question I can hear you asking is: 'Alright, well now that I know my user has a [terrible/alright/excellent] technical background; what do I do with this information?' You want to take this information and tailor the rest of your conversations to their skill level. The reason you want to do this is that, as we discussed earlier, you don't want to go over your user's head because they'll just end up zoning out and not listening to anything you say and you also don't want to patronize someone who does have the knowledge. If there is ever a case of doubt, you are better off assuming that the user does not know or is not interested in knowing and you should reveal virtually nothing about the situation.

You want to be able to keep your listener interested throughout as much of the conversation as possible, so when you're describing things to a non-technical person don't go overboard on the details. Instead of saying something like 'the software's internal development team didn't use the strongly() function and so there was a stack overflow and the core dumped', say something like 'there is a problem with the program and there is nothing you could have done, the best thing you can do if you come across another problem like this is contact us'. Most people aren't going to care why the program broke, they're just going to want to know that someone knows it's broken; how it gets fixed generally won't concern them. As the saying goes, 'Ignorance is bliss.' Like most people who don't care what goes on under the hood of their car, they just want it to get them from A to B, most people don't care that the page file needed to be moved to a different drive and that the RAM was upgraded from DDR to DDR2, so long as they can still save their Word documents.

You want to use the vaguest terms possible, I would advise that you not provide any at all while still maintaining the essentials of the resolution. You don't want to lie about any details, but by going overboard on the specifics that are more than likely going to fly over your user's head anyways, you're just wasting both your and their time. It is best to say 'The issue is fixed now, if you or anyone else in the office has this problem again have them contact us right away.' You can also use analogies, but be sure to use a pre-planned analogy, and not something on the fly. Why pre-planned? It's because if you realize you need to change something halfway through your explanation, chances are high that your user will already have assimilated the first part, and will have an incredibly difficult time remembering something different. The whole reason for using an analogy is to link a familiar mental picture to something new, in the hopes that they'll remember it. An upcoming post will contain an excellent example of an analogy that should be used whenever possible, watch out for it.

To end off this article, I'd like to leave you with one more helpful tip. You are eventually going to have people who, after you've fixed a problem and explained the solution in layman's terms, ask for more details. The big conundrum here is how much detail do you go into? My answer is to let them know that any more explanation is going to be highly technical and might not make any sense. At this point they can make up their mind with whatever they feel comfortable with, and with either decision, you win. If they decide not to have you go further into detail, this will allow you to get back to your other awaiting work, and if they ask you to explain it to them, chances are that you might have underestimated their technical skills, and/or they really are eager to learn. I personally really like it when someone asks me to explain the technical details, it gives me an opportunity to speak in my native tongue (Geek) and not apologize.

Always remember the most important tip of all: enjoy yourself if you can; the moments where the crisis is averted and you are the hero are the moments in which you get to enjoy your professional pride. Take pleasure in the fact that at the end of the call a client who started off angry is now happy with your work.

Justin Smith
nexxai@gmail.com