The old adage is that ’tis better to “work smarter, not harder.” By taking a measured approach to a task, whether it be turning wood on a lathe or coding a new web application, often mistakes or errors can be avoided, which would have greatly expanded the time to tackle the project. In today’s age of smart phones, cloud computing, and big data, one of the ways computer engineers work smarter is by utilizing automation.
Computers excel at repetitive tasks, far better than humans. Barring external influence, a program that is coded to “click the mouse every 5.03 seconds” will do just that, far more accurately than any user could hope to be. Obviously this is a simplified example, but how about running complex queries or formulae every time new data comes into a database? Instead of manually going through the process each time, a computer can be programmed to follow the repeated steps.
Automation not only frees up engineer time, it also reduces human error. Provided the task and any variables are properly accounted for in the code, it will perform as expected every time. Edge cases and unexpected hiccups aside—which ideally should throw a warning to a human engineer—there’s no chance the computer will make mistakes; it will perform exactly as programmed.
The title of this post directly relates to an old coworker of mine, who was at once the hardest-working and laziest system administrator I’d ever encountered, and whose work ethic I greatly appreciate. His role was to monitor the ticket queue, where customers would submit support requests and our automated systems would report system errors. His primary responsibility was to ensure the clients and their systems were working smoothly.
Every day, dozens of automated alerts would come in—a hard drive was nearing capacity, a workstation needed to be rebooted after hours for updates and patching, that kind of thing—and what absolutely killed this engineer was that he had to manually repeat the same steps to resolve these tickets every day. To him, it was menial busy work, and not worthy of his time as an experienced engineer. These issues were important and needed to be addressed, but if he could instead be working on higher-level projects, his job satisfaction and productivity would go way up.
His manager at the time called him the “laziest sysadmin” because “he always looked for ways to automate everything.” That manager believed that the employee “didn’t want to work,” when the reality was that the employee had a specific vision of what his work entailed, which differed from his boss. To his boss, the engineer sitting in a chair and clicking buttons for eight hours a day meant that he was being productive, where to the engineer it was the results that mattered, the ability for him to perform his job more efficiently that counted.
A disk cleanup ticket may have taken him no more than five minutes to resolve, but he was committed to freeing up that time from his plate. He spent several hours engineering a way for our tools to address the issue and only create an open service ticket if something actionable (read: unexpected) happened. Though the payoff may not seem worth it, what if he had seven, ten, twenty tickets of that type per day? Now he’s saving real time in very short order.
Once he received permission, this engineer spent an inordinate amount of time working to automate as many repetitive tasks as our tools would permit, which also resulted in the number of incoming tickets dropping significantly—almost all of the proactive monitoring and maintenance was being taken care of. This not only gave him more time to focus on customer-driven issues, but also to work on other projects that had fallen by the wayside as the volume of tickets increased.
In the end, he was easily our most productive employee, serving as the unquestionable backbone of our support team; while senior engineers were out working on network upgrades and other client-facing projects, he was spending much of his time actually improving our tools, making sure we were able to squeeze the most power out of them possible. The work he did allowed us to almost double in size without needing to hire any additional service technicians—instead of being buried by a torrent of automated emails, he had been able to engineer a workflow that allowed computers to excel at the repetitive tasks for which they were designed.
I genuinely dislike busywork, the kind of tasks that seem to accomplish nothing or serve little purpose. Heck, any time I go into a meeting I try to establish what the goals/aims of the meeting are, so we don’t end up off-topic and spending too much time on things that aren’t relevant to our purpose. It’s my belief that more businesses should take advantage of the power of automation—where applicable and relevant—and not only improve their efficiency but also their customer relations as well.
Every month I compile a table of statistics on our department’s efficiency over the previous period. Where at first I had to run somewhere in the neighborhood of thirty different reports and then manually comb through the data and pick out the relevant numbers, I’ve since automated many steps of the process, allowing my workstation to spit out only the relevant metrics when I feed in the raw data. A process that used to take me four to six hours now takes me fifteen minutes, freeing me up to work on other projects or client-facing endeavors.
Saving four to six hours a month may not seem like a lot overall, but multiply that savings by the number of tasks that can be augmented by automation. What if there were ten tasks? I don’t know any company that wouldn’t want to save 40–60 hours of employee productivity every month. With just three employees that would save the company from having to hire an extra body to assist with the load.
As with all things in business, the value of an endeavor is based on the return on investment. It may not make sense to automate a task that does not come up very often, or that only affects a small amount of people. It may very well make sense to automate a process that could potentially save hours and hours every month, depending how long it would take to implement the automation in the first place.
Though not part of my official title here at work, I’ve largely taken on the role of “process improvement,” because I want our company to be able to grow without blowing up the budget on new personnel. I try to use a data-driven approach to highlight areas that could be streamlined, and to identify areas where there may be invisible or undetected problems.
Does that make me a lazy system administrator? Honestly, I’m okay with that title—I’ll happily put in real engineering hours to make sure I’m not saddled with menial tedium day in and day out.
