Dear Users... (A thread for Sysadmin, Technical Support, and Help Desk people)

[JoeMorgue]

Originally Posted by Wudang

And isn't that exactly what he's complaining about? Those people asking for help with the "actual programs" because "they're not computer people"?

Yes but for some reason it seems the narrative for some has to be when an IT person doesn't want to do a user's job for them they are either being unprofessional, aren't being grateful enough that the users are giving them work to do, or that it is their job and they should stop complaining and they aren't special.

[P.J. Denyer]

- If you've been using your deleted items folder to store emails you haven't dealt with yet and they've been deleted in a server clean up then yes, one of us does have a problem, but no it isn't me. (Real case)

- If you remove one of the columns in your folder display regularly every two or three weeks, just maybe you should learn the two or three clicks to replace it rather than call me every time.

- If I've come up to your desk because you've reported your printer doesn't work, I've fixed it (by flicking the 'on' switch) and printed a page to demonstrate it works, don't then turn the printer round into a position where you can't open the paper tray properly and jam it stuffing half a ream in and then sit silently for two days before claiming to your manager that I ignored your call.

- If another company's website is down I can't fix it for you. No, not even if it's Barclays Bank. (From a man who used to be director of an ISP)

- If your screen is completely blank try turning it on before reporting your computer is broken (from the same ex-isp director)

- Buying at least one new phone every three months and installing the proprietary Outlook integration for every single one while never removing any of them probably will cause strange behaviour. (Less of an issue now than when I was doing the job of course).

And finally, the reason I ended up leaving IT

-To senior management. I am expected to support our product for customers, they report bugs, development will only look at bugs that are reproduced in-house. You have released Apple versions of our product but will not fund any Apple hardware, software, training, or personnel. How do you think that's going to work out?

[arthwollipot]

Dear users:

Use email only when you really need to. Email is perfect for communicating a large amount of technical information. It is really awful for urgent requests. Generally, the same agents will process both phone calls and emails, and they can’t do both at the same time. If you phone the service desk and are placed in a queue, it is not going to be quicker to send an email, because all of the people who might be able to answer your email are busy taking phone calls! Use email for non-urgent technical requests.

The other problem with email. If you don’t provide all of the relevant information in your initial email, all it will do is create a series of back-and-forth messages that waste the agents’ time and your own. If you must use emails, make sure you provide all of the relevant information up front.

[Wudang]

And sending a blurry screenshot with a san serif font that doesn't distinguish "1"s and "l"s etc is suboptimal.

eta: One of the killers features of OneNote for me was being to paste the screenshot on OneNote and let it be automatically OCRed so I could paste the text in google/Stackoverflow/etc.

[arthwollipot]

We have a screen clipper in the SOE, so most people know how to use that. On the other hand, we have on occasion received a photograph of the screen.

[Hellbound]

Originally Posted by Dancing David

Dear User
You little essay about how desperately you need something done, often because you did not follow directions, is not going to change your position in the work order line.

My favorite saying is a variant of that sentiment:

"Your poor planning is not my emergency."

[Dr. Keith]

Originally Posted by Hellbound

My favorite saying is a variant of that sentiment:

"Your poor planning is not my emergency."

I used to say that. Now I'm paid to be available whenever, so I typically say:
"It will take me ten minutes to get back to my computer and start getting you an answer. Will that work?"

Usually I say this as I walk out of whatever store I was in or am pulling off the road to turn back towards home. I thought it would be a short term gig when I agreed, 18 months later they keep sending the checks so I keep saying "how high!"

If they are willing to pay me for 18 more months I will be quite happy to drop everything when they call.

[theprestige]

- Your tool talks to my service. If your tool is saying the wrong things, that's your problem, not mine. Leave me and my service out of it.

- Look, it's your tool. You were hired because of your expertise with the problem space covered by this tool. You chose this tool, to do your job, not me. I have no idea what your tool is supposed to say, or how it is supposed to say it. Figure it out.

