Why I was scared of IT automation

New technology often makes lots of promises but experienced IT professionals are likely to greet these promises warily. There can easily be a disconnect between what the vendor's sales team is pitching as a solution and the actual problems or challenges you're trying to solve. Having anxiety about significant change is expected. In our experience working with customers at Red Hat, we've found that certain roles share common concerns about IT automation.

Executives

As the person who may be most directly responsible for budget decisions and whose name may be most closely tied to the expenditure, IT executives tend to be most concerned with two things. First, they want to know what they're going to get for the cost. And second, they want to understand how problems will get solved—not at a granular, technical level but what they can point to after implementation that reflects that a process has been improved or a problem remediated.

Fortunately, the nature of IT automation means these are easier concerns to address than other software solutions. The right IT automation project pinpoints the time-intensive, manual process to be automated. An accurate cost or time value can often be estimated or calculated depending on the tasks and their complexity. By working quickly to identify the different tasks that underpin the larger process and automating those in a "building block" fashion, you can determine the improvement measure incrementally as you progress and the larger aggregate benefit once the process is automated.

[ Download now: A system administrator's guide to IT automation. ]

IT managers

Unlike IT executives, who are more involved in budgetary specifics, IT managers often feel more involved in the details of the purchasing decision. They're managing the work and the workload, but they sometimes lack key insights and statistics to fully understand how their employees are doing the work. As a result, when looking at automation use cases, they tend to want to do long-term waterfall planning.

But many automation use cases, particularly the more complex ones like compliance and patching, have a lot of lesser-known dependencies that arise later in the project and render waterfall planning inaccurate and ineffective. Not being able to plan effectively is a credible source of anxiety, as is entering a project that is likely to uncover some unknowns as manual tasks gradually get replaced by automated processes.

In past consulting projects focused on automation, managers have felt exposed, forced to acknowledge that they have knowledge gaps about root causes. But it's often their day-to-day work that causes these gaps. Many managers feel like they are constantly reacting to emergencies, dedicating staff to one issue or another, which ultimately leads to feeling short-staffed and under-resourced.

IT managers can reduce some of those reactionary, disruptive management habits by automating some of the tasks causing the service tickets. Their focus switches to having their team use automation to more effectively serve business needs instead of pushing them to speed up manual processes.

Another way to tackle your apprehension about automation can be to delve deeper into your Git and Jira tools, which offer unprecedented visibility and statistics into who's doing what—and how they're contributing. This information can help you uncover some of the unknowns mentioned earlier, and it can help you better understand and predict how long it will take to solve an automation problem. The more knowledge you have about your teams and how they work, the better prepared you'll feel when starting an automation project.

Sysadmins and engineers

If the roles above have more abstract fears about automation, sysadmins and engineers typically have much more visceral, personal fears about adopting automation. Their typical day revolves around these manual tasks and processes, from simple to complex, time-intensive or short. Automating them, you could reason, would obviate the need to keep a person in that role (we explore this in greater detail later in this eBook). Is this a path to outsourcing to consultants? And even if you stay in your job, how do you keep it? Who's going to train you on it? How do you find new ways to deliver value through automation?

Getting away from a known process, however tedious it might be, can be a real stressor—all the more so when you're worried that getting away from that process could eliminate your job. The truth is that sometimes personal reframing is necessary. Where you might have previously described yourself as an infrastructure engineer, you now have the opportunity to evolve into something new—an infrastructure developer. Where your manager previously looked to you to simply work manual tasks faster, you can now innovate automations and have a more direct, visible role in creating business value.

Not to downplay the efforts, knowledge, and stress it can take to make this type of shift, but it has been a proven, satisfying path for many who've taken a new interest in development practices. So, where to begin? Red Hat training and certification can make for a confident start, helping you build your skills while providing validation to your manager and others that you have the capabilities to deliver business value through automation.

Additionally, automation is a flexible solution—it can help you rapidly adapt to new business needs. At the same time, that flexibility can make it difficult to predict where and what you'll be automating in a year. Adapting to this flexibility, seeking out opportunities for collaborative automation, trying to understand your stack, and establishing a system of governance for playbooks can help enrich what you're doing in your own department and create a path toward enterprise automation.

[ A free guide from Red Hat: 5 steps to automate your business. ]

Conclusion

Quelling fears about automation is a culture shift. Open mindsets can help accelerate automation initiatives and speed time-to-value by resisting some of the segmented, rivalry-based structures that can exist between teams. Transparency about knowledge gaps and a willingness to fail early can help teams ultimately deliver faster and more confidently.