How to explain IT?

[Nuriko]

I'm curious how others explain the difficulties in IT troubleshooting to those who seem to always think "why doesn't it just work, this should be simple" or "you're a professional right? Havent you memorized all the fixes?" - I know, most of the time it's not worth the stress and effort explaining how technology works. But there are times I wish I had a better way of explaining how the same problem doesn't always have the same solution. I've seen a handful of "savvy" tech people think they can do professional IT work believing that for each problem there must be the same one solution each time (besides Google). When it comes down to it, even if they do know a few things, they simply do not know how to properly troubleshoot/research anything so they end up looking foolish when they don't get it right the first time and then spend hours on Google and even then arent able to fix it or by the time they do they have lost the faith and trust someone put into them originally.

So generalized topic questions: How do you explain to a non tech person that not every issue is always going to have the same cause? Is troubleshooting a skill that can be taught to someone just starting out or is more of an acquired ability that can only get better with time and experience?

Quick background on where this comes from...suddenly find myself in a management role after being the only IT support for 15 years where "I don't know" wasn't acceptible. Now I have some staff under me. Problem is they're sort of new to support and have the simplistic view above in regards to problem solving. I'm trying to get through to them they need to learn how to troubleshoot but don't know how else to explain it or teach them. Then I need to explain to my own manager that this isn't something I can just bash into their heads. So figured I'd bring up the general ideas here to get some additional thoughts and ideas others might have.

Maybe a simpler question would be "how to train IT noobs" XD - Anyway, thanks in advance for feedback and discussion thoughts!

[Shenrien]

To answer your generalized topic question because I get ask a lot by clients how I remember all this stuff or how I am able to troubleshoot and solve issue. It boils down to time, experience and reflecting on documentation on tasks that have taken a wealth of my time to complete that were not so easily solved. Problems have come before the client I'm currently helping, if they were a first case then it may take a little longer to recreate the steps they took to come across the error or problem they are having. I do my documenting along the way and make note of what steps I took to get to a resolve on first time experience issues. Most cases are a repeat and it is stupid how many things can be fixed with a simple power cycle.

[Francisco]

I'm an IT student, and haven't done any actual on-the-job stuff, but for me it's a matter of eliminating the simplest possible causes first - which can be frustrating for users (i.e. "Oh, it won't turn on? Is it plugged in?"), to which they might respond "I'm not a moron..."

From the simplest problem, you work your way up, eliminating possibilities, because you don't want to look like an idiot ordering a new monitor when the issue is it came unplugged from the tower, or there's a faulty power cable or whatever. Not sure if I'm answering your question or not though, without getting a better grasp of what sort of issues are irking your users. But I would say for any given problem, there's a multitude of possible causes, and you always eliminate the simplest, most common ones first (which is usually the user being a derp).

Edit to add: It's also essential for IT people to have a fundamental idea of how the systems work, with everything to an extent being a "Point A to Point B" process... simply put, if something isn't working, there's a Point A that needs to be working with Point B, but isn't...

Simpler cases being power and networking, a bit more complex with OS/File stuff, but really the same idea if you think of it.

[Byrthnoth]

Start the conversation with "You see, son, bugs are an emergent property of a complicated system with simple rules." and then just let it snowball.

[Hellfury]

Start the conversation with "You see, son, bugs are an emergent property of a complicated system with simple rules." and then just let it snowball.

hehe, I use a twist on this actually, most of my users are completely clueless, but they mostly accept the explanation that code isn't flawless, modern systems have a lot of error tolerance built in, but sometimes the bugs become too much to handle, and the doubters I show the event viewer in windows, then they mostly just nod and agree to whatever I say just to make it stop.

[SephYuyX]

After 15+ years myself, I can barely explain my functions in IT to someone who doesn't understand IT.
I'm pretty sure everyone outside of IT thinks we all just troubleshoot desktop errors regardless of our specializations.

"Yeah, you know, I work on this big word, and this technology, which enables you to be able to do this that and the other, also we run this that and the other, control these functions, the security, and basically everything that keeps this place alive. Not to mention any sort of mobile technology, and the rest of the infrastructure that wraps everything together.

"Oh? You mean you can tell me why my laptop is slow when I browse facebook and youtube?? I thought you just sat around and did nothing until something breaks!"

[Ratatapa]

My description is simple

i'm the one who erase your porn videos

[Niya]

I've been working in IT for 10 years now, and my colleagues sometimes call me the "company wiki" because I seem to know the answer to almost every problem. Sometimes my boss has the great idea to tell me that i should share/teach the stuff i know to the others. The thing is, for some specific issues i can write a how-to, but most of the time I can't because there is no "one way to solve it" but it's rather that I just learned from experience how to approach it.
So yeah, there is no way to "teach how to troubleshoot" other than solving problems yourself and learning how to deal with them. And that takes time, patience and lots of Google...

[The Stig]

I find it better to try and use analogies to other things none IT where possible when explaining, especially to users.

