lukas-juhas-422507-unsplash — *Photo by Lukas Juhas on Unsplash*

This is week 6 of the Google Professional IT Certification course on coursera.org.

. . .

This week may be called “Troubleshooting,” but there is a lot more to it than that. Actually, there is less about troubleshooting than about how to comport yourself during interactions with users. If people you are trying to help get angry it is really because customer service can be terrible work, so you just have to learn to work with people and not let their antics throw you off. Personally, I think I have burned out of the customer service “mentality” (and gone back) so many times I think it is just part of my brain at this point. Walk through the workplace doors and suddenly I just expect that every couple days or so some weirdo is going to be a jerk for no reason. Have a great day!

This week’s course material starts with a broad, definitional assessment of troubleshooting and then just sort of devolves into a “soft skills” overview that is useful (if you have never had a job or can’t see faces or hear tones of voice) but not necessarily related to IT. Onward to the videos.

Module Introduction

Knowing how to identify, analyze, and resolve problems throughout the many layers of an organization’s technological systems, while being nice to people, seems like the focus of this segment. Working in the IT field is technically challenging and also very rewarding. You have to know how to work with people. I feel like there may be some really exciting quizzes coming!

Ask Questions!

Here’s one before the video even starts: Is this turning into a basic customer service course where they sometimes talk about computers? I may not be great at it in the real world, but I am an expert in Theoretical Customer Service—or what I like to call TCS, in my upcoming eBook and lecture series entitled Have You Ever Actually Been Inside a Store?

It seems that people somehow have a tendency to overlook the questions element of troubleshooting. This seems like a crazy assertion, but here we are.

Troubleshooting: The ability to diagnose and resolve a problem.

Effective troubleshooting is one of the most difficult and important skills in IT. Asking questions is the most important part of troubleshooting. To demonstrate this, we are now going to watch a demonstration of a “bad” troubleshooting interaction and a “good” one. I bet the good one has effective question-asking. Let’s see…

Oh man, the first time the guy says she needs a new computer, the second time he fixes the problem by asking some questions and finding a solution! And he didn’t even insult the idiot for having her screen dimmed all the way down! Unbelievable!

IT Support is about working in the service of others. Always try to create a positive experience for the user.

Ugh, fine.

Isolating the Problem

This is how you narrow down the range of possibilities, or scope, of potential problems. This is very logical. Shrink the scope!

Root Cause: The main factor that’s causing a range of issues.

Finding the root cause is especially important in an IT support setting, because you will then be able to prevent the same problem from happening over and over to multiple users. This is demonstrated by another “bad” and “good” scenario, where the “bad” example is a woman is having email problems so the IT guy uninstalls her email program, which doesn’t fix the problem, and in the “good” example he reads his email to find a notice saying that the email server is being taken down for an hour. Hey I think I isolated the problem: the root cause here is that this woman doesn’t bother to read her emails from IT.

Follow the Cookie Crumbs

When given a technical problem, begin your search for solutions at the point when the problem first began (or was noticed by the user). Asking “When did this problem start?” can be the most important question, and can inform the rest of your investigation. Of course this concept is demonstrated by another pair of videos, one “bad” and one “good,” where the user can’t get her cute cat app (whatever the fuck that is) to open. The “bad” IT solution is to just reinstall the app, which doesn’t solve the problem. The “good” process shows the guy asking about when the problem started and discovers that the issue may have started right after the app updated. He rolls it back to the previous version and the bullshit cat thing works again. Super.

Just as questioning the user can give you important information, any system that keeps logs is also extremely valuable in any troubleshooting endeavor. Dig through ’em! There will be more about logs in future courses, supposedly.

Error messages can also be very helpful. In my experience, they can also be very vague and not actually offer any real information beyond a generic “that didn’t work” message. It is a best practice to start by solving the first error, which may have caused a cascade of errors. That first error’s resolution can solve all the rest.

Start With the Quickest Step First

Can’t argue with that! When searching for the root cause of an issue, it is often logical to start with the quickest potential fix. For example, our hapless IT guy recommends re-installing new software that is unresponsive in his first “bad” try. The second time he asks if the user restarted the computer after installing the software, which fixes the problem. Both solutions could potentially fix the problem, but restarting is going to be faster than reinstalling, so try that option first.

Troubleshooting Pitfalls to Avoid

Here are some common things you can watch out for while becoming a great troubleshooter.

#1 – Autopilot: You may encounter the same issue over and over and over and over and over and over again. You may get good at fixing it, but you will also stop thinking critically while fixing that problem. This could easily cause you to miss some important information when you come up against something that seems just like the other problem but is actually different in some subtle way.