- Okay, you know what? I just spent ten minutes googling your tool. I now know how to make it say what you need it to say. Something you should have already known. I'm now doing your job for you. SMH FML.

- My service still isn't working for you? Did you make the changes I googled and sent to you? No? Die in a fire.

- Hi, I figured I'd swing by your campus and see if we can't clear up the lingering issues you're having with my service your tool...

[Dr. Keith]

Originally Posted by theprestige

- Your tool talks to my service. If your tool is saying the wrong things, that's your problem, not mine. Leave me and my service out of it.

- Look, it's your tool. You were hired because of your expertise with the problem space covered by this tool. You chose this tool, to do your job, not me. I have no idea what your tool is supposed to say, or how it is supposed to say it. Figure it out.

- Okay, you know what? I just spent ten minutes googling your tool. I now know how to make it say what you need it to say. Something you should have already known. I'm now doing your job for you. SMH FML.

- My service still isn't working for you? Did you make the changes I googled and sent to you? No? Die in a fire.

- Hi, I figured I'd swing by your campus and see if we can't clear up the lingering issues you're having with my service your tool...

I for one would not be at my office after receiving that last message. Sorry I missed you, tool at reception!

[theprestige]

Originally Posted by Dr. Keith

I for one would not be at my office after receiving that last message. Sorry I missed you, tool at reception!

I deliver the last message in person, as I walk into their office and begin handholding them through one of the most basic tasks in their job description.

[Dr. Keith]

Originally Posted by theprestige

I deliver the last message in person, as I walk into their office and begin handholding them through one of the most basic tasks in their job description.

With a fairly convincing smile the whole time? Ninja.

[theprestige]

Originally Posted by Dr. Keith

With a fairly convincing smile the whole time? Ninja.

The acme of the IT art is that your users love you as much as you hate them. A house call to an idiot is gold in the brownie point bank.

And brownie points are the currency with which are bought promotions and bonuses and expensed trips to the big conventions.

My smile is the best.

[Dr. Keith]

Originally Posted by theprestige

The acme of the IT art is that your users love you as much as you hate them. A house call to an idiot is gold in the brownie point bank.

And brownie points are the currency with which are bought promotions and bonuses and expensed trips to the big conventions.

My smile is the best.

Their ignorant bliss is like a protective bubble.

I bet your smile sells convention approvals.

[arthwollipot]

I just took a call with someone who had a problem with a tool provided by a third-party contractor. I actually had to tell them that they need to get in contact with the third party about it.

[xterra]

I just dealt with someone who has used computers for maybe 30 years and does not know how to change from one window to the other (in this case MS Word to Chrome and back). This is the third or fourth time I have explained the process in the past several months.



Unfortunately, this person is my partner.... Who uses the "I'm old" excuse. Wonderful, but we are only two years different in age.

[arthwollipot]

I'd just like to say. The vast majority of my callers are super cool. And they only call when they genuinely need to, they follow instructions, and are generally a pleasure to talk to.

But just one ****** call can ruin your whole day.

[Dancing David]

Originally Posted by Hellbound

My favorite saying is a variant of that sentiment:

"Your poor planning is not my emergency."

I agree, however the end users are the main focus.
I find it amusing or annoying> I have one end suer I like as a human being, quite a lot.

However the over dramatic emails are very frustrating

[theprestige]

True, my users run the gamut. I have users who know their tools and their problem space backwards and forwards. They know more about how my service works than I do. Those users are a pleasure to work with, and make my job worth doing.

And then I have other users who are clearly taking a cargo-cult approach to their job, adopting bits and pieces of processes from other users, without really understanding what those processes are for or how they work. And then instead of going back to their teammates, or the source of the process they're using, they come to me. The perception seems to be that because I run the service they're trying to use, my job description must also include training them to do their job and coaching them on the right way to use the processes established by/for their team.

Of course, my job description includes nothing of the sort. That's what they have teammates and managers of their own for. So I end up with the impression that there are managers within my organization that are in the habit of hiring unqualified people, and then not doing their own job of managing the people they hire.

