In these times of lean staffing budgets, some IT professionals are hesitant of diving too deep into a new automation tool, worried they could actually automate themselves out of a job.
I came into technology as a Perl programmer and UNIX administrator. I spent years writing common gateway interfaces for websites and automating routine tasks. As I moved along in my career, the ability to script and automate tasks was one of my top priorities when interviewing prospective employees. In my opinion, the ability to leverage an automation tool is a sign of a mature engineer. So why are so many people hesitant to embrace automation tools?
An automation tool can be anything from a scripting language to an application that allows you to build a workflow of tasks to be executed as a single action. Some tools are easy to learn, and others are a little more daunting to master. However, it may not be the learning curve that keeps many people from leveraging these tools. While some may simply not appreciate the value of automation, others are truly apprehensive about the end result. Some fear that if they can do their job in half the time, they or one of their co-workers may no longer be necessary. That could not be further from the truth.
Anyone avoiding automation as a misguided attempt to garner a sense of job security is failing to look at the big picture. How many tasks are left undone simply because there is not enough time? These can be critical tasks, simply neglected or drawn out because they require more time or focus than current workloads can afford. Often, the first tasks to be put off when schedules get crunched are routine maintenance. However mundane, these tasks are meant to be routine because of the high value they can provide.
I used to dread diving into log files to troubleshoot Web applications. I would begin the exercise looking for one issue and come out having found several more issues that had yet to make it onto anyone's radar. At any given time, there are a number of issues that are like a cancer in your environment: Undetected, they can grow and spread. As they grow, these issues can actually contribute to secondary problems, complicating efforts to perform a root cause analysis. What was even more frustrating was finding that the root cause of an issue had been present for months, but went unnoticed until it impacted an end user. I found I had to deploy automation, first by freeing up enough time for us to place an emphasis on reviewing log files. Then, we expanded automation to aid in the task of evaluating log files for potential issues. This provided a very real value to the organization and actually improved job security because it minimized the likelihood of minor problems going undetected and growing into major outages.
Automation isn't just about saving time
In many cases, an automation tool may actually provide hidden value. Take, for instance, the task of creating a new virtual server. If done properly, this is not a simple task. There are many steps and best practices to follow to ensure that security threats are mitigated. The steps can become so detailed that even seasoned administrators will find their skills challenged by the process. This is an ideal place to enlist the aid of an automation tool. In automating these tasks, the administrator now shifts from managing each individual deployment to managing the single automation task. In some cases, this can take the same amount of time. However, by increasing accuracy, it results in fewer inconsistencies and avoids future remediation efforts. Through automation, the administrator has now increased his value to the organization. At the same time, he may have just opened the door to increased value and process improvement within the organization.
In this scenario, now that the process of ensuring compliance and applying best practices is an automated task, is it still necessary to limit control over the creation of a new virtual server to administrators? Could processes be streamlined and tasks delegated to move IT closer to the business? The automation of tasks will definitely make that a possibility, opening the door for IT to provide greater value to the business.
Over time, many automation tasks that began as simple scripts will grow into workflow tasks. This will require a new set of skills, while naturally lending itself to those administrators who also understand the manual processes being automated. This should not be seen as a threat to job security. Rather, it should be recognized as a gateway or even a catalyst to new opportunities.
For the innovative engineer, there will be opportunities to aid in the improved alignment of the business and IT, not just doing more work with fewer resources, but also providing more value from existing resources. For the engineer that fails to learn how to leverage automation tools, they may actually be sending employers the message that they do not care about accuracy, efficiency or responsible usage of corporate resources. Now, who is really protecting their job in that scenario?