Dreading going home for the holidays and dealing with all the broken computers? Tech support can be hard when you’re figuring out how to do it in the moment, even if you write software for a living. But it gets a lot easier if you apply a few techniques that Support professionals do.
Way more products come with tech support than the people asking you for help will remember. A first step in responding to any request for help should be, have we already paid someone to answer this? If the answer is yes, open a support case with them. It’s the best help you can give.
Basically every support problem has happened many times, and there’s a good chance someone will have posted the answer on the Web. Use a search engine and try to find it. I recommend Google1.
These two things combined mean that you can recruit people who are clued in, even if they’re not engineers, to provide initial support for friends and parents who would otherwise reach out to you directly. In exchange you teach them how to do Support, promise they can come to you when they reach their limit to help out, and you step in quickly when they do come to you2.
Once you’ve done this, you’ll have a support team. Doing support on a team is way better than doing support alone.
People will come to you saying “my computer/website/whatever/… is broken.” Don’t launch into a troubleshooting flow for the problem immediately, and don’t ask them to try turning it off and then on again.
The two questions you should always ask, if there is any doubt in your mind about the problem at hand, are:
These questions respect the person who’s coming to you for help, and they take the conversation away from the bad experiences that people might have had calling help desks in the past.
You can, and should, teach them to anyone you recruit to help you with support. And teach them to anyone who is about to open a tech support case - you can sometimes move a case from an unproductive response to a productive one by saying, “Would you like to know how I determined there was a problem? / what I’ve tried to fix it?”
Have an idea in mind for what might be causing your friend’s problem. As you work to troubleshoot, you should know what possible causes of a problem you’ve ruled out and what you haven’t.
The ideal to aim for is to gather information in a quick pass or two, then write sufficiently detailed directions – effectively a script that will be interpreted by a person! – that will let them solve their problem in one pass. You might not always achieve this, but it’s vital to try. Limiting the back and forth will save both you and your friend frustration.
Try to take advantage of writing, whether in email or on a website. It’s often helpful to include a brief note of how you came up with the answer, like “Refer to the Help Center page at support.google.com/… for more detail.”
Limit time spent logged into their computer, whether in person or on a screen share, to the time actually needed to do work that your friend is unlikely to complete on their own. Try to do most of the work by email and script. When done right this will both build your friend’s confidence and make it more likely they’ll be satisfied with the end result3.
Do you know what Rule 1 of Support Club is? You can talk about Support Club, but never name the people you help outside of Support Club! This is why all of the examples I’ll give here say only “a friend.”
Your friend’s personal computer is personal. They might have done things with it that they won’t want you to know about, even if they have come to you for help. For instance, they’ll ask for help with computer slowness, you’ll ask “Do you have any idea why your computer might be running slowly?,” and they’ll respond with a “no” or a fable they made up on the spot4.
Or you’ll ask if they have anything they’d mind you seeing on their computer, and they’ll answer “no” even though they do.
In 2004 (freshman year of college!) a friend told me their Windows XP laptop was running slowly.
I asked if they had any idea why. They said they didn’t, so I told them to defragment their hard drive, print out the report that defrag generated, and give me the printout. They did this, and to my surprise and theirs, the list of “files that did not defragment” was mostly video files with porny names.
They hadn’t read the report before giving it to me, and were embarrassed when I asked if they knew they might have downloaded viruses along with their porn. I couldn’t figure out how to clean their system, so I sent them on to campus IT.
A senior tech at the campus help desk later told me that the viruses of the day were troublesome enough to remove that they handled every PC that came in with viruses by wiping the hard drive and reinstalling Windows5.
When you’re doing support for friends, you can do this by blogging your answers, and updating them when you find points that didn’t quite work out. It’s only a little more work to do this than to write an email, and it will both build your intuition for support and let you help other people than just the original person who asked you.
Remember Rule 1 of Support Club. Don’t name the people you’re helping. That includes link to their websites or social media profiles that you’ve worked on.
When you’re an engineer it’s easy to see problems as needing custom tools to solve. Question this. Learn to see the simple solution, which will often have more manual work than you’d want to do if the problem will come up again. It’s a better deal than you’d think. The problem probably won’t come up again, and if it does the manual work will have given you a much better intuition for what you need to build anyway.
Example: a different friend asked me for help with their hacked WordPress blog on a Linux shared host in 2013. I didn’t follow my own advice here and tried writing a tool to do this recovery. I thought for some hours, didn’t come up with a tool, and wound up being able to recover the data manually in less time than I’d spent thinking about tools I could write to do this6!
I didn’t meet anyone else who had a hacked WordPress blog for another three years, so the tooling would have been wasted even if I had built it in this case.
When someone comes to you for help, try to solve their problem in a way that it will not return to you. This often involves moving from products where support is no one’s job (so it winds up being yours!) to products where it is someone’s job.
Example: my friend with the hacked WordPress blog wanted me to put their data back into another WordPress blog, but absent a clear idea of how it was hacked it seemed likely that a new blog would be hacked like the old one was. Once I got their data back, we imported it into Squarespace and signed up for an $8/month paid plan.
We talked with Squarespace support once over email when the import froze, and they were super responsive. It succeeded later that day and they haven’t needed to ask me for help with their website since.
When a friend asks “how do I do X,” it’s easy to approach this like they’re a consulting client and offer many alternatives. Don’t do this. Learn enough of the problem at hand to offer one alternative that will work with high confidence, and pick one that will minimize the effort that you and they will spend on it down the line.
Long chains of decisions might be very profitable when you’re billing by the hour, but here they just waste both your friend’s time and your own. Pick the most likely set of decisions that will solve the problem at hand, and and write instructions to implement them instead. You can always revisit them later.
Example: Another friend asked me for help “getting a domain.” I asked one question, “what do you want to do with your domain?,” and learned that they wanted to host a website that would mostly contain stories and essays.
I missed one decision along the way – my friend didn’t realize that they needed to use the top level domain they’d registered (or its www. subdomain) for a browser to find their website! – but that was resolved with a ten minute screenshare instead of what would have been hours if I had held their hand the entire way.
Getting More – tech support is a negotiation, and negotiation skills help whether you are giving or seeking support.
xkcd’s Tech Support Cheat Sheet
And I work there too . This post is just my opinion though, not that of my employer. ↩
A professional would say your tech-savvy friends and family are in a “frontline support” role and you’re in a “backline support” role on the team.
Unlike commercial support, when you do this in your own life it will be “open label” and your end users will know that the person they’re talking with might not be as good with computers as you are.
If they’re good enough, honest about their limits, and you step in promptly it still works. Someone who solves most problems quickly, and sends the rest to you to solve slowly, is more helpful than you solving every problem slowly. ↩
LEGO toys and IKEA furniture are satisfying for the same reason. ↩
The affirmative “downloaded porn/cracked software/something I thought was a useful tool like an antivirus but was actually malware” is the most common helpful answer. Other helpful answers are possible but very rare. ↩
Consumer grade malware basically always targeted Windows back in 2004. Times have changed and bad guys go after consumer Macs and Linux PCs, and networked cameras, and blogs, and basically everything that’s on the Internet and connected to power now too. ↩
It still took the better part of a day work to clean up and move, including a lot of reading various dump files and deleting junk by hand. Recovering from being hacked with spam is hard even when you’re good with computers. ↩
I actually sent it to the tech-savvy friend in their circle who has taken up frontline support for them first. I only sent it onward once they had looked at it and agreed they were on board.
Part of being on a Support team is minding how much work the advice you give will lead to for your teammates. ↩