Unfortunately, professionalism and the need for a steady paycheck mandates that I enable this bad behavior to some extent. This naturally results in a certain amount of frustration and a need to occasionally vent.

I think Elagabalus and Giordano have wildly misunderstood the nature of this thread, and are way out of line with their nannying. If you're not an IT professional, here to commiserate with other IT professionals about the characteristic frustrations of our line of work, you're part of the problem: Users who don't understand or respect IT professionals, and don't mind making that attitude clear.

[theprestige]

Originally Posted by Sideroxylon

These people keep people in jobs.

That's the broken window fallacy.

People who don't make a reasonable effort to understand common computer tasks related to their job, waste time and money through inefficiency. These resources could be put to more productive use, if they were freed up by the user who's wasting them on willful ignorance.

Likewise, there are a lot of interesting and complex challenges in IT, productive work that could be done, if IT professionals were not bogged down compensating for - and enabling - willful ignorance among their user base. Every hour I spend coaching someone on basic tasks in their job description, is an hour I fall behind on clearing my organization's technical debt. And technical debt is always accumulating.

"Your stupidity keeps me employed" is at best a silver lining view of what's actually a wasteful and demoralizing situation.

[arthwollipot]

A little bit of training can save a lot of work later.

I once spoke to a person who was complaining that the formatting in some parts of her document were changing based on how she was formatting other parts of the document. I asked her if she knew how Styles worked, and she said "I don't need to know about that".

Well, yes you do, because it is the reason you are having a problem. If you understood how auto-updating Styles worked in Word, then you would not be experiencing the problem. You'd know what it was doing and why. But because you "don't need to know about that", you are wasting your own time - and mine - because you didn't bother to educate yourself about the tool that it's your job to use.

[Norman Alexander]

Originally Posted by arthwollipot

A little bit of training can save a lot of work later.

I once spoke to a person who was complaining that the formatting in some parts of her document were changing based on how she was formatting other parts of the document. I asked her if she knew how Styles worked, and she said "I don't need to know about that".

Well, yes you do, because it is the reason you are having a problem. If you understood how auto-updating Styles worked in Word, then you would not be experiencing the problem. You'd know what it was doing and why. But because you "don't need to know about that", you are wasting your own time - and mine - because you didn't bother to educate yourself about the tool that it's your job to use.

What's this wheel in the front seat of the bus?

The big one that makes the bus go right and left?

I don't know, I just drive it, so I don't have to learn what it does. Can you come here and do it for me?

[rdaneel]

Originally Posted by Norman Alexander

What's this wheel in the front seat of the bus?

The big one that makes the bus go right and left?

I don't know, I just drive it, so I don't have to learn what it does. Can you come here and do it for me?

(A short while after an exasperating training session)

I was driving along and the bus just stopped suddenly, now I can't even get it to start. I don't understand, it was fine yesterday.

What does the fuel gauge say?

Which one is that?

...

What's that noise on your end? it sounds like something smashing against a wall.

[Dancing David]

Originally Posted by Norman Alexander

What's this wheel in the front seat of the bus?

The big one that makes the bus go right and left?

I don't know, I just drive it, so I don't have to learn what it does. Can you come here and do it for me?

HA HA HA

[JoeMorgue]

Again we're all having a jolly laugh but that's exactly the mentality IT support people are supposed to operate under, being on call support/disaster recovery/end user training/just doing to user's job for them/etc people with no rhyme or reason and as evidenced by this thread called unreasonable or unprofessional for pointing it out.

We're supposed to be the guy who fixes your car, teaches you how to drive it, drives you wherever you want to go whenever you find a function on your car you never bothered to learn, and do the insurance adjustment when you total your car.

[theprestige]

If you like this thread, you'll love this subreddit.

[xterra]

Originally Posted by xterra

https://old.reddit.com/r/talesfromtechsupport/

Originally Posted by theprestige

If you like this thread, you'll love this subreddit.

Yes, well worth reading, not just for the head-shaking factor, but because the participants come up with some very interesting solutions, technical and non-technical.



