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

Status
Not open for further replies.
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.

"Your department needs to authorize the additional expense for sparrows before we can do anything. You'll get a quote through the ticketing system."

Pity, really, that it was a sparrow: if they'd selected "small bird (unknown)" from the dropdown it would have been cheaper, but sparrows are specifically charged higher. That's out of my hands, it's a finance decision.
 
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.

I know a place where the current IT ticket system has ticket in there that's a bit out of scope. The network team had a group under it for analyzing/configuring web traffic.

So the ticket asked the "traffic" team if they can get a taxi from the office to the airport at 3:15. The ticket wasn't closed until after that time though. I hope he was able to make his flight.
 
Are colleagues that screw you over through carelessness worse than ones who do it maliciously ?

Sent from my SM-G973F using Tapatalk
 
Are colleagues that screw you over through carelessness worse than ones who do it maliciously ?

I wouldn't think so. Carelessness is annoying, but active malice is a threat. Depending on the circumstances it's certainly possible for a careless error to cause more damage than a malicious one, but generally I'd have to say if someone has a specific intent to cause you harm they are the worse villains.
 
Also carelessness doesn't tend to get worse with time. "Trained Helplessness" does.

That's why I don't help my customer base with minor tasks that aren't my job. It trains them to expect me to do their job for them and they WILL within a metaphysical certainty start coming to you to do more and more of their job if you do that.
 
Also carelessness doesn't tend to get worse with time. "Trained Helplessness" does.

That's why I don't help my customer base with minor tasks that aren't my job. It trains them to expect me to do their job for them and they WILL within a metaphysical certainty start coming to you to do more and more of their job if you do that.
Yep.

We get the same sort of thing here. Some staff who need "IT help" for just about anything computer or telecommunications don't start by phoning our expensive Helpdesk people. They start by phoning the IT person who chatted to them in the canteen who advised them how to adjust the width of their Excel columns. Their rationale is that that IT person must know EVERYTHING! about IT and phones if they can do that. And it's MUCH faster for them to get a result through that person directly than work through the arcane and slow Helpdesk system. In short, they are taking the easiest path out.

So much so that I have had calls from people two jobs and three years previously asking for help (with Excel column sizing, no less).
 
Norman Alexander said:
Also carelessness doesn't tend to get worse with time. "Trained Helplessness" does.

That's why I don't help my customer base with minor tasks that aren't my job. It trains them to expect me to do their job for them and they WILL within a metaphysical certainty start coming to you to do more and more of their job if you do that.
Yep.

We get the same sort of thing here. Some staff who need "IT help" for just about anything computer or telecommunications don't start by phoning our expensive Helpdesk people. They start by phoning the IT person who chatted to them in the canteen who advised them how to adjust the width of their Excel columns. Their rationale is that that IT person must know EVERYTHING! about IT and phones if they can do that. And it's MUCH faster for them to get a result through that person directly than work through the arcane and slow Helpdesk system. In short, they are taking the easiest path out.
So much so that I have had calls from people two jobs and three years previously asking for help (with Excel column sizing, no less).

Well, they're being human for doing so ...

Both the highlighted points make a good reason not to assist people with "quick" little fixes. For me, however, not helping someone with something I'm familiar with goes against my nature. And if the person I assisted starts becoming a nuisance, I can politely but firmly inform them what I did was a one-off as a favour and from now on they should be looking at other venues for help, such as documentation or the help desk.
 
Our new ServiceNow environment is extremely transparent to the users, and they have a lot of access to information than they did before. Part of what I do now is to help people to use the new tools that are available to them. I'm not required to, and strictly speaking teaching them how to use these tools isn't my job, but I do so because in the end it will make my job easier.
 
Well, they're being human for doing so ...

Both the highlighted points make a good reason not to assist people with "quick" little fixes. For me, however, not helping someone with something I'm familiar with goes against my nature. And if the person I assisted starts becoming a nuisance, I can politely but firmly inform them what I did was a one-off as a favour and from now on they should be looking at other venues for help, such as documentation or the help desk.
Oh we tried that. But they have the numbers on a Post-It note stuck to their monitors. So there's no hope of ever changing their behaviour short of actually dying or changing the whole phone system.
 
Don't you need local SME's to resolve those things?

Again I'm done explaining to people why you shouldn't go to your mechanic everytime you need to change your car's radio station.

Things the user should be expected to just know to do their job is not this complicated and only in IT do we pretend it is, again all because of this stupid idea that it's perfectly logical for people who see computers as this mystical totems beyond their understand to gets jobs that require their constant use.

If your doctor was "Tee hee, coy coy Oh I'm just not a human body person" about everything you'd get a new doctor. You wouldn't sit there while he called a biologist to explain it to him and essentially do his job for him.
 
Last edited:
Can I try an analogy? 100 years ago office workers didn't think they "weren't ink people" and asked for help dipping a nib in an inkwell or sharpening a pencil again. They knew the basics of *using* the tools of their trade. They'd gone past the days if cutting their own goose quills and expected proper pens with metal nibs which they didn't make or know how to make.
 
Can I try an analogy? 100 years ago office workers didn't think they "weren't ink people" and asked for help dipping a nib in an inkwell or sharpening a pencil again. They knew the basics of *using* the tools of their trade. They'd gone past the days if cutting their own goose quills and expected proper pens with metal nibs which they didn't make or know how to make.

No they didn't. I have not yet encountered a "Oh I'm just not an X person" for literally anything but computers within anything fairly comparable to this context.

