Leadership

Even Super Techs have limitations

Managing tech support expectations can be tricky when you are a generalist. Most small business techs are not in-depth specialists on all the software products that are used in their companies. There's no way we can know everything there is to know about all of them. But our co-workers don't know that. How do we manage this?

Am I the only one who puts tech support into two different categories? As I see it, there are generalists and there are specialists. Like many of you, I am a little of both. I know what I know about computers and I think I know what kind of knowledge is specialized. I have people that I rely on for that specialized support.

End-user or client expectations when it comes to “computer stuff” can be a tough animal to manage. To some of our co-workers or clients, all computer knowledge is specialized. They don’t recognize when they are asking a simple or a complex question. To them, it's all complex. They just want their problem fixed.

Installing vs. supporting software

I currently support a couple hundred employees in the Small to Medium Business where I work. If you are a tech support generalist like me in this kind of environment, then you have probably installed dozens of various kinds of software packages over the years. Most software installation tasks today are easy.

Now just because you know how to install a piece of software, doesn’t mean you are an expert in knowing how that software works. Am I wrong here? This is the point of my little rant. I sometimes get a little irritated at co-workers who don’t distinguish this. But because I'm a professional I don't show that irritation. Hah!

AutoCAD is specialized knowledge

Twice in my career I worked for manufacturing companies that had dozens of engineers who designed parts using AutoCAD. If you know anything about AutoCAD, you know it is a complex program. It can even be a bit complex to install for an experienced tech. You can go to school just to learn how to install this product.

I considered it part of my job to know how to install AutoCAD and so did my managers. But neither the engineers nor I ever assumed that I was the expert in AutoCAD. I know some of you are, but that’s not my area of expertise. I have too many other products to support, some of them almost as complex.

Managing end-user expectations

It’s always an opportunity to increase your knowledge when someone asks for support on a product that you don’t know in depth. Because of this, I have learned more obscure things about Microsoft Office products than I ever would have discovered from my own everyday use. That knowledge comes in handy.

Since we’re paid to provide tech support I suppose we should just dig in and figure it out when we’re asked something that might be considered specialized knowledge. What do you think? Am I off-base here? Is it ever OK to say, “I don’t know that product?” Yes, it is, as long as you add, "But I know someone who does."

Defer to the specialists

In particular, what if you are asked how to do certain functions in an accounting package and your knowledge of accounting procedures is limited? In cases like this I am glad to be able to call the company that sold and installed the system. They are all CPAs and know much more about debits and credits than I ever will.

Even though I am a network engineer, I have other engineers that I call when I need help. There's no way I can know all the ins and outs of the Cisco IOS. I just don't install that many routers, firewalls or switches. Most server issues I can handle but I still like to bounce things off another engineer in certain situations.

Tech of all Trades

Back to the point of this essay. A small business usually can't afford to have more than one or two techs on staff. In fact, some of them have none. They rely on outside consultants to support their computers and networks. So that one tech becomes a Tech of all Trades. Hey, that's the title of my blog!

I contend that it takes a special skill to be a Tech of all Trades. We have the added challenge of knowing how to manage user expectations of support that go beyond our own knowledge base. Educating your co-workers or clients about what knowledge is in-house is an important part of doing SMB tech support.

15 comments
dogged28
dogged28

quote: "???I don???t know that product???? Yes, it is, as long as you add, ???But I know someone who does.??? end quote. I usually add to that or state "I'm aware of that product and I'll look at it and see what I can do. If I can't get it then I'll find someone who can fix it or call them and get their help." Unfortunately in the private sector this is where you sometimes lose money even though you've stated honestly your limitations. Atleast for me anyways because I'd feel too guilty if I charged full price for failing to fix an issue. But that's okay because as you've stated I've learned something new about a product and about myself.

skrying
skrying