#2 – Not Finding the Root Cause: It is easy to get distracted by small problems. More often than not, there is a larger, unseen problem causing all the small ones. Spend time searching for that root cause and you will fix all the small things at once. Investigation, testing, and identification of the root cause is more effective and rewarding.

What the hell, there are only two pitfalls? Good? And then comes the first quiz.

Intro to Soft Skills

Well, I knew this was coming. At least it is being addressed kind of at the beginning of the program instead of the whole damn time. I have noticed that the IT education and training ecosystem seems to really like to focus on “soft skills.” I don’t want to say that this is misguided, or that it is an easy way to avoid teaching actual skills, but that it doesn’t really have anything to do with IT. Every business wants to hire people who can communicate and behave civilly. Everyone wants to know there are behavioral baselines, and that they are being observed.

Maybe it is like this in other career training areas, but I wonder… Does the complexity of the IT field create some perception of need to focus on soft skills? Why have I had more training in body language (identification, deployment) and listening to people than in basic networking? I haven’t even been taught subnetting and here we are, starting over at soft skills. Oh, well.

I know this course is targeted at a broad and untrained audience, but everyone should know by this point in their career (no matter what point that may be) that customer service is very important. Even in IT? “Oh yes,” say the videos, especially in IT!

The four most important things to do in customer service are:

Exhibiting empathy
Being conscious of your tone
Acknowledging the person
Developing trust

Empathy is the most important thing on this list. Without that, you may only be sympathizing, which is not good enough, apparently.

“The action you take by looking at it from their perspective is what empathy is all about.”

Holy crap this video is almost nine minutes long. That’s about three times longer than most of these videos…ugh.

Empathy is supported by tone. That means you shouldn’t sound like a jerk, even in writing. Tone is a delicate balance. Thanks, moron.

You can reduce tension during the resolution of a problem by acknowledging the user. If they say something like “I already answered these questions in the email,” instead of continuing to type and question them, you could say something like “I’m sorry for all the repeat questions, but it can help me focus more clearly on the problem you’re having.” Moron.

Developing trust is so important because a user may become unwilling to help you help them. If you work with someone frequently, trust means that you can make a mistake here or there and they will still be willing to come to you for help. If you only interact with someone once or twice, the quality of the service you give them will determine if you are building or harming that trust.

“Be honest with the user, even if you think they won’t be happy about it.”

Kind of a good idea, generally, but sure, that works in IT, too. Never be afraid to admit that you were wrong.

Anatomy of an Interaction

Well, this could be funny. Or a painful reiteration of basic customer service skills even the most rookie copy machine understands… Let’s watch:

The first “not good” scenario shows our tech guy “Marty” and user “Gail” back at it again with a broken phone. Marty just says “hi” and asks what’s wrong with her phone. In the “good” scenario, he makes sure to ask “how are you today?” and when she says her phone is broken he adds that he is “sorry to hear that. Let’s see what we can do to turn that around!” (Reviewing the official transcript of the video, I see that they do not include the exclamation point. I agree, but I am making a stupid stylistic point. A point about the unnecessary exuberance used to demonstrate good customer service. If we spoke they way “good customer service” is written about we would be shouting and pretending to smile ALL THE TIME!)

Using information the user has already given to you will allow you to address them in a way that shows that you are listening to them and thinking about their problem. “Hello, User, I hope you’re having a good day despite your computer catching fire earlier this morning causing the evacuation. Let’s see if we can get you a new one.”

This video wraps up with some vague explanations about how being polite is important, more or less, and how explaining to the user what you are doing is going to help them feel comfortable throughout the explanation. At the end of the interaction it is important to provide a summary of the problem and how you have fixed (or attempted to fix) it, and leaving them knowing that they can contact you again if the problem recurs.

How to Deal with Difficult Situations

Right out of the gate here I’m going to guess 1) raise your voice 2) explain why they are wrong and 3) point out how they must be such a disappointment to work with. Okay, let’s see how I did:

There are physiological responses we exhibit when faced with a perceived threat. These include “tunnel vision,” increased pulse and alertness, as well as dry mouth and sweaty palms. (Not letting that guy use my computer.) While you may not really be in any danger, these same reactions can occur in a bad customer service situation. This can cause you to lose focus and become a terrible, useless worker.

Sometimes the best thing you can do is to develop some kind of “reboot” process, such as looking away, taking a deep breath, or counting to one hundred thousand or a million. It is important to be able to identify where in the interaction things started to go wrong. That way, in the future, you will be able to prepare yourself and even avoid losing control, or redirecting the conversation away from this disaster zone.

