After Hours

10 important lessons I've learned as a remote engineer

It takes a special kind of person to handle the remote support role. But for the right tech, the work can be enormously satisfying.

I've been doing remote support for quite a while now, and the journey has certainly been an enlightening one. At any given point, it has been an exercise in frustration, satisfaction, and humor. The biggest challenge to the remote engineer is that you have one added element between you and success -- the end user. For many IT pros, that's just not acceptable. Fortunately, those support personnel aren't doing remote support. It has been quite the learning experience -- one every young hotshot coming out of a comp sci program should have to endure. Why? Because, in the end, they'll better grasp the fundamentals of the desktop PC as well as those who use them.

What are the more important lessons to be taken away from being a remote engineer? Here are 10 you can read and live vicariously though my experience.

1: The lack of computer literacy is astonishing

It never fails to amaze me that there are so many out there who depend upon the PC to do their job -- while at the same time have zero knowledge of the tool. That is not to say they are completely bereft of skills or intelligence. But if you work at a PC all day, you should at least know how to enter a URL into a browser. I can't tell you how many times I've instructed the end user to enter a particular web address into a browser only to be asked, "What's a web browser?" Sometimes I want to respond, "It's the application you probably use day in and day out to do your job!" Either that or... "Think Facebook."

2: People want to get their jobs done

That's right, the one thing in the way of end users doing their job is the remote engineer. No matter how frustrating your job is, it is crucial to remember that the person you're trying to help can't do their job until you do yours. That means the longer it takes you, the less patient they will be. The less patient the end user, the harder your job will be. I go into every remote session with the understanding that the end user just wants to be able to work. If they can't work, they wind up staying late. And no one wants to do that.

3: Patience is the only answer

If you do not have patience, you should seriously reconsider doing remote support. I have spent hour-long appointments where the first 50 minutes were trying to walk the end user through just getting me into his or her machine and the last five or 10 minutes solving the problem. It takes a special hand to deal with that level of end user, and without patience, you are doomed to fail.

4: Occam's razor almost always applies

It's taken me a while to develop this approach -- but no matter the issue, I always start with the simplest possible solution, even if it's a reboot of the desktop. Often, the simplest answer will work, saving you time and saving the client money. That is a win-win. The client will love you for solving the issue so quickly, and you can move on to other end-user problems. Granted, Occam's razor doesn't always apply; but when it does, it's a real blessing.

5: There are times when you have to step away

It happens: You dive into waters deeper than you can handle or a problem continues to evade you. In those situations, it's always best to step away. That might mean putting the client on hold and catching your breath or telling the client the machine has to come into the office. A fresh pair of eyes or a fresh perspective could be all you need to get a win on this one. But it's important to know when it's time to put the mouse down and call it. And it's usually best to call it sooner rather than later. If you continue to struggle with an issue, you're going to wind up with an unhappy customer charged for your failure. Give yourself a time limit on certain issues. When you reach that limit, let the customer know that either you're going to have to come out and resolve the issue or the machine will have to come to your office.

6: Smartphone issues require special attention

I have a number of smartphones at my desk. When a client has an issue with a smartphone, I try to match up the smartphone I have that best suits what the client is using. With that, I can more easily walk through the troubleshooting process. And having the phone on hand allows you to better describe to end users what they should see. If you don't have a similar smartphone, you will need to rely on end users to describe, in detail, what they are seeing.

7: The more details you get, the better your chances

Even before you dive into the problem solving, you need to gather as much information as possible -- the more detailed, the better. Find out what end users were doing when the problem started, what they have done since, what the expected behavior should be, what platform they're using, any passwords they might have, whether they're connecting to a server, etc. There will be information you won't be able to get from the end user, such as IP addresses of servers, admin passwords, and router information. Remember, you have to set yourself up for a win even before you pick up the phone to call. Don't set yourself up to put them on hold just to gather information.

8: It's important to take notes (because the problem will return)

