Is there value in explaining problems?

from personal experience, when I did support way back when. It would depend on the user I was helping. Some of them did not care, others were interested. So I would gauge it on that.

Now for my private clients. I always let them know what the problem is/was. I let them make the decision if they care or not. Once in a while I will ask them if they want to know what the problem was.

The scenario that makes the most sense is if the support person finishes their call, and let's the person's supervisor know what the problem was. End users typically get the information wrong anyways, so cut out the middleman.

Obviously if your friendly with the end user, your more likely to describe to them the problem. But if it's someone who you are not on a good relationship with, a brief description of the problem and what they can do to help prevent it from happening again is ok.

Some users just want to turn it on and have it work, and they don't care to know all the technical details. They're the ones who wouldn't understand anyway if you did tell them. You know that glassy look in their eyes when you try to tell them - again, for the umpteenth time - what a networked drive really is? Why even bother?

Then there are the ones who are somewhat computer savvy, but their real expertise is in their "real" job, and they know it. They realize that when it comes to IT issues, they're only about a 3-4 on a scale of 1-10, but they like to understand how things work a little better. They want to know what's going on, but only because they don't want to find themselves dead in the water if I'm not around, and if they "kinda understand", maybe they'll be able to surprise themselves by being able to figure out something on their own. These are usually the kind of users that I may ask what it is I can do to make their computing lives a little better.

Some users, the real dangerous ones, think they know everything about everything. (And as we all know, no one knows everything about everything.) These are the ones who want to know every little detail so they can share their expertise on the issue, and explain why the initial failure was someone/something else's fault. If it's a problem that was obviously his/her fault, I'll explain the whats and whys the problem because I love the look of egg on the face of someone like that. If it's not their fault, I won't tell him/her anything because it's fun to see them wondering, but not wanting to expose their true ignorance.

Then there are the ones who always "imply" that any failure is obviously a failure on someone's part to prevent it, someone other than themselves, of course. These are the ones on whose computer I always find (yes, I may help it along a bit) an unauthorized program, or that "spyware", or that "mysterious" virus that is only spread by email, or something like that - regardless of what the real problem is. They fall into the "egg on your face" category, but a little more fun.

Some users are really nice about everything, but they themselves did something to screw it up. They need an explanation of what went wrong so they won't do that anymore. These are the one's I'm really nice to because they're always really nice to me.

Now in your case, where a department manager wants to know what happened to another user's computer, I might have to know the reason he/she wants to know. Is he/she looking to place blame for the failure? (Either on the IT department or the user.) Most vocally opinionated people are that way because they want to prove their own prowess or deflect blame to someone/something else. I don't know the exact answer to your particular circumstance, but it appears that if you can put this person in the "egg on your face" category a couple of times, he/she may be less "opinionated" in the future.

I think in MOST cases a breif explanation of what happened or more importantly HOW something happened in enough in most cases.
In the case of the more involved user, I would take time to explain enough that they could avoid or begin to resolve the problem themselves.

I find it usually more helpful, in the case of the more experienced user, to offer sources where they can find information or begin resolving things themselves.

Automotive: in the case of fixing people's cars, I never let people stand around and see "how it's done". Other than the fact that I spent over $60,000 in six years of school and feel that I should reap the rewards, If someone was to look over my shoulder as I replaced brake calipers (simple enough) they may attempt to do it themselves next time without knowing what to look for or what to avoid doing (ie. dirty hands when putting it all together, causes brake fade, squeaking and possible failure/injury). When it comes to cars, people may die if they don't do things properly, so I'm held responsible. For example, I'm sure many people think you are supposed to PUMP UP the brakes when bleeding them, this wives tale leads to improperly proportioned braking and may cause accidents that lead to death, especially in the ABS world or today.

Some things you can learn from watching and trying, other things require professional training. Just because I watch open heart surgery on TV, doesn't qualify me to perform it.
Whereas, if I watch a computer show, I would have no reluctance to edit my registry and tweak settings.

The value of explaining a repair depends on the user and the problem.

If the cause of the problem was something that the user did wrong, or a task that needs to be performed in a specific manner, then by all means an explanation is needed.

If explaining the problem to the user can prevent the problem from happening again, then yes, this also deserves an explanation.

One way to handle this particular manager, is to have a set of canned explanations ready.

I changed the ____
I re-installed ____

Make the explanation short and sweet, but honest.

Keep in mind that the manager may be building a case for more training for their staff, or for out-sourcing IT.
Make sure that you play company politics in your favor.

Chas

I make it a general rule to give at least a very brief explanation of what happened and how it was fixed. For example, if a user typed over a formula in their Excel spreadsheet and now the totals don't add up I would explain that to them, and let them know that if they want to avoid this in the future, they can do it by locking the spreadsheet.

If they express interest ("Really? How do I do that?") I can give them a little value-add. Otherwise, it's simply a small amount of incremental time spent to hopefully avoid the problem in the future.

I work with clients on a consulting basis, so the more value-add I can throw in the better (for them and for relationship-building), but I do keep it low-tech. Most of my clients don't particularly care how I was able to fix it, only that it has been fixed.

I find that I tailor my "explanation" to the unasked questions from users: "Did I break it?" "Is it going to stay fixed?" "Is there anything I should be doing differently?" I answer those questions, truthfully, even if they don't ask. If they ask what the problem was, I give it to them in very general terms "Windows glitch "Wasn't setup right."

As for the opinionated manager. He's bordering on telling you how to do your job. I've run into these types on occasion. They're the kind of people that would arrive in heavan and promptly tell God he should spend a couple bucks to fix up the place. We're not paid to explain client/server technology to lay-people. We're paid to keep it running. The manager needs to know that. If we explained everything we did, we never get it done.

Well I must admit I don't believe non-IT personal should have a detailed explanation on how a problem was resolved. Sure, in the case where it is a users mistake, explaining why it went wrong is fine. We've all worked damn hard to get the knowledge we have. Studying and experience. I don't see why we should give that info out so easierly. My diploma and mcse cost me alot of money, if my boss (non-IT) wants to know exactly how I solved a BSoD or something, he should go do the mcse himself. Then I'll gladly explain it to him.

Don't get me wrong tho. I do believe that sharing experience and knowledge with other IT pros as an absolute must. Its a tough industry and we must work together to get it back on track.

Do your techs write out tickets to track the work? If so, as long as they are not detailed accounts of the work done, leave the user a copy adding if they have further questions to call or e-mail the tech. This does a few things: 1. It gives the user the opprotunity to read the explanation, if they are interested. 2. Provides a trail of the work done on the computer. This is especially useful when dealing with "You did something to my computer and now xxxx doesn't work!" 3. And providing an explanation can help build a raport between the tech and the user.

Many times it feels like it's the techs versus the users. And while this attitude can make us feel vindicated it doesn't solve the problems. Your users can't do their job without you but you won't have a job if they don't get their work done. Short version: You're a team (yes, I know you all hate me now). Whether the obnoxious manager want's to admit that or not it's the best attitude I have found for dealing with these situations. And, honestly, the user's I have the best raports with seem to be the ones with the fewest problems. Good Luck.