For example, I often find it nice to compare it to a car, when it comes faults with hardware. For the internet, I compare it to a water system if people complain internet is slow (where data = water, and turning on tap = downloading/streaming/using bandwidth).

EDIT: I also want to say, I'll only explain if they ask. Otherwise I'll make a lighthearted comment about stuff like "yeah, it breaks as often as our public transport" with a laugh/joke and leave it at that.

To teach your team stuff, besides telling people to google it, I would suggest the following phrases:

"Did you check the logs?" (application, windows, network, where appropriate) & "Can you reproduce the error?"

Getting people to check logs is crucial I feel to a lot of things. Otherwise, short of that, is to get the user to replicate the issue under your presence.

[Hellfury]

Slightly related

[Yabby]

Otherwise, short of that, is to get the user to replicate the issue under your presence.

Have to love when you walk into a room for them to show you the problem, and everything starts working perfectly.

It's almost annoying at how often this happens.

[Ratatapa]

Have to love when you walk into a room for them to show you the problem, and everything starts working perfectly.

It's almost annoying at how often this happens.

90% of the time it's a code 18

[Melena]

My description is if you've figured out google, i'd be out of a job.

[The Stig]

Have to love when you walk into a room for them to show you the problem, and everything starts working perfectly.

It's almost annoying at how often this happens.

Annoying in a way but I enjoy it more often than not. I enjoy getting summoned and then seeing a problem escape.

The only times it's annoying is that you really need to fix it but cannot because of this, but for most issues I'm happy for it to escape.

Some other related media, but usually in larger IT Companies that deliver solutions:







And for the true Googlers:





edit:

Useful tools: http://fakeupdate.net / http://fakewindowsupdate.com/
https://technet.microsoft.com/en-gb/.../bb545021.aspx

[Nuriko]

I find it better to try and use analogies to other things none IT where possible when explaining, especially to users.

For example, I often find it nice to compare it to a car, when it comes faults with hardware. For the internet, I compare it to a water system if people complain internet is slow (where data = water, and turning on tap = downloading/streaming/using bandwidth).

I really like the idea of analogies too. Never thought of a car analogy but I like it and water/pipes/bandwidth is an easy one that people usually understand. I try to use a doctor/patient analogy sometimes. For example, this has happened once or twice:
"Why does my Internet not work?"
"I don't know, can you tell me a little bit more about what you're seeing/error messages etc?"
"It's just not working, don't you know why?"
"Well, if you tell your doctor you have a stomach ache, are they going to instantly know the cause without more info?"

Some people understand/can relate to the idea of problems as being like an injury/sickness and that learning the symptoms can help pinpoint the causes of them (I think I was inspired by House's diagnostic philosophy). Others think I'm crazy for comparing myself to a doctor even though that wasn't the point /sigh

[orinthia]

Practice. There's not a lot you can do to teach troubleshooting, it comes from years of dealing with shit and not running to someone else to fix it. It takes creativity, a small desire to learn and adapt, and an understanding that you're not just following a script since scripts can hardly solve people. Lots of folks are like this, young and old, so while some take to this sort of thing like a dolphin to fish and never grow out of it, some need a flowchart, troubleshooting manuals/wikis/forums, a guiding hand, and to have a pencil+notepad tied to their arms just to get their barrings.

Notepads are the saviors of complicated issues, because you will forget what you tried hours before or things you've changed since you started. Even if you fail, you now have a record of what was tried so time isn't burned retrying dead ends (can be more important than actually solving an issue sometimes).

[Jefe]

IT's are those who couldn't cut it as Computer Scientists :kappa:

[ikariiiii]

at the root of all troubleshooting is isolation. isolate all possible factors and you will be more likely to resolve the issue. i have to repeat this sentiment a million times at my job daily; some people get it, most people choose not to try.

[Enedin]

Analogies all the way. I work as a UX and UI designer for a company that makes document generation software for CRM systems, and I explain this to my grandma like this:

"Our customers already have cars, but now they want music. Some cars come with their own radio, but our radio can do a lot more, so some people want to buy our radio. My job at the company is to make sure that radio is nice to look at and easy to use. Like, where do I put the volume knob? How can I easily switch channels? That's what I think about."

Car = CRM
Radio = document generation software

And I take this all the way:

• "Our radio is great and can do a lot of stuff, but you cannot put it in every car." (we only integrate with a few CRM systems)
• "Our previous boss had a tendency to put 38 buttons on the radio, instead of hiding them in options that you can navigate through." (our former boss didn't think UI is important and he just showed all options to the user at once)
• "Most of our radios look the same, but we also sell one kind where you can decide for yourself which buttons to use and where to put them." (we have out-of-the-box solutions and an API that developers can use to build their own document generation stuff)
• "You don't want to have a volume knob that gets stuck when you turn it too much." (we used to have a function that, when overused, would render you unable to generate further documents)

Obviously you lose detail, but you win so much clarity that it definitely makes up for it. Just gotta talk to people in terms they understand.