I know plenty of "Oh I'm just not into sports" people. The difference they don't get jobs as sports commentators and just expect that to somehow workout. Well maybe Deadspin who's entire business model seems to be "What if we had a sports blog, but like written by people who hate sports?"

But in seriousness only with computers can you get a job that requires you to constantly use something and then loudly declare that you don't understand them and have no intentions of ever learning how to understand them and still expect to keep the job.
 
Last edited:
Our new ServiceNow environment is extremely transparent to the users, and they have a lot of access to information than they did before. Part of what I do now is to help people to use the new tools that are available to them. I'm not required to, and strictly speaking teaching them how to use these tools isn't my job, but I do so because in the end it will make my job easier.
Management probably hopes it'll make your job so much easier they won't need you any more.
 
Can I try an analogy? 100 years ago office workers didn't think they "weren't ink people" and asked for help dipping a nib in an inkwell or sharpening a pencil again. They knew the basics of *using* the tools of their trade. They'd gone past the days if cutting their own goose quills and expected proper pens with metal nibs which they didn't make or know how to make.

The Ink People sounds like either a really good indie band or a really bad horror movie.
 
Can I try an analogy? 100 years ago office workers didn't think they "weren't ink people" and asked for help dipping a nib in an inkwell or sharpening a pencil again. They knew the basics of *using* the tools of their trade. They'd gone past the days if cutting their own goose quills and expected proper pens with metal nibs which they didn't make or know how to make.
Pen and ink is not analogous to computers. The thing that computer people consistently overlook or simply cannot understand is that the vast majority of people simply aren't computer people, as the tools are currently conceived of, designed, and intended to be used. It's not even a question of whether they grew up with computers. The things are just not as straightforward and intuitive as we the five percent think they are. We the five percent who naturally grok this stuff and take it for granted that everyone else can do the same.

And it's not something that can be entirely solved by just telling people to figure out how to computer better. A lot of people are already at their limit, just doing simple, predefined tasks by rote.

https://www.nngroup.com/articles/computer-skill-levels/
 
This is happening right now. The level of detail is exactly as presented here:

DEVELOPER: I have my build automation set up with credentials for my code repository. But the job gets a credentials error. Can someone here help me with this issue?

ME: It depends what the issue is. What is the job trying to do? What happens when it tries?

DEV: It's trying to download a module.

What I'm actually trying to get at, without spelling it out like the guy is five years old, is, "what command is triggering the error, and what error is triggered?" To me, this is absolutely basic, obvious, computer troubleshooting 101. I assume that every software developer is familiar with the debugging process of "read error message, figure out what caused it, figure out how to address the cause".

But apparently this guy simply does not think that way. It does not occur to him to provide, or even think about, basic technical details of the problem. I figure there's at least a 50% chance that if he actually reads the error function call and the error message together, the solution will be obvious and easy to apply. I figure there's at least an 80% chance that I'll understand the problem and its solution instantly, the moment he provides those to snippets of text. Even though right now I know absolutely nothing about the actual details of his setup or goals.
 
Your example in the above post is so far away from the examples in this thread I despair. I entirely get domain knowledge. I don't expect application programmers on z/OS to know the RTM2WA. Again and again and again he expects people who's job requires basic office skills to have basic office skills.
He's not talking about the vast majority of people. He's talking about that subset of people whose jobs require basic office skills, the advertised requirements of said jobs specify basic office skills.
 
This is happening right now. The level of detail is exactly as presented here:

DEVELOPER: I have my build automation set up with credentials for my code repository. But the job gets a credentials error. Can someone here help me with this issue?

ME: It depends what the issue is. What is the job trying to do? What happens when it tries?

DEV: It's trying to download a module.

What I'm actually trying to get at, without spelling it out like the guy is five years old, is, "what command is triggering the error, and what error is triggered?" To me, this is absolutely basic, obvious, computer troubleshooting 101. I assume that every software developer is familiar with the debugging process of "read error message, figure out what caused it, figure out how to address the cause".

But apparently this guy simply does not think that way. It does not occur to him to provide, or even think about, basic technical details of the problem. I figure there's at least a 50% chance that if he actually reads the error function call and the error message together, the solution will be obvious and easy to apply. I figure there's at least an 80% chance that I'll understand the problem and its solution instantly, the moment he provides those to snippets of text. Even though right now I know absolutely nothing about the actual details of his setup or goals.

Unfortunately I deal with varieties of this one every day.
Not from developers, but from the userbase of the application that I support.

I see a general unwillingness to read any error message, and a pathological unwillingness to capture the error message and provide it to me.

NB. The application displays a button to copy the error.

But no, no screen shot (or description) of what the user is trying to do, no screenshot or copied text of the error.

I use Splunk to dig into the applications logs by the ID of the user that generated the error.

Imagine my joy when the error turns out to be things like typos in the userId, resulting in "User ID not found" or the user's password resulting in "User ID or password not correct".

Even more when I discover a gigabytes of .pdf files in the users windows profile, resulting in complaints that "XXXXX is running slowly"
 
Your example in the above post is so far away from the examples in this thread I despair. I entirely get domain knowledge. I don't expect application programmers on z/OS to know the RTM2WA. Again and again and again he expects people who's job requires basic office skills to have basic office skills.
He's not talking about the vast majority of people. He's talking about that subset of people whose jobs require basic office skills, the advertised requirements of said jobs specify basic office skills.
I'm saying that most computering that we consider basic office skills, that has been marketed and normalized as basic office skills, really isn't. It's skills that require a basic computer aptitude that most people don't actually have. It's stuff a lot of people can't learn without a lot of effort, and even then some of them will never learn it well or even at all.
 
Status
Not open for further replies.

Back
Top Bottom