Letters: Readers respond to an article about quitting the rat race, with some saying their generation was handed an untenable position and others saying the struggle is nothing new
And the mentality you’ve described is extra bullshit in an IT or support role, as I’m sure you’re aware.
This is paraphrased in the “Doom talk” I had to have with my boss back when I was working in systems maintenance. As in, he’d come into my office and complain, “Every time I come in here you’re just playing Doom. You need to justify your salary or otherwise maybe we don’t need to pay you.”
What MBA’s and PHB’s don’t realize is that IT and systems maintenance is not a production-oriented operation. You’re not making widgets. The metric is not how many tickets do we generate and how fast are they solved. The metric is, how can we have as few tickets as possible? Because by and large what you’re doing in support and IT is fixing stuff that’s broken. The ideal state for the business to be in is not to have anything that’s broken at all, on a minute-to-minute basis.
Boss, you want to see me in my office playing Doom. Because that means none of your millions and millions of dollars of mission critical infrastructure which your engineers rely upon to generate billable hours is on fire. If any of it catches fire today, I am on site to put it out. If anyone has a problem or a question, I am on call to solve it. If there is maintenance to be performed or new equipment to be rolled out, I’ll be doing that. But otherwise I’m not going to invent busywork just to placate middle management which, as a whole, can’t reliably remember which of the two mouse buttons to click.
Yep. I’m in the midst of that. We’re in a “busy” season for my clients (mostly finance/accounting people), and I’ve reduced my output hours per day to a lower amount because I want to be more available for more time so that I can jump on critical issues as they arise. For the most part, you want to jump on critical things regardless of the situation, but right now it’s more critical because of the busy season, so minor gripes get sidelined, all of my maintenance and other duties, like projects, scripting, etc, are all on hold, favoring time to resolution over almost everything else. So if I can be free more than normal so that I have the bandwidth to take care of things when they arise, so much the better. I don’t want to be distracted writing a script when a critical ticket drops and I miss it by a few hours while the customers are unable to work because I was debugging a PowerShell function.
So my logged hours are down because I refuse to pick up dormant unimportant tasks while I’m idle. I use the time to review all tickets and just patrol the service tickets for critical issues. I have absolutely no reservations about doing it.
I agree, the goal should always be to play doom. Not because you ignore your work, but because there’s nothing to do since everything works. IT support isn’t here to justify their existence by staying busy. We’re here so that when you need help, we can help. If there’s nothing to do, then we’re standing ready, and if we play doom, or Halo, or literally any other game/distraction/whatever, while we wait, as long as it doesn’t impact our ability to respond when needed, then that’s fine. That’s what everyone should want. If the hardware is so unreliable that you’re constantly having to work on it to keep it running, then, as IT, you fucked up.
I’ll also mention that there’s a paradox in IT: we’re expected to do so much and if you just do all the work by hand, you’ll be busy all the time. If you leverage scripts and scheduled tasks, you can significantly cut down on your workload. The paradox is that when you don’t have those scripts and scheduled tasks, and you’re doing everything by hand, you don’t have enough time to create the scripts to reduce your workload.
I’ll give an example. At a previous workplace, the bossman was very much in favor of doing things by hand, the original business model was T&M. He later moved to a more MSP model, where people are paying regardless of how much time was spent, so my focus shifted to automate everything and drop the ticket load as much as possible. In one such case, we kept getting issues related to a service failing. I don’t recall what the issue was, nor what problem it created, but I remember that simply restarting the service fixed the problem. So instead of fielding dozens of tickets a year to restart the stupid service, I added a scheduled task to run a script that would restart the service automatically every week at (some godawful hour) AM, on a Sunday or something. Once that script was scheduled for weekly runs, we stopped getting those tickets.
I have dozens of other examples along the same lines. One of my most proud moments was a script to fix a service where, if another service was running before it, the service wouldn’t load properly. The program service just wouldn’t start if a system service was running. It was a non-critical system service, but both had to be running after boot time. I had already tried every combination of delayed start, and every time, the program service would fall because the system service ended up running too quickly. So I made a script to shut down the system service, start the program service, and then restart the system service, and scheduled it to run 15 minutes after boot, anytime the system restarted (usually overnight for patching). Once that was in place, complaints of (program) not working after patch day, went away.
I hate repeating process because nobody thought to actually fix the problem, they just patched it back together manually. When faced with a reoccurring problem, I look at how I can stop it from happening; of course I fix it in the short term but as soon as I’m done I’m working on a script that can do it for me, then figuring out the best way to trigger the script so that I don’t have to be involved.
No matter how busy you are, finding a way to get rid of problems like that, by any means necessary, is essential; otherwise, you’ll be drowning in tasks to fix stuff that shouldn’t be broken.
That said, as someone in software development, wouldn’t there be some optimization work you could do?
Keeping up with the technology?
Preparing training material?
Figuring out the next steps for the next improvements to be done to the system?
Looking at solutions to better monitor what is going on? Scripts to automate tasks?
I find it hard to believe that things are so static.
Absolutely! Those things are known to management as, variously, “wasting time,” “spending all day surfing the internet,” “submitting frivolous RFQ’s,” and heaven forbid if you want to attend training or a trade show, “accruing unnecessary travel expenses.”
And the mentality you’ve described is extra bullshit in an IT or support role, as I’m sure you’re aware.
This is paraphrased in the “Doom talk” I had to have with my boss back when I was working in systems maintenance. As in, he’d come into my office and complain, “Every time I come in here you’re just playing Doom. You need to justify your salary or otherwise maybe we don’t need to pay you.”
What MBA’s and PHB’s don’t realize is that IT and systems maintenance is not a production-oriented operation. You’re not making widgets. The metric is not how many tickets do we generate and how fast are they solved. The metric is, how can we have as few tickets as possible? Because by and large what you’re doing in support and IT is fixing stuff that’s broken. The ideal state for the business to be in is not to have anything that’s broken at all, on a minute-to-minute basis.
Boss, you want to see me in my office playing Doom. Because that means none of your millions and millions of dollars of mission critical infrastructure which your engineers rely upon to generate billable hours is on fire. If any of it catches fire today, I am on site to put it out. If anyone has a problem or a question, I am on call to solve it. If there is maintenance to be performed or new equipment to be rolled out, I’ll be doing that. But otherwise I’m not going to invent busywork just to placate middle management which, as a whole, can’t reliably remember which of the two mouse buttons to click.
Yep. I’m in the midst of that. We’re in a “busy” season for my clients (mostly finance/accounting people), and I’ve reduced my output hours per day to a lower amount because I want to be more available for more time so that I can jump on critical issues as they arise. For the most part, you want to jump on critical things regardless of the situation, but right now it’s more critical because of the busy season, so minor gripes get sidelined, all of my maintenance and other duties, like projects, scripting, etc, are all on hold, favoring time to resolution over almost everything else. So if I can be free more than normal so that I have the bandwidth to take care of things when they arise, so much the better. I don’t want to be distracted writing a script when a critical ticket drops and I miss it by a few hours while the customers are unable to work because I was debugging a PowerShell function.
So my logged hours are down because I refuse to pick up dormant unimportant tasks while I’m idle. I use the time to review all tickets and just patrol the service tickets for critical issues. I have absolutely no reservations about doing it.
I agree, the goal should always be to play doom. Not because you ignore your work, but because there’s nothing to do since everything works. IT support isn’t here to justify their existence by staying busy. We’re here so that when you need help, we can help. If there’s nothing to do, then we’re standing ready, and if we play doom, or Halo, or literally any other game/distraction/whatever, while we wait, as long as it doesn’t impact our ability to respond when needed, then that’s fine. That’s what everyone should want. If the hardware is so unreliable that you’re constantly having to work on it to keep it running, then, as IT, you fucked up.
I’ll also mention that there’s a paradox in IT: we’re expected to do so much and if you just do all the work by hand, you’ll be busy all the time. If you leverage scripts and scheduled tasks, you can significantly cut down on your workload. The paradox is that when you don’t have those scripts and scheduled tasks, and you’re doing everything by hand, you don’t have enough time to create the scripts to reduce your workload.
I’ll give an example. At a previous workplace, the bossman was very much in favor of doing things by hand, the original business model was T&M. He later moved to a more MSP model, where people are paying regardless of how much time was spent, so my focus shifted to automate everything and drop the ticket load as much as possible. In one such case, we kept getting issues related to a service failing. I don’t recall what the issue was, nor what problem it created, but I remember that simply restarting the service fixed the problem. So instead of fielding dozens of tickets a year to restart the stupid service, I added a scheduled task to run a script that would restart the service automatically every week at (some godawful hour) AM, on a Sunday or something. Once that script was scheduled for weekly runs, we stopped getting those tickets.
I have dozens of other examples along the same lines. One of my most proud moments was a script to fix a service where, if another service was running before it, the service wouldn’t load properly. The program service just wouldn’t start if a system service was running. It was a non-critical system service, but both had to be running after boot time. I had already tried every combination of delayed start, and every time, the program service would fall because the system service ended up running too quickly. So I made a script to shut down the system service, start the program service, and then restart the system service, and scheduled it to run 15 minutes after boot, anytime the system restarted (usually overnight for patching). Once that was in place, complaints of (program) not working after patch day, went away.
I hate repeating process because nobody thought to actually fix the problem, they just patched it back together manually. When faced with a reoccurring problem, I look at how I can stop it from happening; of course I fix it in the short term but as soon as I’m done I’m working on a script that can do it for me, then figuring out the best way to trigger the script so that I don’t have to be involved.
No matter how busy you are, finding a way to get rid of problems like that, by any means necessary, is essential; otherwise, you’ll be drowning in tasks to fix stuff that shouldn’t be broken.
Yeah, firefighter mentalities are terrible.
That said, as someone in software development, wouldn’t there be some optimization work you could do? Keeping up with the technology? Preparing training material? Figuring out the next steps for the next improvements to be done to the system? Looking at solutions to better monitor what is going on? Scripts to automate tasks?
I find it hard to believe that things are so static.
Absolutely! Those things are known to management as, variously, “wasting time,” “spending all day surfing the internet,” “submitting frivolous RFQ’s,” and heaven forbid if you want to attend training or a trade show, “accruing unnecessary travel expenses.”