(I posted that link on Aug 30. No one responded to it, so I thought I'd respond to your posting of it so you wouldn't feel alone.)

[Dr. Keith]

Originally Posted by xterra

Yes, well worth reading, not just for the head-shaking factor, but because the participants come up with some very interesting solutions, technical and non-technical.



(I posted that link on Aug 30. No one responded to it, so I thought I'd respond to your posting of it so you wouldn't feel alone.)

I didn't respond because I lost the rest of my day going down that rabbit hole.

[arthwollipot]

Good morning, Service Desk, this is Andrew speaking. How can I help?

Ah, hi. Yes. I need a dongle please.

*beat*

I'm sorry, can you explain a little further?

Yes, I need a dongle for the department's IP address.

*beat*

You need a... sorry?

Turns out they needed a wireless broadband modem so that they could access a website being developed by a third party, while working remotely from home. The developers restricted the website to be accessible only by departmental IP addresses, so when operating via DTA on her home network she didn't have the correct IP address to access the site. But it took quite a few minutes of pulling teeth to determine this information. All she had been told was "You need a dongle. Call Service Desk to get one."

[Tolls]

That's not really her fault, of course.
It's the old "whisper the mystical incantation" idea that seems to pervade some places.

Either that or Python:
"One of cross beams has gone out skew on treddle."

[arthwollipot]

Originally Posted by Tolls

That's not really her fault, of course.
It's the old "whisper the mystical incantation" idea that seems to pervade some places.

Either that or Python:
"One of cross beams has gone out skew on treddle."

Right, but it's not hard to learn the correct names for things. This particular one confused me because I'm old enough to remember the original meaning of the word "dongle", which was a pass-through device that plugged into the serial port of the computer that allowed proprietary hardware to operate. It was some time before I remembered that people use the word to refer to wireless broadband modems.

[Tolls]

Originally Posted by arthwollipot

Right, but it's not hard to learn the correct names for things.

Ah, well it would be hypocritical of me to complain about things like that as I'm hopeless at remembering the names of things. And don't get me started on bloody acronyms. I do wonder why I'm in this job sometimes...

As for dongle, yes it does seem to have morphed into "anything that plugs into a computer". I suspect that some bright spark noticed that the not very big thing going into a computer (in that case the serial port as you say) was called a dongle, so this thing going into the computer that's not very big must also be called a dongle. Again, the "mystical word" thing.

[theprestige]

I think this is related to the problem of "solutioning".

In general, IT folks operate best from a clear problem description, which they can evaluate to determine the cause and the solution. It doesn't even have to be a technical description. As long as you can describe in your own words what you're trying to do, what you expect, and what happens instead, your IT guy should be good to go.

Screen shots and error messages - verbatim! - can be used here to fill in the technical gaps in your description.

It's when you try to describe a *solution* that things go off the rails.

[Wudang]

Originally Posted by theprestige

It's when you try to describe a *solution* that things go off the rails.

Exactly. This has been known for decades and is one of the drivers for agile development recording user stories.

[JoeMorgue]

I would argue about... half my time is trying to pull what the actual problem out of a user that only wants to keep saying some minor variation on "It doesn't work" over and over.

[zooterkin]

Originally Posted by Wudang

Exactly. This has been known for decades and is one of the drivers for agile development recording user stories.

Despite having been in IT for nearly 40 years, I have no idea what the highlighted phrase means.

[theprestige]

Originally Posted by zooterkin

Despite having been in IT for nearly 40 years, I have no idea what the highlighted phrase means.

The basic idea is that there are two broad paradigms for software development. The older paradigm, prevalent for many years, went something like this:
1. Define requirements.
2. Spend a year developing software to meet those requirements.
3. Release the software all at once.
4. Discover all the bugs and all the missed requirements and all the implemented requirements that nobody actually wanted.
5. Define new requirements.
6. Spend a year...
Etc.

This paradigm was called "waterfall" software development, for some reason. Probably because you can visualise the process as a cascade of activity, Requirements > Development > Discovery.