Remember that really obscure fix you used to solve problem X a few months ago? No? Well, it's returned to another client, and now you have to retrace your steps to solve the problem again. That is wasted time. Instead of finding yourself in this position, make notes of what you do to solve issues (unless it's a common issue). Doing this will not only make your job easier, it'll make it faster. In the world of remote support, efficiency is king. Go into every job with as much information as possible and your chances of success are much improved.

9: Not all remote tools are created equal

RDP is great for servers. But when you're dealing with desktop machines, you're looking at tools like TeamViewer or LogMeIn. Both of these tools do a great job of getting you into a client's desktop and even working with the Windows 7 UAC and multiple monitor setups and handling file transfers. If you're using anything that falls short in those areas, you are doing yourself a serious disservice. You might wind up having to purchase a full-blown support license for such a product. But it's worth it. Yes, some are costly, but they are a necessary cost of doing remote support.

10: You have to know when to call in the cavalry

There are certain instances when the only route to success is calling in vendor support. This is especially true when you're dealing with niche software that has zero documentation and is not a friend of Google. In that case, your best first move is to get the third-party support on the phone, remote them in, and let them handle the task. In fact, when a client calls in about their niche software, the first thing I ask is whether they have a support contract with the vendor. If they do, I'll tell them to call them first and if they can't resolve the issue to call me back. This helps save them money and makes you look like the good guy in the end.

Fulfillment

Remote support is a special beast that requires a special kind of engineer. It's not just about patience or a soothing voice. You must have a specific approach to the very work you do. After numerous years of remote support, I've learned that the position takes a certain kind of person for any level of success to be achieved. It's not the easiest path, but it has its own flavor of rewards that most in the IT industry would find fulfilling.

Automatically sign up for TechRepublic's 10 Things newsletter!

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

26 comments
jsargent
jsargent

If you are charged with supporting a turn-key solution (eg. POS applications) I don't believe it is acceptable to forward your customer to the OS vendor when he has paid you his hard earned cash to give him support. By all means when a problem cannot be circumvented because it is a bug with hardware or the OS, you can use an explanation from a vendor to justify your suggestions but you can't make the customer run around when he has paid you money for support for a turn-key solution. Unfortunately the cavalry for our products is a developer and, occasionally, when we have a problem he is required to justify the next action that should be performed using their hidden knowledge of the product and hardware.

aidemzo_adanac
aidemzo_adanac

I have a dead Harmony remote, judging by your title, II was hoping you could help fix it.

Cicuta2011
Cicuta2011

Although Linux can be installed with other computers besides PCs most admins using Linux work with PCs which brings me to computer literacy: 1.- most people treat Linux as an independent platform without realizing that it is another UNIX platform as it was derived from AT&T UNIX. 2. How about Solaris, AIX, Ultrix, HP-UNIX, SCO UNIX? Those platforms fall also under the umbrella of UNIX and is consider computer savvy for most administrators (computer literacy). 3. Is the computer administrator an engineer as most companies call them? My answer to the question is: If the person has not taken an engineering curriculum and have a university degree in engineering that individual is not an engineer. 4. Even a Windows certification does not make a person an engineer! 5. Do SysAdmins design computer centers? My experience tells me that they do not and it is also consider computer literacy. 6. Remote computer systems administration does not make an individual an engineer....Show me a university degree in engineering and then I can believe the person is in fact an engineer. 7. How about other applications such as databases?...that is also computer literacy. 8. How about NIS, NIS+, NFS, DNS, Ldap, etc.? The admin must know those protocols and applications as well in order to be computer savvy. 9. Remote administration is nothing different that in-house administration. The admin from his/her office remote log in into the servers even with PCs using Putty or other application.

EchoVector
EchoVector

"Is it plugged in and turned on?" Yes, I have actually had to ask that. And yes, I have been answered in the negative. Days like that leave you singing "God is great, beer is good and people are crazy".

CACASEY
CACASEY

