Dear Users… (A thread for Sysadmin, Technical Support, and Help Desk people) Part 10

Status
Not open for further replies.
You wouldn't expect a carpenter to not know how to use a circular saw, but you also wouldn't expect them to understand the internal electrical circuitry that makes it work.

Surely the general principle is that a tool is something that I can competently use but can't necessarily make.

Sure, that's a reasonable definition. I would also say that it's possible to be able to competently use a tool without understanding how or why it works the way it does.

As far as the "tool" part goes, I think we can safely assume that for modern office work computers are tools users should be familiar with. If the job you're doing requires a spreadsheet, word processor, presentation software, CAD, etc, I'm of the opinion people should either know how to use them or be willing to learn.

So where does this leave the user in Accounting who needs help resizing a column in Excel? Do I sigh, show them, and hope they remember it? And if I see too much of that, take it up with their supervisor? Or do I go all JoeMorgue on them and tell them to do their own bloody learning because I'm not their teacher?

For me, it's the first option. At least the first time. If users made a habit of it I'd be inclined to show them where they can find the answers themselves, and failing that kick the problem upstairs:

User's supervisor: "So why are you telling me this?"

Me: "Up to now, it's been a problem between me and the user. Now that I've informed you, it's your problem."
 
Corollary: Read your job description. Pretty sure "Scoring office points" is never one of the bullet points.

I've found doing just the opposite quite valuable. If I think someone's made an error, my concern goes directly to them alone first. A good way of finding out if I'm mistaken before I make an issue of it to anyone else. Also a chance for them to fix it themselves and communicate it in their own way.
 
I've found doing just the opposite quite valuable. If I think someone's made an error, my concern goes directly to them alone first. A good way of finding out if I'm mistaken before I make an issue of it to anyone else. Also a chance for them to fix it themselves and communicate it in their own way.
In other words, NOT scoring office points but actually looking to solve the problem, hopefully permanently.
 
As far as showing someone how to resize a column in Excel, if that's all one does, it's pretty poor teaching.

Far better to show them how resizing works as a general principle, where GUI grab handles/handlebars/whatever-you-call-them can be found using a range of examples.
 
In other words, NOT scoring office points but actually looking to solve the problem, hopefully permanently.


Exactly, like I was just telling the new guy I'm training (after showing him the remains of one of my major F-ups) "It's not about placing blame, it's about finding what the problem was and fixing it. Everyone screws up, you admit it own it and learn from it and it won't be a problem. You try to hide it and we may not be able to find the problem that needs to be fixed. Sometimes it's procedures, training, systems even hardware and yes at times personnel ".
 
Exactly, like I was just telling the new guy I'm training (after showing him the remains of one of my major F-ups) "It's not about placing blame, it's about finding what the problem was and fixing it. Everyone screws up, you admit it own it and learn from it and it won't be a problem. You try to hide it and we may not be able to find the problem that needs to be fixed. Sometimes it's procedures, training, systems even hardware and yes at times personnel ".

A beautiful sentiment but one that doesn't always fit the realities of the working world. CYA should be written in golden letters a foot high on every wall. You want to do the very best IT work? Don't worry about CYA. You want to keep that roof over your head? CYA CYA CYA.
 
As far as showing someone how to resize a column in Excel, if that's all one does, it's pretty poor teaching.
Far better to show them how resizing works as a general principle, where GUI grab handles/handlebars/whatever-you-call-them can be found using a range of examples.

Are general IT staff trained in how to train someone. Have they covered that particular feature and of course, that is not what your customer i.e. the person you are trying to teach wants.
 
Please try again, this time reading what I wrote. (I recommend you read my next post first.)