I am not above saying, "I don't know," but there are also times where I instead may say "Let me research that for you." (and that's when I find my friend Google, or use a co-worker as a reference to find a solution, and then follow-up as soon as humanly possible). Is this just another way of saying the same thing?

tmalonemcse
tmalonemcse

As much as I hate to admit that I don't know everything about all the products I support, it is just part of the job of being a generalist. I wrote a nice rant or essay about the subject: http://blogs.techrepublic.com.com/techofalltrades/?p=148 If you are a tech support generalist like me, then there are occasions where you must tell the client or co-worker, "I don't know." What is the right way to handle that?

jdmercha
jdmercha

There are several other things you can say that mean the same thing, but sound better. I need to get something back at my desk to fix this problem. I need to check with another tech to make sure we are doing the same thing about this problem. I don't have the time to fix this problem now, can I come back tomorrow? This is a two part problem, I need to fix the network side before I can fix the desktop side. I need to double check the solution before I try it. I need to do some more research about this problem.

Mycah Mason
Mycah Mason

You obvously need to be tactful in your use of IDK. As a personal rule, I generally don't say "IDK", not because I'm too proud to say it, but because I need to maintain my reputation as a person who HAS the answers. After all, that is my job. Rather than telling a person "IDK", I tell them that "I need to look into it." or "I need to research that." This gives me the opportunity to go find the answer to something I don't know and doesn't leave the customer feeling like I don't know how to do my job. I usually reserve the IDK response for the person who is really pushing for an immediate answer that I cannot give them. I think that by doing this you teach people to respect your IDK answer more and maintain the reputation of always having answers. There is definately a balancing act between tech knowledge and customer satisfaction.

mjd420nova
mjd420nova

Not a day goes by that I don't learn something, most often without using that phrase "I don't know". But I have had to use it a few times. There are a large number of tech web sites that I use to look for answers to some of the strange problems I run across. Using I don't know is always followed by "But I will find out" and this always serves to give the customer/client hope and continued faith when I do find the answers to the problem. I have a list of valued inside contacts for many manufacturers that will guide me to other contacts and inside technical wizards that have yet to fail me with some really obscure problems. The biggest problems I have run across have not been with hardware but with software and there things can get very sticky. With so many interactions and installation variables on so many different platforms, these will provide some of the most difficult problems that often are hard to duplicate and even tougher to diagnose.

Tony Hopkinson
Tony Hopkinson

it gets easier with practice. I don't know now. I will know when and god knows are the follow ups. If you are working for a company where this is a bad thing to say, leave.

billbohlen@hallmarkchannl
billbohlen@hallmarkchannl

Being a "computer guy" for 15 years now, I've had to say the humbling words "I Don't Know" many times in my career. Not only my career, but also all of the techie stuff that follows me home...friends and relatives who depend on me to help them through all of their computer problems. The key is knowing where to look for the right information. There is a 90% chance that someone else has asked that question or has encountered that problem before. And more than likely someone has posted the answers on the Internets. So say "I Don't Know" with pride, then plug a few search terms into Google.

dave.schutz
dave.schutz

My company has several software packages purchased from outside vendors and I get asked questions about software issues frequently. I think it's impossible for a small IT shop to know how everyone's software works on the business side. I can install and troubleshoot most problems, but I call the vendors when the software does not work. That's why we pay for support contracts. You have to know what you're good at and when to call for help.

tmalonemcse
tmalonemcse

There is the key phrase that many overlook. I too like to find answers. By your comment it appears that you have built up a large source of answers. I think we all do that. Because I do like to find the answers, I tend to take on a lot of those obscure requests. It brings a feeling of conquest to be able to come back with the answers in good time. Have you ever had one of those days where the requests for answers comes fast and furious? Managing a stack of unanswered questions can add pressure to any tech support job. Sometimes the FIFO process gets reversed and LIFO takes over. Even worse is when there is a more urgent question in there that impacts the normal flow of business for someone. And of course, when the queue gets too large, the important but not urgent questions don't get the priority attention they deserve. We need software just to track the requests. Managing tech support is easier and yet harder as the knowledge base grows. I have said many times, "I knew the answer to that once. I know it's in here somewhere." I don't know. Managing the support function is both a science and a talent. It's an art. Thanks for your comments. "Hard to duplicate and even harder to diagnose." I like that.

tmalonemcse
tmalonemcse

I have come to respect your succinct wisdom, Tony. Thank you for the focused comments. Opportunities to practice saying "I don't know" are becoming more frequent as I deal with upper management. I don't like that. It is only a bad thing to say because I have rarely had to say it before in areas where I have expertise. I have delivered correct answers consistently when asked about tech products that I know and use regularly. Most of the things for which I have to say "I don't know" these days involve requests to solve business problems, not technical problems. It's an uncomfortable area for me. The company is good, the skill is new. I will continue to practice.

tmalonemcse
tmalonemcse

Google has led me to a multitude of answers on a wide variety of tech problems. Some say that Google is a god. Google is my friend. But Google can't help me when the question is something like, "Where did my file go? I saved it like I normally do. Now it's gone." I'm OK with saying "I don't know," but there is the underlying unasked question, "How could this happen? Is the system broke?" It's just one of those things we all deal with. There are some questions that can't be answered without implying incompetence. In a case like this, I try to get them to replicate the problem. Sometimes it's just a training issue, an opportunity to help. I still don't like having to say "I don't know," but the next time the question comes up I'll be able to help that person. Hopefully there are not too many "I don't know" situations in a given day. That can be overwhelming even to the best researchers.

Tony Hopkinson
Tony Hopkinson

answer and don't have do do any thinking. They are either adding 2 and 2 in base 10, or guessing. I'll have to go away and think about it is a good answer, as long as you do, think about it. Any fool can come up with the wrong answer quickly, being forced to do something quickly usually makes us look like fools... The only think I would suggest, is time to think about it, isn't time to dither, or cross your fingers and hope it all goes away. They are more complex and a little harder to work, but they are still how to get from where you are now to where you want to be in achievable steps. I 'program' them, some manage them, some trouble shoot them, model the problem witn the tools you use best. Just remember the map is not the territory.

CharlieSpencer
CharlieSpencer

can be made more acceptable by appending, "No one has ask about that before." As a generalist, you need to develop the reputation of not necessarily having all the answers immediately, but of being able to supply them in a timely manner.

CharlieSpencer
CharlieSpencer

"Where did my file go? I saved it like I normally do. Now it's gone." Has anyone figured out a polite way to say, "Well, obviously you didn't save it like you normally do, or else it would still be there." Seriously, how do you reply to a user when the problem is clearly his (unintentional) fault?

Editor's Picks