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

Status
Not open for further replies.
Plus, to be honest, my glasses may have been tinted by having to deal before with people who would find any excuse to not do their job. I may have mentioned before the dynamic duo of twits adminning the MQ server at the previous company that wanted to be invited to a meeting to even get a simple setting for your queue. Like, literally, at one point by sheer coincidence both me and my brother who was in another team sent a request for a queue on the same day. He wanted the messages to be persisted to the HD because they were important info from another app, me, I didn't because it was just "reset cache" stuff that wouldn't even be relevant any more after a few minutes. BOTH got an answer that it's against corporate rules and we need to schedule a meeting with them to explain why we need that setting so. Like, literally both X and not-X were against the rules according to them. And the more you'd try to be nice and accomodating, the more they'd waste your time.

And that's just scratching the surface of how much of a roadblock they tried to be. Even tried to insert themselves into planning the web server architecture, which was way outside their responsibility.

Meanwhile my friend who was in a third team, literally sent them an answer saying, "that's not your concern, it has already been approved that way by the architect, just do your job" and he just got it with no fuss.

So, yeah, that's the kind of experiences that colour my glasses, if you wonder why I get seriously butthurt about admins trying to tell me what I need to do as a developer :p
 
Last edited:
That is legit hilarious.

Not to him, obviously. Literally, my trying to explain in about a page of text which library is affected, which isn't, and such, instead of a simple "yes", "no" or "it will be fixed until tomorrow" is why I'm not on that team any more.

Well, less stress for me, so I can't complain :p
 
So, yeah, that's the kind of experiences that colour my glasses, if you wonder why I get seriously butthurt about admins trying to tell me what I need to do as a developer :p
Absolutely. Completely understand. I just think your butthurtedness was misdirected when you directed it at me, because that's not what I was doing at all. :D
 
Well, quite possibly, yes. We're not even in the same country, much less the same corporation, so yeah, different people, different styles and experiences.
 
Dear Users: think before you request something and make sure it's clear what you actually need. There is a huge difference between "Dataset A, in Format C" and "Dataset A about data that exists elsewhere in Format C". Either way I can't help you, but which poor bastards get stuck with it hinges on whether you're asking about data that's in a particular format or wanting data in that particular format.

It's like you're asking for "Report: French Language"; are you asking for a report on the French language, or a report in French? Or is it both: a report on the French language, in French?
 
Dear User: don't shoot the messenger. You asked for data that would show the effects of your giant new process, and I gave you the data you asked for. It's not my fault that your efforts yielded a 0.08% success rate. I'd be delighted to go through my query line by line so you may attempt to find an error in it, but I suspect you'd be better served by devoting your time to fixing your new process.
 
Dear User: don't shoot the messenger. You asked for data that would show the effects of your giant new process, and I gave you the data you asked for. It's not my fault that your efforts yielded a 0.08% success rate. I'd be delighted to go through my query line by line so you may attempt to find an error in it, but I suspect you'd be better served by devoting your time to fixing your new process.
:D:thumbsup:
 
"We need you to test these new patches thoroughly."
"Right, what do these patches actually do?"
"We don't know."

WTF!?!?
 
"We need you to test these new patches thoroughly."
"Right, what do these patches actually do?"
"We don't know."

WTF!?!?

Pffft. That's stupid. Everyone knows patches fix what the previous patch broke. No point in making them spell it out everytime.
 
Dear User: don't shoot the messenger. You asked for data that would show the effects of your giant new process, and I gave you the data you asked for. It's not my fault that your efforts yielded a 0.08% success rate. I'd be delighted to go through my query line by line so you may attempt to find an error in it, but I suspect you'd be better served by devoting your time to fixing your new process.

I'm reminded of when a support group at the Really Big Airplane company proudly proclaimed that they had taken one day out of the overall flow of the engineering release process. By taking two days out of my flow and adding one to theirs. Without consulting the people they were supposed to be supporting, of course.
 
I'm reminded of when a support group at the Really Big Airplane company proudly proclaimed that they had taken one day out of the overall flow of the engineering release process. By taking two days out of my flow and adding one to theirs. Without consulting the people they were supposed to be supporting, of course.

That sounds like <big bank> . IT support's request ticket system was designed to maximise the number of individual tickets for their KPIs instead of improving processes for their users. Say your team had a new task and needed access to something. The team lead had to raise individual tickets for each user. Someone with the slightest interest in user experience would have allowed a single form list all the IDs that needed access and then split them into individual work items, no. One small example of many.

They streamlined their unix (inc linux) support so much that the only way I would be able to request a fix for a memory leak in ssl would be to ask for a new server with a later version of websphere.
 
That sounds like <big bank> . IT support's request ticket system was designed to maximise the number of individual tickets for their KPIs instead of improving processes for their users. Say your team had a new task and needed access to something. The team lead had to raise individual tickets for each user. Someone with the slightest interest in user experience would have allowed a single form list all the IDs that needed access and then split them into individual work items, no. One small example of many.

They streamlined their unix (inc linux) support so much that the only way I would be able to request a fix for a memory leak in ssl would be to ask for a new server with a later version of websphere.
This is usually the sole reason why many stupid work practices exist. People do what makes their KPI's look best, even if what they do is stupid, illogical and bad business practices and they know it. But that's what they get paid for and puts food on their table - good KPI's.
 
I have no idea what KPI's are!
Key Performance Indicator. Aka KRI's (Key Reporting Indicator) and a whole bunch of other management-speek acronyms over the years.

For example (and this is true), one company I worked at made the salespeople meet a KRI (their acronym at that time) of maximising their sales to cost-of-sales ratio. Not sales volume or profit, the ratio, and their bonuses were tied to that one KRI. The intention was to get best value for advertising. The outcome was that the salespeople quickly worked out that if they all spent nothing on advertising and sold only one $5 widget each in the sales period, their KRI ratio was astoundingly excellent and their bonuses were assured. Didn't take long for that to change... ;)
 
Last edited:
Status
Not open for further replies.

Back
Top Bottom