A common source of anxiety and rage for customers is when they do not understand the question, or they think you are asking the same question over and over again. It is a great skill to be able to ask questions differently to try to get the other person to think about it in the way that you want. I am always quickly coming up with a polite way of re-asking something so that the person will actually answer the question I have asked.

Avoid situations where the you are both trying to talk over each other. There is a video scenario demonstrating this. Some users can get aggressive because they aren’t getting the answer they want to hear, or they think they are too important to have to follow rules. It is important for you as the technician to try to stop or discourage this kind of behavior, even if it means going to the proper members of your organization to address the issue. This video is telling you to report assholes that come to the help desk and harass the technicians. Okie dokey. But also, more importantly, be patient. What? Squeal on the jerks but also take time to try to see things from their perspective and consult company policy and documentation.

Quiz. Check.

Ticketing Systems and Documenting Your Work

Documenting your work may seem like a waste of time, but it will really save you tons of time later on. Instead of having to re-learn a process or re-create a solution from months or years ago, all you have to do is consult your detailed and thorough notes from the last time you confronted that problem.

A ticketing system notifies you of problems, the users and machines involved, and any notes you take while working on that ticket. It will also keep the user in the loop as you work through the issue.

Systems and processes are always changing, and so should your documentation. Be concise and clear, and take note of every relevant detail.

Process Documentation

No documentation is the worst documentation. All the time and steps you took to solve a problem are only in your head, and then only temporarily. Next time that same issue arises, none of your coworkers will know that you have already found a solution. They have to solve that problem all on their own while you’re off doing who-knows-what.

Poorly written, unclear, or fragmented documentation is also bad, leaving a reader with more questions than answers. Clear-cut instructions make for good documentation. Identified problems, enumerated solutions, and clear, complete steps on how to implement the solution(s).

Documenting in Ticketing Systems

One of the most important things about writing documentation in your ticket system is leaving an Audit Trail, so that you can clearly see steps taken on that ticket and if those steps worked or not. A bad example could be

User: "My computer broke can you fix it?" Tech: "Yes all set."

While an example of good documentation could be

User: "Hi, I have an issue with some software I use for stuff" Tech: "User had error message '22' when starting xprogram.exe. Traced this error to incompatibility with another program that needed to be updated. We reinstalled the latest version 10.2.5 and tested all clea"r.

Module Wrap Up

People can be upset or uncomfortable when they don’t understand how their technology works or what causes it to stop working. This means that as an IT support technician you are in a position to directly help people in their day-to-day lives by fixing their problems and imparting your technical knowledge to help them understand how their systems work. With great responsibility comes something something.

Writing Effective Documentation

512px-Peanut-Butter-Jelly-Sandwich Here is the assignment for this week:

Write documentation to explain the process of making a peanut butter and jelly sandwich to someone who has never seen one before. You’ll want to be detailed yet concise. Specifically, the documentation should include the following:

a description of the problem
a description of the end result
the solution detailed in a step-by-step manner

I did an amazing job. I will be autographing and auctioning off a copy of my submission for this assignment to raise money for… Oh, wait, no I won’t.

DOCUMENTATION
Construction of Peanut Butter and Jelly sandwich ("PB&J"), Explanation and How-to
3/4/18

>>> 

The Problem: Having three ingredients, bread, peanut butter, and jelly, the user will want to consume all three, and may want to combine the flavors to create a harmonious product, aka sandwich. There is also the question of portability addressed by this process, where two of the three ingredients are not easy to eat by themselves and can even require additional utensils.  
The Solution: Combining all three ingredients into one sandwich unit provides an easy to eat and transport meal, combining all three flavors and textures of bread, peanut butter, and jelly.
The Procedure:
Assemble all three ingredients in a clean work area.
1. On a flat surface lay out two pieces of bread per sandwich being constructed
2. Using a butter knife or other appropriate implement, remove desired amount of peanut butter (about 3 TBLSP) from container and spread evenly over one piece of bread.
3. Remove a similar amount of jelly from the container and spread evenly over the other slice of bread.
4. Lift the slice of bread that has been covered in peanut butter and rotate so that the peanut butter side is facing the jelly on the other piece of bread.
5. Slowly lower the slice down, so that the peanut butter and jelly are pressed together between the two slices of bread.
6. Enjoy.

This was a peer-reviewed assignment. I hope everyone is as kind to me as I was to them. Except for the person who didn’t follow the instructions. Screw them. They’ll wind up in management, I’m sure.

That concludes the first Course, Technical Support Fundamentals, completed over the last six weeks. I don’t see the next course listed in my coursera dashboard yet, so stay tuned for next week, Course II, (Week 7?) or whatever they call it. Oh, hey, maybe this is spring break???