The waterfall paradigm made a lot of sense in the days when software came on physical media. You'd buy a disk, insert it in the computer, install the software, and use it warts and all until the new version came out next year. Then you'd upgrade, and hope that the new version had more useful features and less bugs than the previous version. Mostly this worked.

But as we moved into an age when more and more software was running as a service over the Internet (Turbotax Online, for example), software companies realized they didn't necessarily have to wait six months or a year for a new version. They could fix bugs and add features as they were discovered. You could update your service every six weeks, or every six days. Or every six hours. And being able to produce beneficial updates quickly gave you an advantage over your competition.

But to do that well, a new paradigm was needed. The new paradigm needed to have a system for breaking down software development into small tasks that could be completed quickly, tested quickly, and released quickly. And, in order to be valuable, the new system had to link these tasks to specific tangible benefits to your users.

The implications of such a system are literally paradigm-shifting. Instead of your software developer laboring for a year on a massive code base, making hundreds of changes without really knowing if they're useful or wanted or even simply not harmful; your software developer can labor for a week on something he knows is desirable, and at the end of the week he can test it and know that it's working as intended. Shortly thereafter, that improvement that customers actually want - the bug fix, the new feature - can be released, and customers can be made happier thereby. This is, in a word, *awesome*.

And this awsomeness hinges on knowing what customers want. You know there's a bug that affects database performance, but have your customers even noticed that? Or are they all clamoring for a delete button that warns them before they delete stuff? Gathering that customer feedback, and using it to decide which development goals to prioritize, is critical to the success of the system.

This new paradigm is called "agile" software development, probably because it's the same basic cycle of activity as the waterfall, but done at a much faster pace. Customer feedback about what they're trying to do and what they expect from your software is called "user stories". The phrase "recording user stories" is the agile paradigm's term for defining requirements.

A mature agile development team will usually have a Product Owner assigned or embedded with the developers. Their job is to gather the user stories, prioritize them, and bring them to the developers. The developers, armed with the knowledge of what the users want, are then responsible for breaking the requirements down into incremental development tasks that will produce real improvements as each one is completed.

One side effect of the agile paradigm is that it requires an acceleration of the entire software development lifecycle *and* of all the tooling required to get a piece of code from the developer's head onto the customer-facing website. When I started out in systems administration, I could leave a software QA server down for a week or two while I worked on more important tasks. What's a week or two of QA downtime, on a year-long development cycle?

But when that same cycle is supposed to run multiple times a day, and the developer has committed to having some good thing ready for customers by the end of the week, even an hour of QA downtime really hurts. So the entire pipeline has gotten more robust, more efficient, more fast.

And more automated. When you're cycling through the entire process multiple times a day, you can't just hand a guy an installer and some instructions and tell him to upgrade the server so they can test the new version. Instead, you fill your pipeline with robots that do all that automatically, on the fly, all day every day. Instead of telling your quality engineer to manually step through all of the testing processes, you tell him to write automated testing scripts using a standardized suite of tools, so that his expertise can also be applied continuously by robots, without having to wait for human intervention.

And that's basically my job: Administering an automated software delivery system, so that my developers can drop their code into a code repository, sit back, and let the robots do their job.

tl;dr - it means you start by finding out by what your customers actually want, so that when you give them stuff it's stuff you know they'll be happy to get.

[Dr. Keith]

Originally Posted by theprestige

The basic idea is that there are two broad paradigms for software development. The older paradigm, prevalent for many years, went something like this:
1. Define requirements.
2. Spend a year developing software to meet those requirements.
3. Release the software all at once.
4. Discover all the bugs and all the missed requirements and all the implemented requirements that nobody actually wanted.
5. Define new requirements.
6. Spend a year...
Etc.

This paradigm was called "waterfall" software development, for some reason. Probably because you can visualise the process as a cascade of activity, Requirements > Development > Discovery.