Jack - If you are providing professional remote support to any organization other than the smallest of small business, you will have access, and be expected to use and contribute to, a knowledge base of issues and problems. Doing support work, remote or not, without such a tool means repetitive work at best and billing customers multiple times for "solving" a recurring problem. Knowledgebases are typically connected to ticketing systems (like CA or Remedy). One other point of note - For the past several years I have been recommending to clients that they invest a little time and money into training their employees how to use the help desk. Virtually no one addresses this primary quality driver and I'm convinced the quality and efficiency of support would increase by at least 50% if end users were given some basic instruction, versus a phone number or web/e-mail address.

Lawrence Garvin
Lawrence Garvin

To a notable extent, the first four items on this list all feed from the first. End users "just want to do their job", and this philosophy is a significant part of what feeds their illiteracy about the tool they use to do their jobs. But that really falls at the feet of the employer, who should have the expectation that a job prospect can use the toolset prior to hiring them. Imagine if a carpenter hired an apprentice that didn't understand the difference between a hammer and a drill, or worse, how to use each of them. Patience and simplicity are additional outgrowths of #1 and #2. If more literacy of the tool existed, a lot of the need for patience with end users would be non-existent and the simple solutions would be investigated and attempted by the end-user before calling a support technician. But then, these arguments are not new. I begged employers as far back as the 1990s when we were first introducing PCs into the workplace that there had to be a reasonable expectation of a core skill set among the PC users, or we'd spend exponential amounts of time supporting those users. Ultimately we implemented a policy (totally appropriate for Win v3 16-bit systems) that required the end-user to reboot their system prior to calling the help desk. We cut help desk calls in half, virtually overnight, merely as a result of implementing that policy.

Donu7
Donu7