(Deleted part of this post after reviewing JoeMorgue's contributions to this thread.)

Your scenario was farcical. You might as well asked how I would do it if there was a person standing behind them holding a gun loudly declaring that they would shoot them if they asked how to resize an Excel document.

And even if your scenario was true it still wouldn't be my problem if, through some insane scenario Google was not available to them and it was because of the way the customer wants their system set up.

"I can't charge my phone on my computer, fix it" when the answer is "Because your boss, my client, asked that USB port security be enable" is also not my problem.

"My computer only works within the perimeters my company has tasked IT to let/make it work" IS NOT MY PROBLEM.
 
Last edited:
A beautiful sentiment but one that doesn't always fit the realities of the working world. CYA should be written in golden letters a foot high on every wall. You want to do the very best IT work? Don't worry about CYA. You want to keep that roof over your head? CYA CYA CYA.

A wonderful and true sentiment, but (and this might be me to a degree) a job where the CYA has to be constant and there is no, I guess "trust" isn't exactly the right word but it's close, between "IT" and "Corporate" sounds just... so exhausting and toxic and not worth it.

ETA: The metaphor might be a bit crude but I once in the Navy told one of my superiors something to the effect of "I can either keep my ass covered or constantly be pulling miracle fixes and solutions out of it, not both."
 
Last edited:
A wonderful and true sentiment, but (and this might be me to a degree) a job where the CYA has to be constant and there is, I guess "trust" isn't exactly the right word but it's close, between "IT" and "Corporate" sounds just... so exhausting and toxic and not worth it.

Well, "worth it" depends on what they're paying you. But yes, those sorts of positions are not the happiest, and I was glad to move to more placid waters where the stakes are lower. The CYA I do now is much more relaxed, and the stakes are mostly confined to protecting the reputations of myself, my team, and my management silo. In my previous position my CYA had to protect my company against our expensive contractors implementing the new system, and at times there were tens of thousands of dollars at stake if fault in a mistake could be proven to be ours or theirs. Also potentially our jobs, if something big had gone down and sacrificial goats were needed.
 
A beautiful sentiment but one that doesn't always fit the realities of the working world. CYA should be written in golden letters a foot high on every wall. You want to do the very best IT work? Don't worry about CYA. You want to keep that roof over your head? CYA CYA CYA.

Well, that can be when it does become a problem of personnel in addition to whatever underlying problems there was. Plenty of times here where CYA has got someone OTD (Out The Door). With hundreds of thousand and even millions of dollars of product, production equipment and even just production time at stake as well as toxic gasses, hazardous chemicals and high energy equipment "It's a factory, **** happens" (as one of our techs once said to me after being involved in the destruction of a critical production element) just doesn't cut it. If you're honest and open about what happened then perhaps we can find and address the actual problem. If CYA is all you've got to contribute to finding the actual problem then you can be an additional problem that needs to be resolved as well. Again this isn't strictly just IT work (robotics and such in an often hazardous production environment) so YMMV.

ETA: For example someone screwed up in a simple recovery taking down a whole section of the factory. Because they wouldn’t just admit and say what they had done it took almost half the day to figure out what had happened and fix it. If they had said exactly what they had done and where it might have been 15 – 20 minutes of down time. I wasn’t in that day but heard about it later. Because of their inability to honestly participate in the problem resolution, they were dismissed that day. I ran into the person some time later (working for another company) an asked “What happened?” because they were generally a straight forward and honest person. They said they didn’t know why but for some reason they just couldn’t bring themselves to admit what had happened.
 
Last edited:
TragicMonkey isn't say CYA to the extent of not doing your job, if you read a few of his decorous rants you will see his CYA is about making sure he documents what he has been told to do, by whom and what the affect may be. He means don't be the one that can't show that they did as instructed by a "boss".
 
TragicMonkey isn't say CYA to the extent of not doing your job, if you read a few of his decorous rants you will see his CYA is about making sure he documents what he has been told to do, by whom and what the affect may be. He means don't be the one that can't show that they did as instructed by a "boss".

I understand that, however my point wasn't about one not doing their job. It was about making a mistake or being involved in some kind of other failure and trying to CYA as opposed to honestly helping to find the problem. If procedures or instructions were the root cause then demonstrating that is honestly trying to fix the problem, as well as helping to revise them. While not a direct boss, just a shift lead, my decades of experience often means I'm the one that writes instructions or procedures as well as does the training. 'If you screw up, as plenty of us have around here, just be honest and open about it' is part of that training and can just help you still keep your job. As I usually also relate some of the stories like the ETA before.
 
Appeals to "Just fix the problem" when the problem isn't our problem to fix is the problem.

I mentioned this earlier, getting the whole "Oh we're all on the same team here" speech whenever I push back on doing things outside the scope of m job.

I'm a contractor. We're not "on the same team here." My company and their company have a contract, an agreement, outlining the kinds of services I provides. I don't deserve a corporate speak guilt-trip about teamwork when I acknowledge that.

When your mechanic doesn't agree to drive you to a concert 3 cities over in two weeks because he's a mechanic, not a chauffer you don't go "Oh we're on the same team! Can't you just focus on fixing the problem of me not having a way to get to my concert? After all you're a car guy; fixing it, driving them, all the same."
 
Last edited:
TragicMonkey isn't say CYA to the extent of not doing your job, if you read a few of his decorous rants you will see his CYA is about making sure he documents what he has been told to do, by whom and what the affect may be. He means don't be the one that can't show that they did as instructed by a "boss".

Indeed. I usually end up being the Cassandra of the team: I predict disaster if a decision is made a certain way, the boss doesn't listen, I document this very carefully, then when it blows up in their face and they want to blame the underlings I can so sweetly, so kindly, so gently pull out all the rope they used to hang themselves. My last boss but two was so dreadful at this sort of thing she actually said in an email that a mistake she made was my fault because, and I quote, "you should have known I didn't know what I was talking about when I told you to do that". Before that I had her initial instructions in an email, confirmed those instructions in another email where I listed out the consequences, then I verbally confirmed those instructions twice more in front of witnesses just to be sure. I never had to do anything with that email, but you can be sure I kept it just in case "my" mistake was ever brought up in a performance review.
 
Appeals to "Just fix the problem" when the problem isn't our problem to fix is the problem.

I mentioned this earlier, getting the whole "Oh we're all on the same team here" speech whenever I push back on doing things outside the scope of m job.

I'm a contractor. We're not "on the same team here." My company and their company have a contract, an agreement, outlining the kinds of services I provides. I don't deserve a corporate speak guilt-trip about teamwork when I acknowledge that.

When your mechanic doesn't agree to drive you to a concert 3 cities over in two weeks because he's a mechanic, not a chauffer you don't go "Oh we're on the same team! Can't you just focus on fixing the problem of me not having a way to get to my concert? After all you're a car guy; fixing it, driving them, all the same."

Even if you do work for the same company, different departments have different tasks to be done. Sure, in a perfect world I'd have plenty of time to help out other people. But my stuff needs to get done, and my own team's needs take precedence. I can't let my team's project fall behind just because Nancy from Accounting fell off the toilet and is wedged in the stall covered in her own pee, shrieking for help. This data isn't going to query itself! I'm just kidding, of course. If that actually happened I'd be standing outside the ladies room door recording the audio for the internet and/or a new ringtone.
 
Your scenario was farcical. You might as well asked how I would do it if there was a person standing behind them holding a gun loudly declaring that they would shoot them if they asked how to resize an Excel document.

And even if your scenario was true it still wouldn't be my problem if, through some insane scenario Google was not available to them and it was because of the way the customer wants their system set up.
So you replaced my farcical scenario with one of your own ...

What I'm seeing here is an "attitude." "If you haven't picked up a little piece of knowledge that I happen to know you're obviously an idiot who doesn't deserve the time of day." Have you ever considered the possibility that people sometimes get thrown into jobs where for whatever reason they haven't yet acquired the full skill set they need to do it?

"I can't charge my phone on my computer, fix it" when the answer is "Because your boss, my client, asked that USB port security be enable" is also not my problem.

"My computer only works within the perimeters my company has tasked IT to let/make it work" IS NOT MY PROBLEM.
The above two examples show the user can't do something because it's forbidden by policy. Of course the only response is "Sorry, I can't help you because I don't set policy."

The original problem was a user who didn't know how to do something that was possible to do, a situation you can assist with. For me, I'm willing to help—the first time. Maybe the second time, too, but at that point I'll try pointing the user to resources they can consult instead of asking a person for help. After that I'll seriously consider asking them to consult the documentation I pointed them to earlier.
 
Last edited:
The original problem was a user who didn't know how to do something that was possible to do, a situation you can assist with.

You're still trying to make "That's not my job" into something unreasonable and evidence of me having "an attitude."
 
You're still trying to make "That's not my job" into something unreasonable and evidence of me having "an attitude."
Many years ago (I may have told this story before) on my first Service Desk job we got a call about a sparrow trapped in the stairwell. Ever since then, "a sparrow in the stairwell" has been my euphemism for any request or task that is wildly out of scope.
 
Many years ago (I may have told this story before) on my first Service Desk job we got a call about a sparrow trapped in the stairwell. Ever since then, "a sparrow in the stairwell" has been my euphemism for any request or task that is wildly out of scope.

Well obviously you need to drop the attitude and be a team player.
 
Status
Not open for further replies.

Back
Top Bottom