Digital experience ('DEX') issues reported by employees, from the original report:
- 37% : Security/regulatory policies
- 37% : IT overwhelmed by number of issues that need resolving
- 35% : Lack of training for IT personnel
- 34% : Handling the shift to hybrid/remote work
- 32% : Increasing number of endpoints to manage
- 31% : Technology in place is not appropriate for supporting DEX
- 27% : Lack of knowledge around DEX
- 25% : Lack of budget to support DEX efforts
- 19% : Lack of buy-in from leadership around importance of DEX
- 2% : No challenges being faced
(with some snark: statistics on signup/login requirements before viewing published reports, and presenting statistics in images instead of tabular data formats were not reported)
So in other words, 95% of employees have unrealistic expectations with regard to IT? Anything less than PFM (pure friggin magic) will likely come up short in their view.
I take it you don't deal with enterprise environments much? The bar to clear for avoiding daily annoyance is really not that high. Yet, here's a list i can still remember after a decade:
- outbound http proxies sometimes falling for a few specific URLs but the issue was never debugged
- employee portal logging you out after a couple minutes of inactivity
- expenses claiming Web app which could've been 2 plain HTML forms but somehow required IE and was so bad I had "calm down after doing expenses" breaks
The bar is really around: don't actively make people angry.
-Web policies that actively prevent you from doing research in key company technologies (edit: fake example, but effectively it was on the level of a gun maker blocking searches on firearms)
-No budget for replacing/upgrading outdated computers that get absolutely crushed by memory hogging corporate nannyware. It's amazing how little you get done when it takes five minutes to open Excel
-Computers not arriving until well after the start date of new hires
-Outdated database access prograns that won't run on x64 systems (or better yet, are still run on terminals and the only viable means of export was printing...and yes I ran into that only a couple years ago in a Fortune 100)
I get a lot of this is outside the hands of IT to actually fix, but they're still "IT Problems" even if the root cause is shitty management
I wonder how many employees know when their employer outsources their IT operations to another company/country? Where you used to have experienced sysadmins and IT folks on-site maintaining systems and helping people out, now you have a catch-all call center for a dozen companies with a runbook that starts and stops at "please restart your computer."
I had a recent indecent where I needed a new screw for my work laptop. I walked up to the IT building on site and asked for one. They said they couldn’t get one unless I had a ticket. So I went back to my desk and opened a ticket with IT. It took almost an hour to talk to the person and then they wanted pictures of the missing screw hole. So I had to use my phone to take pictures and upload them to the support website. More waiting. Then I get a report back saying they recommended a complete clamshell replacement (for a screw!). I told them just give me a freaking ticket please. They finally did and I went to the on-site IT building and they put in a new screw in 2 minutes. But the whole process took almost 4 hours. Half a day wasted for a screw.
This was my experience too when working in IT for a little bit. Many were happy to just sort problems out there and then but I could clearly see they were being reprimanded by HR for fixing issues without tickets. However, there was one callous and jaded printer technician who basically wouldn't even speak to someone unless they had a ticket opened.
Why would HR care whether an IT support staff was following the IT team's ticket process? HR is there to recruit, help hire, help fire, explain benefits packages and vacation policy, sometimes address workplace personnel conflicts, sometimes help teams budget salaries, and so on. IT's policies are made and enforced by IT management/leadership. I've never heard of any company where HR had any input whatsoever into an internal engineering or support team's processes.
Different organizations have different structures and different distributions of responsibility. I could absolutely see some places having HR be the place where metric-based policies originated, even for the IT team—and even over the objections of the head of IT. Especially if it's a place where the head of HR is a VP/C-suite, but the head of IT is just a Director. (Shockingly, not everywhere sees IT as being as important as other divisions.)
They are not your friends, but also they very rarely have even ability to care about internal processes of various departments. As in, your boss may need HR to supervise as he is trying to take disciplinary action against what he perceives as you not following internal rules.
But HR themselves wont check whether you do jira tickets or whether you do something else. For HR, IT is one of many departments with own set of rules that HR does not get to decide.
It's been my experience that IT management want to see metrics and dashboards for everything. The want to be able to plan, allocate resources, and justify purchases and staff.
How many of these did we do, how many of those, how long did it take to close this type of ticket, etc. So while the technical people could fix things on the spot, they are not allowed to due to the demand for metrics and tracking.
I can see both sides of the debate, but there needs to be a good balance. We can get stuff done and provide metrics without too much overhead.
They wants metrics for everything but surprisingly they always refuse to measure the time people are using to fill those tickets and time spend in meetings everybody dislike.
Maybe, but I’ve noticed there’s a big difference in IT departments who will open a ticket for you/do it together, vs. ones who will only confirm that they won’t talk to you until you go back to your desk to open a ticket. I started my career in IT and have worked in both kinds. Some IT departments really have an us vs. the world mentality.
Needing tickets is just reality. Companies see IT as a cost center so they need to justify their existence, which they do with tickets. Creating tickets itself doesn’t need to be adversarial, but the process can be used to try to get people to leave you alone (or at least make it onerous to do so) if that’s what you want.
Around here, I as a support guy could theoretically open a ticket. But I'm shielded by policy, so users cannot call me directly. Instead they will reach a call center (same for emails) where tickets are written down, classified and assigned. It usually takes an hour from initial call until I even see the ticket.
When you see this, this is almost always a management vs IT issue, and you're just suffering the fallout of it.
With this said, if the management demands IT has tickets, this is something that must be reiterated to every employee. "If you go to IT without a ticket, they cannot and will not help you"
While you as an employee may not have been adversarial, it is extremely common for angry users demand help right now for their life ending issue that's more important than anything else in the world! You know, they need that PDF printed right now... While you happen to be working on the server that's keeping 100 other people from working.
I was the IT support tech who would input tickets for people instead of insisting they call/walk-in with a ticket. The result was management gaslighting my ticket numbers as artificially inflated and being highly critical of my work. Wound up on a PIP.
(Realistically, everyone outside the department knew me by name. They would call and ask for me any number of ways including outright lying. They'd tell me I was the sole source of any problems getting solved! "Everyone else in that department can't do a thing.")
Please just put tickets in before you reach out to IT and have the number ready. Print it off, even.
If you've ever worked in IT support, you know that the ticketing process is about the only thing that keeps the idiots at bay, spamming support directly with the most inane issues.
You may be quite adept with computer machines, but work a few days in IT support, and you'll understand why there is a ticketing process.
I think at least a part of that problem is that the usual support ticketing process infantilizes users. If you call in and the first question is along the lines of "is it plugged in? have you tried turning it off and on again?" then of course your next ticket will take that level of questioning into account. And call in even for a switched off monitor next time. Because they wouldn't ask that question if that wasn't their job to fix, right?
Also, of course users will try and fail to fix issues themselves. They should be applauded for the intent and empowered to be successful next time (if possible). Instead they are usually berated for failing and breaking stuff along the way. Which leads to the usual sheepish "I didn't do anything, I didn't touch it, it always was broken like that".
Of course there is a minimum number of imbeciles. But most people can be educated and empowered, so they do behave like adults when dealing with problems. "The system" just has to give them that chance.
I agree entirely, and thank you for providing a more thoughtful analysis.
My experience: when tech support are (very) competent, (very) patient, (very) people-loving people, left to do their work in a low-turnover place with no ticket system, it is (very much) more efficient in the short-term, and absolute magic in the long-term.
I worked in IT. I had two techniques for people with inane questions -- number one, acknowledge their request and tell them they are in the queue, then follow up the next day asking if they still need help. Usually they had either figured it out or asked a friend by then. Number two was to just teach them where to figure it out for themselves as a ticket update, and then close it out the next day.
If they actually came by, we would just help them and then file a ticket for them to track our work.
There is no reason to force people to file tickets before you help them.
They absolutely should force people to file tickets before helping them, if the IT department is understaffed (which is an entirely different problem).
Understaffed or not, if you want to be perceived as a cost center that gets in the way, sure require tickets to do any work.
If you want to be seen as a force multiplier for the business that helps people get work done quicker, then actually help people and do the record keeping on your time, not theirs.
It's been a long time since I've worked in a support-adjacent role, but IME it was always less about "keep[ing] the idiots at bay" and more about covering the ass of the help desk.
Things that take a support person 5 minutes are the bulk of the job, and those things have to be accounted for. If you slack on that, people will make their own determination of what constitutes a "simple" issue, you'll wind up with most of the issues the help desk solves not showing up in their metrics at all, and it looks to the higher-ups like the support people are just lazy.
In the places I've worked, support always _loved_ the "idiots" because their problems were simple. Being able to resolve a ticket by putting in a single screw, telling the person to turn on their computer, or initiating a password reset was the easiest kind of win you could get.
Not really. The process is what keeps IT guys from being overloaded by 5 people competing who is going to push them harder so that their issue take priority. Or simultaneously screaming at them when they will be done. And it prevents them from drowning in issues reported by multiple channels (mail, chat and phone) spending time trying to organize them into single queue or figuring one which mail has additional information to what was said in which phone call.
Process like jira tickers are literally the thing that improves quality of life of non-idle IT worker.
Your example is actually example of the above. You want your screw to be treated as #1 priority right now. Allowing the technician to finish what he was doing and only then get to your request is not fast enough. But, with that being the norm, work becomes jumping between tasks and trying to finish three things parallelly. It becomes impossible or super ineffective to finish larger tasks.
Yuck! There are reasons processes like that exist as annoying as they are. At a certain scale orgs have to make a queue or else nothing gets done. I work at a scale up and have seen the phenomenon with my own eyes. Easy enough when there are 10 employees. A lot harder when you 10x that number.
The situation you describe does sound pretty extreme though. Maybe your org is large enough to warrant it who knows. I don't think I could work someplace that had that much red tape.
As I said, this particular anecdote does seem extreme. I am just making the point that at a certain scale it gets harder to do out of band tasks if you don't scale up the staffing to match it.
The idea of a ticketing system is to put everyone in a line and have them wait their turn. You were basically trying to skip the line. Yes, it was something trivial and easily fixable - but it was also something that didn't really affect your work productivity--your laptop wasn't falling apart, was it? So you could have put in a ticket and waited your turn like everyone else. Perhaps there were others with productivity-affecting issues that needed to be taken care of first.
The only way they are being unreasonable is if your company is in the high single or low to mid double digits of employees and they are using it as an excuse to avoid work. For large companies, there's enough trouble with managers and officers of the company all thinking they can just take an IT worker at their pleasure regardless of other workload, so they're probably going to be extra defensive for anyone else.
You should work IT servicedesk for a few months for a large company that doesn't want to plow money into IT and see how it is.
The down votes you’re getting here just really highlights how out of touch many developers (HN users) are from the reality of IT. All of your points are spot on, and anyone disagreeing with them simply doesn’t have enough experience to have a valid opinion.
IT Operations lives and dies by all the “5 minute real quick” tasks. The fact is that many requests fall into that category, but there can be 100s of those per day. The only way to manage that is by forcing people to open tickets, and then handle them according to priority.
Running with no slack is the definition of every company on the planet, except FAANG where they are swimming in money. From a business standpoint it makes no sense to pay people to sit around doing nothing just in case someone comes by with an extremely non-critical issue.
Running a tight ship may not make everyone happy, but it does force people to prioritize what really needs to get done vs what’s not critical.
I'm a sysadmin with decades of experience, many of them user facing and in IT support. I disagree with them. Hopefully I have enough experience to hold an opinon.
Triage is incredibly useful in life and death situations, and has some value in many others. Sticking to unmovable policy no matter what however is not IT Support, it's Corporate, Faceless IT Support that makes everyone who isn't IT dislike us.
The world doesn't have to be this way, and rigid adherance to policy and your disparaging attitude are some of the main reasons I hope I never have to work in soulless corporate IT again.
I think there is no right or wrong answer here. Imagine if IT just fixed that screw without a ticket. All good. Few mins. Now a few days later, there is sudden issue with the laptop. Guess what the customer will say ? They will say "Oh I donno, the IT guy put a screw in here last so may be something happened because of that". Now, there is no audit trail and accountability and details and boom, the IT person's job is at risk because they did not follow protocol.
No one wants to take 4 hours to replace a screw. But the answer is not always so cut and dry. The best we can do is to find a balance. For example, the IT guy fixes the screw right there BUT ensures a ticket was put in by the customer within next few hours.
Just let people open a ticket from a station at the IT desk, or let IT open the ticket themselves for a certain class of items. Similar to an over-the-counter permit at a building department. Municipal governments figured that out decades ago ;).
I've also had IT folks open a ticket for me on the spot. They know what minimal info to type to describe the problem, the longest part is telling them your name or employee ID number. They then close it immediately.
Well, that's a problem with the management of the service desk. Most walk-in service desks log the ticket for you.
But it would have been interesting had you told them you couldn't use your computer because the screw is missing, and how do they expect you to log the ticket? Sounds like there is an arsehole in the service desk. I'd lodge a complaint internally.
You should walk a day in their shoes. Hand someone a screw and the next day someone else will come up and ask for a new monitor, and when you ask for them to request a monitor in the ticket system they will get all upset and talk about how they heard that you gave out supplies to someone else yesterday. Why can't you do it today?
Serving walk-up requests for equipment like monitors is one of the most basic functions of our IT. They ask for your username and file an auto-closing ticket on your behalf right there. When supplies are tight, like with M1 Macs, you have to get on a waiting list. But anything they have in inventory they will give you if you ask.
And how much time would the IT guy have wasted finding that screw? So you think everyone knows exactly what screw goes in that hole? There’s likely a not insignificant amount of time needed to just figure out which type of screw it was.
Beyond that, every user thinks their issue is “just a quick question”. When you have 100s of people who all think that, that’s a whole week of work right there.
And often times something that looks small can turn into a big problem. Why did that screw fall out? Screws don’t just “fall out” for no reason. Did the threads get stripped out? How did that happen? If so maybe the chassis needs to be replaced. Did it pop out because of a swelling battery? If you don’t start with a ticket, there’s nowhere to keep track of all that.
The work is there regardless of who does it. It’s a net zero change in total amount of work. It’s more efficient to have the user with the problem to write up the initial report, as they’re the ones with the most details. And it’s better to let IT focus on actually solving other things than to have a highly paid workforce just writing up tickets.
At my last job they would just open the ticket for you after you left and immediately close it with a brief description. Walk up IT is fantastic when done right. At least they didn’t have to call a Dell or HP tech to come on site and install the screw.
The person who asked you to open a ticket was actually declining to solve your screw problem. They figured there was a high chance you would not bother to open a ticket. Also if you do open a ticket, they can assign it to someone else and from their point of view the problem has gone away.
The person recommending a clamshell replacement was telling you "I don't know what screw goes in that hole and actually I don't know how to order that off the vendor's website". They do not turn screws for a living and don't have the technical vocabulary to cope with your problem.
The only way they can get rid of you is to make it the vendor's problem; which means they need to transform your problem into something in the vendor's catalog. Hence, clamshell replacement.
When you went on-site with a ticket it seems like the front desk had no easier option left than to find a "screwdriver turner" (with the big pile of broken stuff in the back room) and get them to actually fix your problem.
No. 95% have gone through IT problems that impacted their work. The other 5% have either not have had to deal with such problems, or the ones they did had no significant impact on their work.
This means that too many people are going through hurdles with IT, not that problems cause problems. It shows that companies need to streamline and improve their IT processes so that fewer employees are impacted.
The one that I've seen a few times is when a new employee comes, and they literally cannot work due to a variety of IT issues:
- Nobody has ordered a new machine, takes up to a month to sort out
- Their name is spelled wrong in the email system, takes weeks to fix. Especially bad if your role is external facing.
- Subscriptions have not been made for necessary services eg Bloomberg
- Access is denied due to the initial password being unknown. It takes a week to sort out.
I've even heard of people quitting their new job due to one of these issues. It makes the place look really amateur when a new joiner isn't set up to start when they arrive.
I've had this happen to me. Ended up with three work computers after waiting a week after my start date to get one. It was a temporary gig and they were paying me regardless, so no skin off of my back...but it was endlessly frustrating for my boss and I had multiple IT people tied up for hours trying to resolve everything.
Edit: I also left another position at another company (to move to a different position at the same company) mostly because it meant I would get a new computer instead of one that would take 20 minutes to boot (and required mid-day reboots as well)
Don't exclude the middle. Those people probably think it doesn't decrease productivity and morale, because those are already garbage regardless of what IT does.
These are probably the people who work in IT, who love to fix things and solve problems. Their workplace productivity and morale may be enhanced by the inevitable IT problems that befall others.
If I tried really hard to devil's advocate that position:
"If my boss can't start this 90 min Zoom call that could be an email because his headset is broken, that is some sweet blessed relief from this drudgery."
I saw IT policy cause the near-downfall of a software company after it was absorbed by a bank.
As you would guess, overbearing security policies came in nearly overnight. Development had to be done on machines with (practically) no internet connection, approved devices were crappy laptops with no memory, developers couldn't access systems to diagnose issues, looking away from your machine for more than 5 minutes had it locked.
Everything just took five to ten times longer. You hear people say "the company still pays you for your time", but of course job satisfaction is important, and the company just hemorrhaged developers.
My startup was bought by a large corporation late last year. My laptop finally died a month ago and I was issued a new one from corporate IT and they really messed Windows up. Our desktop app that we develop won’t even run on it.
I have to change my password every 2 months, I can’t change power settings without an admin account (it’s locked on balanced), ssh wasn’t working because I needed admin to start the service, I can’t change which programs run at startup, I can’t uninstall programs that they’ve preinstalled even if I don’t use them, they automatically install/reinstall Java 8 which messes up my JAVA_HOME environment variable and I’ll randomly have to fix it so I can compile my Java 11 code base, everything in my home folder automatically goes to One Drive (rip node_modules), the fan runs at 100% no matter what because of some shitty corporate back ground processes.
It’s absolutely maddening. I’m going to reinstall my own copy of Windows or buy my own machine soon.
My company thankfully allows engineers to be admins on their machine with the right amount of begging and persistence. But it still sucks.
And now my corp Win10 machine is so clogged up with firewalls, antivirals, ZScaler and CarbonBlack whatever the fuck that is that the machine regularly stalls and just sits there for seconds at a time. In the middle of typing. It's put a dragchute on my productivity but they're paying me so fuck it.
Sounds like standard SOC2 cargo cult security.You're not secure until you spin around 5 times and say the magic incantation while documenting that you've done it for the audit.
I went from working at a company that offered “tech lounge” style IT where there was a place on site you could go to get your problems addressed, to one where they use more standard big company IT and the new one is so, so much worse for getting anything fixed. It’s incredible. Waiting on hold for an hour or more to just report your problem is totally the norm. Getting hardware is a massive pain and requires tons of approvals and weeks long wait times. Getting help for more subtle issues is virtually impossible. Just things like replacement cables or dongles are like trying to do a moon landing. It’s awful.
I work in the government. I know people who have worked at my office for years and don't yet have access to the classified systems required to do their jobs.
I was working as a DC tech at a small collocation provider, roughly 120 people company-wide. It was a standard shop these days: O365 apps, Chrome on Windows 10, Slack, etc., totally managed and locked down.
The IT staff were completely unable to control the Windows patching process. They made a lot of noise about gathering office hours for people so they could do OS & app updates when you weren’t working. Except it never, not one time worked.
It was company folklore all the times the Windows patching process took down engineering devices that were actively in use performing upgrades or changes to core routing and switching devices. So because IT couldn’t control patching, core network services were repeatedly lost during maintenance windows. Because the host performing the work would suddenly reboot to patch itself.
Now, I don’t know what lack of competence led to this situation. Maybe Windows Update is truly a horror story. But I’ll tell you one thing for certain: IT didn’t give one shit about the impact their mistakes had on production, on morale, or frankly about much of anything.
Like the rest of the workforce, IT is overwhelmed, overworked, under appreciated, and fed up with the BS. But it sure seems like they go out of their way to screw people over.
I work in IT security, so I am probably one of those people who screw other people over by pushing patches to be installed no matter what.
Behind the scene, it is a never ending war between me who says "if your want your data to be safe, we need to patch", and the business that says "no, those is quarter rend (or stuff like this)'.
So I say" on, sign this paper what you start that you do not want your data to be secure"
And it goes on forever.
This is exhausting for everyone, but IT is zero the very bottom of thefood chain, we cannot claim sales or new products and provide z utility like water or trash collection.
So this is not always that someone is trying to screw you over, out is just that technology works the way it works, with the money that is invested in it.
Your comment exemplifies the attitude I'm talking about. You've presented a scenario that's false in it's premise: either your data is safe or it isn't. But really, whether a thing is protected isn't quite so zero or one. Whether your production environment is actually at risk for the exploit being patched is a reasonable thing to ask in all scenarios. "What's our exposure here? Can it wait a few days?" would be a reasonable thing to ask.
But in my experience that isn't how it goes. It goes how you suggested: ITSecOps presents an easy-to-decide case based on a false premise, and then immediately asks for CYA if the company says no. Over time, this becomes a rubber stamp from management, who are also demoralized by the process.
The solution is to not present every security patch as a sky-is-falling event, but rather to be reasonable about the threats one faces and the impact to the business of forcing updates.
>Whether your production environment is actually at risk for the exploit being patched is a reasonable thing to ask in all scenarios. "What's our exposure here? Can it wait a few days?" would be a reasonable thing to ask.
You would think it do be that way, but it don't....
Especially with things like Microsoft's megapatches they distribute these days. You are asking for the potential impact of anywhere from 10 to 100 patches custom tailored to the particular applications you're running on your server. Now you're asking for some large number of manhours of in depth analysis in a department that's already short on time.
And as often as there is a patch that breaks the application, there is a patch that was released as a low impact that suddenly is high impact because it can be chained into an exploit, and now IT/SecOps is looking at the servers history to make sure it wasn't exploited at some time in the past.
What is helpful here is not delaying patches, but instead having good testing environments that run the same version of the production application so the patch can be tested there first. Of course that costs a lot so you don't see it as often as you should.
> You've presented a scenario that's false in it's premise: either your data is safe or it isn't.
Do you work in cybersecurity? have you done security assessment - the real, technicals ones before?
I did. I coded (a tiny, tiny) part of the Linux kernel. My teams break systems for a living.
If you have actually done security assessments than you know, of course, that there is no way to assess whether a vulnerability is low or high before shit hits the fan. When MS says "critical", then I say "critical" as well. I am not going to plat smart ass and then realize that in the shitty cathedral of systems businesses build there is THE configuration that allows for an exploit.
Anything lower than critical - I do not care/ This can be done later. Bit is it is critical, it will be applied immediately, breaking systems and important presentations of the C-whatever. If the business has something against me then feel free to escalate to my management and tell them that they do want their data to be insecure. Because this is what they do want. Some tried - their systems are patched as the others.
Everyone today is a doctor, football coach an,d recently cybersecurty expert. Yes, maybe your IT team sucks, but others just want to do their fucking dmn, work.
You know, I've worked in IT long enough -- 25 years now! -- to watch the rise of "the cybersecurity professional", and their place as a rubber-stamp of acceptability in the food chain of business IT. I'm sorry if you find this comment to be incendiary, and an attack against you in particular. It most certainly is not. I do understand that there's a wide chasm between the state of the industry and the intentions of individual people. If it's any consolation, I've found that my own work is mostly a kind of rubber stamp too, and lately I've begun to question the entire endeavor. What are we actually working to do anymore? Beats me, really.
But, I do find some irony in a statement like "it is critical, it will be applied immediately, breaking systems and important presentations of the C-whatever. If the business has something against me then feel free to escalate to my management" when the title of the article we're talking about is Report: 95% of employees say IT issues decrease workplace productivity and morale. If you don't see the connection between "I don't care how this affects you" and "IT causes low productivity and morale", well then I guess all I can do is laugh, and be glad I've left IT desk work for data center technician work.
I am in the same boat, about 30 years of IT and moved to information security 15 years ago because it was a very interesting challenge.
I understand your rubber-stamp thing (I see it a lot with "audits") but I refuse to be one. This is a lot of friction but ultimately I got the trust of the company (a very big company).
One of the things I changed about 6 or 8 years ago was the patching process. Patching was done during maintenance windows and froze during quarter ends and similar.
OTOH a wormable vulnerability, a ero day or similar will not wait - so I requested a decision of the owners of the data: either availability or security. They asked me all kind of questions such as "what is the probability" to what I answered that I have no idea. But if the recommendation of the vendor is to patch NOW then utr is also mine.
And our systems are always patched, and I sleep better, they sleep better, everyone sleeps better.
If you work in IT you know what this is either the useless dept that puts barriers, or the saviour when there is trouble. Nobody from these 95% realize that there may be reasons for the restrictions, even if at home they do not need a password or backup or patch or something.
It would be much easier to work in some "added values" departments such as marketing and not in the water^H^H^H^H^H IT one.But I love my work.
Your earlier comment is about an IT department "overwhelmed, overworked, under appreciated, and fed up with the BS" who also had no control over the patching installs anyway, and didn't care, and your conclusion is ""What's our exposure here? Can it wait a few days?" would be a reasonable thing to ask." of them? I can't see that adding "now every single patch forever is up for argument" as likely to improve such a situation.
Even in a competent and interested IT department, the change from "patch Tuesday, same time every month" to "now every patch is up for negotiation" seems like a non-trivial overhead, given that we assume it's desirable to install them all eventually. Exercising power for power's sake. One off asking "can we eat later today" is reasonable but if dinner is always inconvenient for someone then decide once "dinner is later" or "we eat separate dinners", don't have a dinnertime negotiation every day.
I think compromises could be made in this case - like giving users a reasonable amount of time to apply the patches before the update is performed forcibly. I have seen important meetings stalled because the presenter was only given two hours to reboot his computer after Windows updates were applied, for instance. Same for big Windows feature updates occuring in the middle of the day and stopping work for an hour. But with say twelve hours or so then the user could reboot in the evening or during lunch break without affecting productivity.
It depends on the vulnerability. as I commented elsewhere, below Critical I do not care. Critical needs to be patched NOW, breaking things if needed. Including the important presentation.
If you want Windows boxes to stay updated then have a way to replace the entire machine and replicate all needed application data (including sql server databases and anything proprietary) within minutes or hours at no notice. The Windows Update Service is a practical nightmare. It will get corrupted. It will require an entire re-image of the machine to fix. It will happen on production servers and client endpoints without regard to core business impact. It might even happen at a rate of a few per hundred of installs updated.
Back in the day, if your pencil was dull, you sharpened it with your own personal workplace sharpener. You could replace your pencil or maybe even typewriter by just going to the supplies closet and get a new one. Security was done by cleaning your desk and locking the file closet in the evening. Also, the friendly security guy at the main entrance greeted you nicely and knew your face.
Nowadays, if there is a problem with your pencil-equivalent computer plus word-processor, you have to get support from hardly available technicians. You cannot just take the next computer out of a nearby supplies closet. Even worse, after an update, all computers company-wide break at the same time in the same way, no chance for a quick fix. Security is done by weird processes that must be followed to the letter, including learning a new "key profile" by heart every 8 weeks instead of just taking along the company-provided file-closet-key on a keychain. If you use the company provided email client like it is built to be used, e.g. click on attachments, you are at fault for breaking policy and endangering security. If you fail to use obscure processes that said email client doesn't actually want you to use to check for the originator address of an email, you are endangering security. Same for the fancy new phone-replacement-software that needs you to download and execute arbitrary executables which you aren't supposed to do. And the guard at the door has been replaced by an RFID badge that any kid in the subway standing next to you can clone with his phone. Of course you are supposed to know this and wrap that badge in tinfoil outside company premises.
IT issues are so debilitating because users are powerless to fix them. They are blamed for problems that arise just because of the mandated software being unsuitable and insecure. All this gets papered over by heavy processes such that even the people in IT who are trying to help are powerless, bogged down in ticket-pushing busywork, and tons and tons of policies that actually do nothing useful.
It isn't FUD if it is still true for a majority of deployments, even new ones.
One popular example: EV chargers still rely on easily cloneable Mifare Classic for access and billing and are only very slowly changing over to more secure alternatives. And in case it isn't obvious: Mifare Classic security problems were literally more than a decade old knowledge when EV chargers started to be deployed.
A pencil is a simplisic writing device whereas a computer and its software is significantly more complex. Not to mention it communicates with external devices like mice, keyboard, wifi, website, and email
Mandated software, like security products, don't exist on a pencil because it can steal all your financial data from an external connection.
IT has policies because of past failures and regulations. They are also bogged down because a ticket can take anywhere from 5 mins to many days and it's impossible to accurately predict what frequency of each type of problem will occur from the known set or how long it each will take. Companies hire a decent amount but they also can't over staff a dept just so everyone gets their issues fixed instantly.
Users can't fix their computer most of the time because they don't know how. A pencil either needs to be sharpened, needs to be replaced, or is working. Everyone can be taught how to do those three things in a short amount of time.
One office object that's not a computer and would be a better comparison is the copy machine. It's a troupe about how often they broke.
The comment that you're replying to isn't arguing that computers shouldn't be complicated, or that we don't need them to be. It's pointing out that they are complicated, and in a way that leaves most people powerless.
There's no need to run in and defend computers, or security policies.
Maybe not from korija in particular; you're probably right about their specific intentions writing that post.
But I've seen posts—hell, I've met people in person—that clearly put forward the opinion that computers are a mistake, they're overly complex, and we need to go back to the time before they existed.
Most of the time, this is at least couched in the form of "Aw, man, these computers are just so dang complicated, y'know? I can never get 'em to work right! You know how it is, right?" But there have been multiple occasions where it was much less playful and much more seriously "computers don't help, they only make things worse, I hate them and we should just all go back to pencil and paper."
And for what we need computers to do, there is a necessary, irreducible complexity involved, so there is a limit to how simple things could be even in theory.
But the problem isn't with that necessary complexity per se. It is the lack of knowledge in the responsible upper layers of any organisation about how to deal with that. Computers are complex, as essential as pen and paper (or more) and exhibit highly correlated failure modes (i.e. one faulty update or one trojan takes down all of them, just like a fire burns all your papers). This means that a large amount of resources should be expended to prevent problems from occuring in the first place, because they are usually large-scale and severe. Instead, IT gets the minimum amount of resources to keep up with constant firefighting. Also, risk-prevention is frowned upon, the new shiny or the crap everyone uses always has priority, even if it increases risk. Because nobody ever got fired for buying HAL or something.
Right; exactly. This is the kind of sensible analysis of the situations you described that is needed to actually solve them, rather than just decide that computers were a mistake and throw them out (or, as is much more common, throw up your hands and claim that this is unsolvable).
"computers are complex unlike a pencil" it's mostly complaints about IT
"heavy processes such that even the people in IT who are trying to help are powerless, bogged down in ticket-pushing busywork, and tons and tons of policies that actually do nothing useful."
My defense was attemping to explain they are difficult compared to other office products ait's to be expected.
His comment seems to imply that there's failure in the IT process or the way it's run that cause the issues. In other words "we have a process for pencils that work , why not computers " as if process can be scaled linearly
The number one issue with IT is that companies don’t see the value in having a full support staff and hire the bare minimum to get stuff done. My wife worked for a few big enterprise companies in Denver and they’d only have 4-8 people supporting hundred each. Higher ups choose the software and hardware, they’re stingy with licenses, only replace hardware every five years, will have a faulty computer repaired dozens of times before getting replacements, buy hardware that’ll be obsolete in a year), upgrades are all computers at once because the software doesn’t support testing groups. A funny example is she recently helped a hospital network upgrade to new computers in 2021; none of the computers support windows 11 so they have to buy new computers again because their new software doesn’t support windows 10. This happens all the time.
This is an accounting problem. If you get your act together and buy a load of new hardware, hire staff to maintain it, there's a definite number attached to it.
If you let your teams get bogged down with crappy hardware and no support, you also pay, but nobody can count where the losses were and what they sum up to.
Like an invisible tax, you end up paying one way or another, but you'll never know how much and whether it was a good trade.
Yep. I would be 3x as productive if I was given hardware and software which was fit for purpose.
I have actually been unable to work at all for 17 days this year so far due to stupid issues caused by poorly tested changes or having to wait for tickets to be cleared.
But I give less of a fuck these days. I can do other things and still be paid.
I mean yea but in my experience, what really decreases my morale and burns me out is terrible user experience. I understand that there are bugs in code and systems crash so I don’t really let IT issues bother me. But it bothers me to no end to have to use user hostile software day in and day out at work. Death by a million clicks.
Basically, you can run your IT department one of two ways. You can be a statistic driven group that ultimately will fail to serve the company because the act of taking those statistics will corrupt you. You can just serve your customers and take note of what you do and then try to figure out the stats afterwords. Maybe its premature optimization that gets you.
I would bet you can figure out how bad IT is going to be by the CFO's attitude towards IT. Doesn't really matter what the CIO thinks because the justification for budget makes you do stupid things.
I had brief experience managing such IT team after which I've gained big respect for them. I've never seen such low budget to amount of work ratio in my IT career. Everybody expects them to fix the "trivial" problems immediately but reality in my case was:
- 2 "IT guys" for > 500 headcount company
- If you look at IT guy instant messaging app you will see many unread notifications all the time. Without tickets it's impossible to properly prioritize and divide work. "Tickets" for everything" was one of my first change.
- They are responsible for the broadest set of technologies / vendors I've ever seen. That includes: networking (including cabling, switched, wireless routing, VPN, firewalls), laptops, office apps, conferencing hardware (and software), IT security, accounting and warehouse software (including their MS SQL databases,) windows servers, virtualization, managing email accounts and maaaany more.
- without tickets they can't show real amount of work they are doing so justifying adjustment budget and staffing for the need is a big challenge. On the other hand everybody expects to fix trivial problems without forms (so most of their work!).
- Upper management don't perceive the as value but only as a cost
- trivial problems could be fixed faster but that would require supplies for spare parts. This is bigger than you may think: few generations of laptops in use, office hardware, spare monitors, docking stations etc. That require office space for a small "warehouse" which is not free. How to justify this need considering the previous points?
- many people fix "trivial problems" themselves: replacing cable, "borrowing" cable/mouse/monitor from a different desks. That creates more work for the IT guys: more issues because of incomplete office hardware.
I worked at a place where IT was obsessed with moving everyone to thin clients. The executives loved it, HR loved it, and it took almost 3 years to get most developer work kind of working.
Are these issues with IT or with corporate bureaucracy?
Is there anything about IT that specifically amplifies these issues, or are there similar issues in other contexts which aren't IT-related?
IMO it's easy to blame the technology. But when virtually all individual corporate tooling relies on IT, there's no real control group to provide an alternative.
A lot of the problems listed below sound like they could be solved relatively easily - if the will was there, and if the corporate relationships around them didn't promote bureaucratic non-solutions because of turf wars, irrational policy, lack of effective oversight, and so on.
Thank goodness it's a lot of years that I do not have to deal with corporate IT support, but at the time (in various firms) they tended to be a lot similar to the procurement office (Bob the dinosaur) in Dilbert:
This is the thing that infuriates me most about any job. At any business, everyone needs to work as a team to accomplish the business's goals and make the customer happy. If anyone decides they're not going to care about their team mates, they are working against the best interests of the people who pay their salary. They're taking a dump on the rug of the person giving them a meal.
It might be the IT person doesn't have time to work on new issues. Or it might be the middle manager doesn't want to fight for what we really need. Or the executive doesn't want to spend money on what they don't personally care about. Or the engineer doesn't want to work with operations on how the product should work. Or human resources doesn't care how painful it is to onboard in the company. Or the company as a whole doesn't care how difficult it is to just find some information, or communicate across teams.
It's usually never just one person or group at fault. The culture sets the tone for how well people listen for problems, how willing they are to jump in and fix them, and whether they even think it's OK to try to fix them. Apathy, fear, and jadedness will drive everyone to stop making things better. If you find yourself in such an environment, my advice is to quit immediately, because changing culture is just about the hardest thing there is.
What's the alternative? That IT issues increased workplace productivity? I'm not going to give 1E my contact information to read the full report, but this does not sound insightful to me.
130 comments
[ 3.5 ms ] story [ 197 ms ] thread- 37% : Security/regulatory policies
- 37% : IT overwhelmed by number of issues that need resolving
- 35% : Lack of training for IT personnel
- 34% : Handling the shift to hybrid/remote work
- 32% : Increasing number of endpoints to manage
- 31% : Technology in place is not appropriate for supporting DEX
- 27% : Lack of knowledge around DEX
- 25% : Lack of budget to support DEX efforts
- 19% : Lack of buy-in from leadership around importance of DEX
- 2% : No challenges being faced
(with some snark: statistics on signup/login requirements before viewing published reports, and presenting statistics in images instead of tabular data formats were not reported)
- outbound http proxies sometimes falling for a few specific URLs but the issue was never debugged
- employee portal logging you out after a couple minutes of inactivity
- expenses claiming Web app which could've been 2 plain HTML forms but somehow required IE and was so bad I had "calm down after doing expenses" breaks
The bar is really around: don't actively make people angry.
-Web policies that actively prevent you from doing research in key company technologies (edit: fake example, but effectively it was on the level of a gun maker blocking searches on firearms)
-No budget for replacing/upgrading outdated computers that get absolutely crushed by memory hogging corporate nannyware. It's amazing how little you get done when it takes five minutes to open Excel
-Computers not arriving until well after the start date of new hires
-Outdated database access prograns that won't run on x64 systems (or better yet, are still run on terminals and the only viable means of export was printing...and yes I ran into that only a couple years ago in a Fortune 100)
I get a lot of this is outside the hands of IT to actually fix, but they're still "IT Problems" even if the root cause is shitty management
But HR themselves wont check whether you do jira tickets or whether you do something else. For HR, IT is one of many departments with own set of rules that HR does not get to decide.
How many of these did we do, how many of those, how long did it take to close this type of ticket, etc. So while the technical people could fix things on the spot, they are not allowed to due to the demand for metrics and tracking.
I can see both sides of the debate, but there needs to be a good balance. We can get stuff done and provide metrics without too much overhead.
About ten times as long as wihout using the ticket system and involving middle management
Needing tickets is just reality. Companies see IT as a cost center so they need to justify their existence, which they do with tickets. Creating tickets itself doesn’t need to be adversarial, but the process can be used to try to get people to leave you alone (or at least make it onerous to do so) if that’s what you want.
With this said, if the management demands IT has tickets, this is something that must be reiterated to every employee. "If you go to IT without a ticket, they cannot and will not help you"
While you as an employee may not have been adversarial, it is extremely common for angry users demand help right now for their life ending issue that's more important than anything else in the world! You know, they need that PDF printed right now... While you happen to be working on the server that's keeping 100 other people from working.
(Realistically, everyone outside the department knew me by name. They would call and ask for me any number of ways including outright lying. They'd tell me I was the sole source of any problems getting solved! "Everyone else in that department can't do a thing.")
Please just put tickets in before you reach out to IT and have the number ready. Print it off, even.
You may be quite adept with computer machines, but work a few days in IT support, and you'll understand why there is a ticketing process.
I think at least a part of that problem is that the usual support ticketing process infantilizes users. If you call in and the first question is along the lines of "is it plugged in? have you tried turning it off and on again?" then of course your next ticket will take that level of questioning into account. And call in even for a switched off monitor next time. Because they wouldn't ask that question if that wasn't their job to fix, right?
Also, of course users will try and fail to fix issues themselves. They should be applauded for the intent and empowered to be successful next time (if possible). Instead they are usually berated for failing and breaking stuff along the way. Which leads to the usual sheepish "I didn't do anything, I didn't touch it, it always was broken like that".
Of course there is a minimum number of imbeciles. But most people can be educated and empowered, so they do behave like adults when dealing with problems. "The system" just has to give them that chance.
My experience: when tech support are (very) competent, (very) patient, (very) people-loving people, left to do their work in a low-turnover place with no ticket system, it is (very much) more efficient in the short-term, and absolute magic in the long-term.
If they actually came by, we would just help them and then file a ticket for them to track our work.
There is no reason to force people to file tickets before you help them.
If you want to be seen as a force multiplier for the business that helps people get work done quicker, then actually help people and do the record keeping on your time, not theirs.
[1] Primary business, the shit the makes the money. [2] Support, shit that is done only to support #1.
Things that take a support person 5 minutes are the bulk of the job, and those things have to be accounted for. If you slack on that, people will make their own determination of what constitutes a "simple" issue, you'll wind up with most of the issues the help desk solves not showing up in their metrics at all, and it looks to the higher-ups like the support people are just lazy.
In the places I've worked, support always _loved_ the "idiots" because their problems were simple. Being able to resolve a ticket by putting in a single screw, telling the person to turn on their computer, or initiating a password reset was the easiest kind of win you could get.
Process like jira tickers are literally the thing that improves quality of life of non-idle IT worker.
Your example is actually example of the above. You want your screw to be treated as #1 priority right now. Allowing the technician to finish what he was doing and only then get to your request is not fast enough. But, with that being the norm, work becomes jumping between tasks and trying to finish three things parallelly. It becomes impossible or super ineffective to finish larger tasks.
The situation you describe does sound pretty extreme though. Maybe your org is large enough to warrant it who knows. I don't think I could work someplace that had that much red tape.
I think there can easily be two queues. The formal ticket queue and the "lets just do it to save admin"-queue.
Like, big tasks can't block small fast tasks due to congestion.
The only way they are being unreasonable is if your company is in the high single or low to mid double digits of employees and they are using it as an excuse to avoid work. For large companies, there's enough trouble with managers and officers of the company all thinking they can just take an IT worker at their pleasure regardless of other workload, so they're probably going to be extra defensive for anyone else.
You should work IT servicedesk for a few months for a large company that doesn't want to plow money into IT and see how it is.
IT Operations lives and dies by all the “5 minute real quick” tasks. The fact is that many requests fall into that category, but there can be 100s of those per day. The only way to manage that is by forcing people to open tickets, and then handle them according to priority.
As with all the other criticism in this topic, the fault is with the execs, and not the frontline IT workers.
Running a tight ship may not make everyone happy, but it does force people to prioritize what really needs to get done vs what’s not critical.
Triage is incredibly useful in life and death situations, and has some value in many others. Sticking to unmovable policy no matter what however is not IT Support, it's Corporate, Faceless IT Support that makes everyone who isn't IT dislike us.
The world doesn't have to be this way, and rigid adherance to policy and your disparaging attitude are some of the main reasons I hope I never have to work in soulless corporate IT again.
No one wants to take 4 hours to replace a screw. But the answer is not always so cut and dry. The best we can do is to find a balance. For example, the IT guy fixes the screw right there BUT ensures a ticket was put in by the customer within next few hours.
But it would have been interesting had you told them you couldn't use your computer because the screw is missing, and how do they expect you to log the ticket? Sounds like there is an arsehole in the service desk. I'd lodge a complaint internally.
Beyond that, every user thinks their issue is “just a quick question”. When you have 100s of people who all think that, that’s a whole week of work right there.
And often times something that looks small can turn into a big problem. Why did that screw fall out? Screws don’t just “fall out” for no reason. Did the threads get stripped out? How did that happen? If so maybe the chassis needs to be replaced. Did it pop out because of a swelling battery? If you don’t start with a ticket, there’s nowhere to keep track of all that.
Or just swap the drives with another laptop and send them on their way and then diagnose the other laptop later.
I worked in IT and our mission was always to get the customer working again as quickly as possible, and put as much work on us as possible.
That’s how you add value as an IT organization.
The person recommending a clamshell replacement was telling you "I don't know what screw goes in that hole and actually I don't know how to order that off the vendor's website". They do not turn screws for a living and don't have the technical vocabulary to cope with your problem.
The only way they can get rid of you is to make it the vendor's problem; which means they need to transform your problem into something in the vendor's catalog. Hence, clamshell replacement.
When you went on-site with a ticket it seems like the front desk had no easier option left than to find a "screwdriver turner" (with the big pile of broken stuff in the back room) and get them to actually fix your problem.
This means that too many people are going through hurdles with IT, not that problems cause problems. It shows that companies need to streamline and improve their IT processes so that fewer employees are impacted.
We're in agreement what exactly was the purpose of the survey...
See: https://slatestarcodex.com/2013/04/12/noisy-poll-results-and...
- Nobody has ordered a new machine, takes up to a month to sort out
- Their name is spelled wrong in the email system, takes weeks to fix. Especially bad if your role is external facing.
- Subscriptions have not been made for necessary services eg Bloomberg
- Access is denied due to the initial password being unknown. It takes a week to sort out.
I've even heard of people quitting their new job due to one of these issues. It makes the place look really amateur when a new joiner isn't set up to start when they arrive.
Edit: I also left another position at another company (to move to a different position at the same company) mostly because it meant I would get a new computer instead of one that would take 20 minutes to boot (and required mid-day reboots as well)
"If my boss can't start this 90 min Zoom call that could be an email because his headset is broken, that is some sweet blessed relief from this drudgery."
They probably just thought that answer was funny.
https://slatestarcodex.com/2013/04/12/noisy-poll-results-and...
As you would guess, overbearing security policies came in nearly overnight. Development had to be done on machines with (practically) no internet connection, approved devices were crappy laptops with no memory, developers couldn't access systems to diagnose issues, looking away from your machine for more than 5 minutes had it locked.
Everything just took five to ten times longer. You hear people say "the company still pays you for your time", but of course job satisfaction is important, and the company just hemorrhaged developers.
I have to change my password every 2 months, I can’t change power settings without an admin account (it’s locked on balanced), ssh wasn’t working because I needed admin to start the service, I can’t change which programs run at startup, I can’t uninstall programs that they’ve preinstalled even if I don’t use them, they automatically install/reinstall Java 8 which messes up my JAVA_HOME environment variable and I’ll randomly have to fix it so I can compile my Java 11 code base, everything in my home folder automatically goes to One Drive (rip node_modules), the fan runs at 100% no matter what because of some shitty corporate back ground processes.
It’s absolutely maddening. I’m going to reinstall my own copy of Windows or buy my own machine soon.
And now my corp Win10 machine is so clogged up with firewalls, antivirals, ZScaler and CarbonBlack whatever the fuck that is that the machine regularly stalls and just sits there for seconds at a time. In the middle of typing. It's put a dragchute on my productivity but they're paying me so fuck it.
I was working as a DC tech at a small collocation provider, roughly 120 people company-wide. It was a standard shop these days: O365 apps, Chrome on Windows 10, Slack, etc., totally managed and locked down.
The IT staff were completely unable to control the Windows patching process. They made a lot of noise about gathering office hours for people so they could do OS & app updates when you weren’t working. Except it never, not one time worked.
It was company folklore all the times the Windows patching process took down engineering devices that were actively in use performing upgrades or changes to core routing and switching devices. So because IT couldn’t control patching, core network services were repeatedly lost during maintenance windows. Because the host performing the work would suddenly reboot to patch itself.
Now, I don’t know what lack of competence led to this situation. Maybe Windows Update is truly a horror story. But I’ll tell you one thing for certain: IT didn’t give one shit about the impact their mistakes had on production, on morale, or frankly about much of anything.
Like the rest of the workforce, IT is overwhelmed, overworked, under appreciated, and fed up with the BS. But it sure seems like they go out of their way to screw people over.
Behind the scene, it is a never ending war between me who says "if your want your data to be safe, we need to patch", and the business that says "no, those is quarter rend (or stuff like this)'.
So I say" on, sign this paper what you start that you do not want your data to be secure"
And it goes on forever.
This is exhausting for everyone, but IT is zero the very bottom of thefood chain, we cannot claim sales or new products and provide z utility like water or trash collection.
So this is not always that someone is trying to screw you over, out is just that technology works the way it works, with the money that is invested in it.
But in my experience that isn't how it goes. It goes how you suggested: ITSecOps presents an easy-to-decide case based on a false premise, and then immediately asks for CYA if the company says no. Over time, this becomes a rubber stamp from management, who are also demoralized by the process.
The solution is to not present every security patch as a sky-is-falling event, but rather to be reasonable about the threats one faces and the impact to the business of forcing updates.
You would think it do be that way, but it don't....
Especially with things like Microsoft's megapatches they distribute these days. You are asking for the potential impact of anywhere from 10 to 100 patches custom tailored to the particular applications you're running on your server. Now you're asking for some large number of manhours of in depth analysis in a department that's already short on time.
And as often as there is a patch that breaks the application, there is a patch that was released as a low impact that suddenly is high impact because it can be chained into an exploit, and now IT/SecOps is looking at the servers history to make sure it wasn't exploited at some time in the past.
What is helpful here is not delaying patches, but instead having good testing environments that run the same version of the production application so the patch can be tested there first. Of course that costs a lot so you don't see it as often as you should.
Do you work in cybersecurity? have you done security assessment - the real, technicals ones before?
I did. I coded (a tiny, tiny) part of the Linux kernel. My teams break systems for a living.
If you have actually done security assessments than you know, of course, that there is no way to assess whether a vulnerability is low or high before shit hits the fan. When MS says "critical", then I say "critical" as well. I am not going to plat smart ass and then realize that in the shitty cathedral of systems businesses build there is THE configuration that allows for an exploit.
Anything lower than critical - I do not care/ This can be done later. Bit is it is critical, it will be applied immediately, breaking systems and important presentations of the C-whatever. If the business has something against me then feel free to escalate to my management and tell them that they do want their data to be insecure. Because this is what they do want. Some tried - their systems are patched as the others.
Everyone today is a doctor, football coach an,d recently cybersecurty expert. Yes, maybe your IT team sucks, but others just want to do their fucking dmn, work.
But, I do find some irony in a statement like "it is critical, it will be applied immediately, breaking systems and important presentations of the C-whatever. If the business has something against me then feel free to escalate to my management" when the title of the article we're talking about is Report: 95% of employees say IT issues decrease workplace productivity and morale. If you don't see the connection between "I don't care how this affects you" and "IT causes low productivity and morale", well then I guess all I can do is laugh, and be glad I've left IT desk work for data center technician work.
I understand your rubber-stamp thing (I see it a lot with "audits") but I refuse to be one. This is a lot of friction but ultimately I got the trust of the company (a very big company).
One of the things I changed about 6 or 8 years ago was the patching process. Patching was done during maintenance windows and froze during quarter ends and similar.
OTOH a wormable vulnerability, a ero day or similar will not wait - so I requested a decision of the owners of the data: either availability or security. They asked me all kind of questions such as "what is the probability" to what I answered that I have no idea. But if the recommendation of the vendor is to patch NOW then utr is also mine.
And our systems are always patched, and I sleep better, they sleep better, everyone sleeps better.
If you work in IT you know what this is either the useless dept that puts barriers, or the saviour when there is trouble. Nobody from these 95% realize that there may be reasons for the restrictions, even if at home they do not need a password or backup or patch or something.
It would be much easier to work in some "added values" departments such as marketing and not in the water^H^H^H^H^H IT one.But I love my work.
Even in a competent and interested IT department, the change from "patch Tuesday, same time every month" to "now every patch is up for negotiation" seems like a non-trivial overhead, given that we assume it's desirable to install them all eventually. Exercising power for power's sake. One off asking "can we eat later today" is reasonable but if dinner is always inconvenient for someone then decide once "dinner is later" or "we eat separate dinners", don't have a dinnertime negotiation every day.
Nowadays, if there is a problem with your pencil-equivalent computer plus word-processor, you have to get support from hardly available technicians. You cannot just take the next computer out of a nearby supplies closet. Even worse, after an update, all computers company-wide break at the same time in the same way, no chance for a quick fix. Security is done by weird processes that must be followed to the letter, including learning a new "key profile" by heart every 8 weeks instead of just taking along the company-provided file-closet-key on a keychain. If you use the company provided email client like it is built to be used, e.g. click on attachments, you are at fault for breaking policy and endangering security. If you fail to use obscure processes that said email client doesn't actually want you to use to check for the originator address of an email, you are endangering security. Same for the fancy new phone-replacement-software that needs you to download and execute arbitrary executables which you aren't supposed to do. And the guard at the door has been replaced by an RFID badge that any kid in the subway standing next to you can clone with his phone. Of course you are supposed to know this and wrap that badge in tinfoil outside company premises.
IT issues are so debilitating because users are powerless to fix them. They are blamed for problems that arise just because of the mandated software being unsuitable and insecure. All this gets papered over by heavy processes such that even the people in IT who are trying to help are powerless, bogged down in ticket-pushing busywork, and tons and tons of policies that actually do nothing useful.
Please do not spread FUD. Except for antique technologies. (MCF-1, ...) you can't clone RFID devices.
If you think its antique... like, its still widely in use today, i think you are wrong.
One popular example: EV chargers still rely on easily cloneable Mifare Classic for access and billing and are only very slowly changing over to more secure alternatives. And in case it isn't obvious: Mifare Classic security problems were literally more than a decade old knowledge when EV chargers started to be deployed.
https://community.nxp.com/t5/NFC/good-alternative-for-EV-cha...
It isn't FUD if reality is that bad...
Hardware device that copies many keys including encrypted: https://icopyx.com/
Mandated software, like security products, don't exist on a pencil because it can steal all your financial data from an external connection.
IT has policies because of past failures and regulations. They are also bogged down because a ticket can take anywhere from 5 mins to many days and it's impossible to accurately predict what frequency of each type of problem will occur from the known set or how long it each will take. Companies hire a decent amount but they also can't over staff a dept just so everyone gets their issues fixed instantly.
Users can't fix their computer most of the time because they don't know how. A pencil either needs to be sharpened, needs to be replaced, or is working. Everyone can be taught how to do those three things in a short amount of time.
One office object that's not a computer and would be a better comparison is the copy machine. It's a troupe about how often they broke.
There's no need to run in and defend computers, or security policies.
Maybe not from korija in particular; you're probably right about their specific intentions writing that post.
But I've seen posts—hell, I've met people in person—that clearly put forward the opinion that computers are a mistake, they're overly complex, and we need to go back to the time before they existed.
Most of the time, this is at least couched in the form of "Aw, man, these computers are just so dang complicated, y'know? I can never get 'em to work right! You know how it is, right?" But there have been multiple occasions where it was much less playful and much more seriously "computers don't help, they only make things worse, I hate them and we should just all go back to pencil and paper."
Poe's Law[0] is around for a reason.
[0] https://en.wikipedia.org/wiki/Poe%27s_law for those who aren't familiar
And for what we need computers to do, there is a necessary, irreducible complexity involved, so there is a limit to how simple things could be even in theory.
But the problem isn't with that necessary complexity per se. It is the lack of knowledge in the responsible upper layers of any organisation about how to deal with that. Computers are complex, as essential as pen and paper (or more) and exhibit highly correlated failure modes (i.e. one faulty update or one trojan takes down all of them, just like a fire burns all your papers). This means that a large amount of resources should be expended to prevent problems from occuring in the first place, because they are usually large-scale and severe. Instead, IT gets the minimum amount of resources to keep up with constant firefighting. Also, risk-prevention is frowned upon, the new shiny or the crap everyone uses always has priority, even if it increases risk. Because nobody ever got fired for buying HAL or something.
"computers are complex unlike a pencil" it's mostly complaints about IT "heavy processes such that even the people in IT who are trying to help are powerless, bogged down in ticket-pushing busywork, and tons and tons of policies that actually do nothing useful."
My defense was attemping to explain they are difficult compared to other office products ait's to be expected.
His comment seems to imply that there's failure in the IT process or the way it's run that cause the issues. In other words "we have a process for pencils that work , why not computers " as if process can be scaled linearly
If you let your teams get bogged down with crappy hardware and no support, you also pay, but nobody can count where the losses were and what they sum up to.
Like an invisible tax, you end up paying one way or another, but you'll never know how much and whether it was a good trade.
I have actually been unable to work at all for 17 days this year so far due to stupid issues caused by poorly tested changes or having to wait for tickets to be cleared.
But I give less of a fuck these days. I can do other things and still be paid.
I would bet you can figure out how bad IT is going to be by the CFO's attitude towards IT. Doesn't really matter what the CIO thinks because the justification for budget makes you do stupid things.
- 2 "IT guys" for > 500 headcount company - If you look at IT guy instant messaging app you will see many unread notifications all the time. Without tickets it's impossible to properly prioritize and divide work. "Tickets" for everything" was one of my first change. - They are responsible for the broadest set of technologies / vendors I've ever seen. That includes: networking (including cabling, switched, wireless routing, VPN, firewalls), laptops, office apps, conferencing hardware (and software), IT security, accounting and warehouse software (including their MS SQL databases,) windows servers, virtualization, managing email accounts and maaaany more. - without tickets they can't show real amount of work they are doing so justifying adjustment budget and staffing for the need is a big challenge. On the other hand everybody expects to fix trivial problems without forms (so most of their work!). - Upper management don't perceive the as value but only as a cost - trivial problems could be fixed faster but that would require supplies for spare parts. This is bigger than you may think: few generations of laptops in use, office hardware, spare monitors, docking stations etc. That require office space for a small "warehouse" which is not free. How to justify this need considering the previous points? - many people fix "trivial problems" themselves: replacing cable, "borrowing" cable/mouse/monitor from a different desks. That creates more work for the IT guys: more issues because of incomplete office hardware.
Is there anything about IT that specifically amplifies these issues, or are there similar issues in other contexts which aren't IT-related?
IMO it's easy to blame the technology. But when virtually all individual corporate tooling relies on IT, there's no real control group to provide an alternative.
A lot of the problems listed below sound like they could be solved relatively easily - if the will was there, and if the corporate relationships around them didn't promote bureaucratic non-solutions because of turf wars, irrational policy, lack of effective oversight, and so on.
https://dilbert.com/strip/1995-07-29
It might be the IT person doesn't have time to work on new issues. Or it might be the middle manager doesn't want to fight for what we really need. Or the executive doesn't want to spend money on what they don't personally care about. Or the engineer doesn't want to work with operations on how the product should work. Or human resources doesn't care how painful it is to onboard in the company. Or the company as a whole doesn't care how difficult it is to just find some information, or communicate across teams.
It's usually never just one person or group at fault. The culture sets the tone for how well people listen for problems, how willing they are to jump in and fix them, and whether they even think it's OK to try to fix them. Apathy, fear, and jadedness will drive everyone to stop making things better. If you find yourself in such an environment, my advice is to quit immediately, because changing culture is just about the hardest thing there is.