The waterfall paradigm made a lot of sense in the days when software came on physical media. You'd buy a disk, insert it in the computer, install the software, and use it warts and all until the new version came out next year. Then you'd upgrade, and hope that the new version had more useful features and less bugs than the previous version. Mostly this worked.

But as we moved into an age when more and more software was running as a service over the Internet (Turbotax Online, for example), software companies realized they didn't necessarily have to wait six months or a year for a new version. They could fix bugs and add features as they were discovered. You could update your service every six weeks, or every six days. Or every six hours. And being able to produce beneficial updates quickly gave you an advantage over your competition.

But to do that well, a new paradigm was needed. The new paradigm needed to have a system for breaking down software development into small tasks that could be completed quickly, tested quickly, and released quickly. And, in order to be valuable, the new system had to link these tasks to specific tangible benefits to your users.

The implications of such a system are literally paradigm-shifting. Instead of your software developer laboring for a year on a massive code base, making hundreds of changes without really knowing if they're useful or wanted or even simply not harmful; your software developer can labor for a week on something he knows is desirable, and at the end of the week he can test it and know that it's working as intended. Shortly thereafter, that improvement that customers actually want - the bug fix, the new feature - can be released, and customers can be made happier thereby. This is, in a word, *awesome*.

And this awsomeness hinges on knowing what customers want. You know there's a bug that affects database performance, but have your customers even noticed that? Or are they all clamoring for a delete button that warns them before they delete stuff? Gathering that customer feedback, and using it to decide which development goals to prioritize, is critical to the success of the system.

This new paradigm is called "agile" software development, probably because it's the same basic cycle of activity as the waterfall, but done at a much faster pace. Customer feedback about what they're trying to do and what they expect from your software is called "user stories". The phrase "recording user stories" is the agile paradigm's term for defining requirements.

A mature agile development team will usually have a Product Owner assigned or embedded with the developers. Their job is to gather the user stories, prioritize them, and bring them to the developers. The developers, armed with the knowledge of what the users want, are then responsible for breaking the requirements down into incremental development tasks that will produce real improvements as each one is completed.

One side effect of the agile paradigm is that it requires an acceleration of the entire software development lifecycle *and* of all the tooling required to get a piece of code from the developer's head onto the customer-facing website. When I started out in systems administration, I could leave a software QA server down for a week or two while I worked on more important tasks. What's a week or two of QA downtime, on a year-long development cycle?

But when that same cycle is supposed to run multiple times a day, and the developer has committed to having some good thing ready for customers by the end of the week, even an hour of QA downtime really hurts. So the entire pipeline has gotten more robust, more efficient, more fast.

And more automated. When you're cycling through the entire process multiple times a day, you can't just hand a guy an installer and some instructions and tell him to upgrade the server so they can test the new version. Instead, you fill your pipeline with robots that do all that automatically, on the fly, all day every day. Instead of telling your quality engineer to manually step through all of the testing processes, you tell him to write automated testing scripts using a standardized suite of tools, so that his expertise can also be applied continuously by robots, without having to wait for human intervention.

And that's basically my job: Administering an automated software delivery system, so that my developers can drop their code into a code repository, sit back, and let the robots do their job.

tl;dr - it means you start by finding out by what your customers actually want, so that when you give them stuff it's stuff you know they'll be happy to get.

Thank you.

I'm more familiar with "agile" as used in physical manufacturing, not software. This was very enlightening.

[arthwollipot]

Originally Posted by JoeMorgue

I would argue about... half my time is trying to pull what the actual problem out of a user that only wants to keep saying some minor variation on "It doesn't work" over and over.

Indeed. This is something that I'm usually very good at. That particular call stumped me, though. How are you with strong accents?

[Sideroxylon]

Originally Posted by arthwollipot

Indeed. This is something that I'm usually very good at. That particular call stumped me, though. How are you with strong accents?

People skills are under rated while having none is even part of the stereotype.

[Faydra]

And what you invariably get in new agile shops is people "waterfalling the sprint" because it's all they know. That's where my team is at currently. It's a work in progress. Sigh.