Personally I also lump mail clients with smartphones (primarily because most of the smartphone questions I receive are also questions about email clients built into the smartphones) and I kill both questions with one stone: simulators. There are plenty of email and smartphone simulators out there that make troubleshooting and walking customers step-by-step a really painless process. For the most part, I have most smartphone paths memorized (it's pretty easy since the iPhone rarely changes in its major UI paths) but for just about every question I consult simulators to double check everything. My favorite site for simulators is chasms.com but there's tons of other sites/simulators out there that I feel it's worth mentioning.

info
info

...of the '80s and '90s. #9!!! Oh my GOD, NUMBER NINE... If we'd ONLY had remote control software as easy to use and comprehensive back then as is available now! Talk about a Godsend...

skootert221
skootert221

IT is so competitive and saturated that if you're fortunate enough to still be in the field, you must be fairly open about your value. It's essential for employees and management to see the services you provide and why you are necessary for the company to be successful. Always be patient, courteous, understanding, compassionate, and knowledgeable. You must forge trusting personal relationships with all if you want to continue a beneficial career.

OurITLady
OurITLady

Most vendor support does not like talking to you unless you have done all the basic troubleshooting steps first. I'd remote onto the machine and at least run through the basic OS troubleshooting to make sure the application should be able to run, maybe even check the event logs as well to see if the application is throwing anything up there. We have a number of less commonly used applications, it's a fairly quick job to make sure that the server for them is online, can the client ping it, is there a software clash with something they just downloaded, etc before you start wasting the time of the techs who support those apps.

Craig_B
Craig_B

Understanding the actual problem and not just want the customer told you. Many times the customer will say A happened so please do B, when this is not the whole story. Asking the right questions, so you are fixing the real issue is key. With that goes a basic understanding of what level of knowledge and truthfulness the customer has.

salnaib
salnaib

I like to work from home but I need your feedback how to start as one person and grow and may be open office later or stay as consultant as one person job. Any feedback would be appreciated. I liked your article. saad

douglas.gernat
douglas.gernat

So I've come across a handful of issues as of late that make the following information something to ponder over. Let's start with a question: At what point, while working on a problem, do you believe it to be resolved? Is it: A. The moment you make a change that has fixed the problem before? B. When one successful test has been performed from your workstation, phone, email address, etc.? C. When you get tired of staring at the ticket in your queue and decide it is no longer an issue of importance D. Any of the above In this lowly engineer's opinion, I see it as none of those. When you find a solution to a problem, the proper approach is to approach it as if it were going to fail. By taking this mentality, upon implementation, you will test the living daylights out of it. Once I have found a problem resolved, I immediately test it in as close approximation to the user's environment as possible (under their login, from a similar login, machine format, etc.). If this is successful, I usually follow up with the user directly and ask that they test it as though they would normally use the product. Once this is successful, I analyze the results for possible flaws. Let's use a real world scenario: A location was offline due to a power problem. We were properly notified, contacted the customer, who replied when power was restored. They replied that everything was up and running. Great, thank you friendly user for replying to us and telling us what we probably already know as we glare at our monitoring systems with beady little caffeine filled engineering eyes. Does this mean the problem is truly resolved? Not to me... Test one (Test for yourself): Let's go a step further. Let's check over our various monitoring systems to see any obvious issues. In this case, everything appears to be normal. But what do our systems actually monitor? They look at a series of ping tests, Service Statuses, and agent statuses. The aggregate of those we hope is a technology environment which the user finds, well, useful! Does a positive test mean that they are fully operational? Does it mean no future issues may be encountered? Not so much, its a point in time, we're looking through a loupe at specific components. Test Two (Test with the user): Let's make sure the user environment is actually working. Ask the contact to test all services such as voice, email (may have already done so), file shares, web browsing, authentication, etc. Essentially, any services that should be documented in their network diagram. There's your user test. Test Three (Test for your boss): Lastly, let's connect and get all nerdy on 'em. Once the first two tests are successful. Check latency and packet loss to and from the firewall. Everything normal? Cool, we have layers 1-3. Connect to the server onsite, check that all proper services are running (in Windows land, sort by startup type and ensure all automatic services have started). Crawl the system and application logs since the boot (can be marked by the eventlog service starting), anything in there? These are the things that make you shine. 95% of the time, all is well. But that one time you find an active directory issue just waiting to keep you up over the weekend, or a simple printing service unavailable, or perhaps a failed disk drive waiting to blow up, you'll be glad you were OCD about troubleshooting. With those 3 series of tests (adapted for the situation of course), I am generally confident in the resolution . I'll generally follow up once more to show the value of our professionalism with the contact on additional steps performed, and request a follow up if anything is out of line. Depending on severity, I might then do the same steps the next day with as little intrusion to the user as possible.

Suresh Mukhi
Suresh Mukhi

Been on both sides. Being remotely supported and giving remote support. I like being on the receiving end of support better. I can play dumb and "test" the support technician and see if they know what they're doing. :)

silvamayflower
silvamayflower

Thanks for this insight into something I have considered myself, having been on the other end of the phone for many friends over the years. I note that you are astonished at lack of computer literacy - I am not! But what is so annoying is the patronising adviser that seems to make up the bulk of those doing your job. First of all, if I am in Chrome or Firefox, I want to know why the adviser tells me I should open IE, and then gets into a flat panic when I ask if the above will do instead. Then they invariably tell me to 'type this into the long box at the top of your screen. This is called the address bar....' and equally patronising language. I have often had to say,' look mate, I am computer literate. Please don't patronise me and use proper language. I will ask you for clarity if I don't understand.' It's a big windup to me, and is what I call the 'lowest common denominator syndrome' - often displayed by the call centre dude who is totally thrown when deviating from his script. Horrible! Gives support a very bad name. Rant over, and thanks for a very interesting article.

Odysseus2012
Odysseus2012

On the spot! Great article, this author has been through it. I always struggle with my mobile users who have to ship their machines if I don't fix it--when to call it. Mobile users do not have the perogative to drop their machines at the local IT shop on the way to lunch and pick it up on the way back in; they're on the way to a sales meeting in the middle of nowhere. This article not only supports us remote techs who want the end user fully operational as soon as possible, but affirms my daily--hourly--struggles. Thank you TechRepublic and Jack Wallen!

mike
mike

I love working from home and every point hit the mark. I can add this: When you have a client on some kind of recurring income billing, always bill for and credit the stuff you do for free so they see the value in the work you perform that you don't charge them for. Do this with time you do not bill for too. If I work 2 hours remotely and want to only charge for 1 hr, I bill for 2hrs and credit 1 hr and use some kind of statement like Credit for customer loyalty, or just credit for service (date / issue -so they can relate it to the task at hand)

CharlieSpencer
CharlieSpencer

Your standards for computer literacy are good if one is discussing the literacy of administrators, engineers, developers, etc. Jack was referring to the literacy of the end users most often encountered by people providing support remotely. These 'computer illiterate' end users routinely Google each URL; don't know the difference between the Internet, Internet Explorer, Windows, and Microsoft; and have never opened a file browser since their documents are 'in' Word and their music is 'in' Media Player. Addressing your last point, remote assistance differs from in-house IF you are providing third-party support. Firewalls or other security measures unique to the supported person's site may configured to block Putty. It's important for those arranging the support to make sure remote accessibility is tested regularly. The client's networking staff may inadvertently make changes that disable third-party remote connectivity.

Suresh Mukhi
Suresh Mukhi

Isn't the fact that they needed to reboot their system also a symptom of another problem like a virus or the hardware itself?

CharlieSpencer
CharlieSpencer

I had no idea this category of software existed. Thanks!

Suresh Mukhi
Suresh Mukhi

Thank you so much for this tip! Now I just have to google 'smartphone simulators" . Which one would you recommend for Nokia, Apple, Android?

CharlieSpencer
CharlieSpencer

I've learned that can mean anything from, "I sent the job to the printer but nothing came out", or "I can't find the printer icon in this application', or "The document I want to print won't open", or "I can't find the document I want to print", or "I can't get logged on", to "This damn thing won't turn on!"

eldergabriel
eldergabriel

You mentioned some good points, and there are many dimensions and aspects to what you are talking about. This is clearly an area where those "soft skills" we so often hear about come into play, and many of us who are technically adept are often stereotypically found lacking. One of those soft skills is the ability to accurately gauge the end user's knowledge base, abilities, and quite often their sensitivities. For instance, a tech may not think they are speaking condescendingly to a user, but the user may judge from the tech's tone of voice, accurately or not, that they are being talked down to. I've also observed situations where a support tech with a relatively low self esteem, having a bad day, will feel the need to throw technical jargon or use other aggressive approaches toward the end user to make him/her feel better about themself. Other times, the end user may be exceedingly difficult know-it-alls, and may need to be put in their place. There are many reasons, not always logical or clear, as to why a recipient of technical support may feel as though they are being spoken to patronizingly. To be successful in this line of work, one absolutely must hone the fine art of getting a feel for where the user is coming from and adjust one's approach accordingly. LCDS - "lowest common demoninator syndrome", heh. This is often unavoidable for newbie support drones, still green around the gills, floundering in the big pond. I suppose it's a phase most of us go through, if only for a little while. It still stuns me though when I am the recipient of such treatment when I call in, only after having exhausted all other options. And then, after having explained the problem in technical depth, they haven't picked up on the fact that I clearly know what I'm talking about, and have already done the bulk of the troubleshooting for them, to the point where we're beyond front line or even tier 2 support, and the issue needs to be escalated even further. Such is life. At any rate, I agree: great article.

skootert221
skootert221

That's a great way to show your value!!!

Lawrence Garvin
Lawrence Garvin

In the 1990s it was merely a symptom of the relative instability of the operating system: Windows 3.1 And while the fact that the end user did reboot the system to resolve some perceived issue should be logged, quite often such needs are just a natural outgrowth of how that user is using (or abusing) the system. Sometimes it's a buggy application ... and there's not much that can be done about it. I'm currently fighting a (well-known) HTML rendering issue in Outlook 2010. It requires me to kill off the process from time to time to restart Outlook (or proactively close it at the end of each day, which I'm not wont to do). A typical end-user would not likely be inclined to go kill outlook.exe using Task Manager, but rather reboot. (Everybody knows how to Ctrl-Alt-Del.)