Why automation is a ‘hard sell’ in the IT workplace – Verdict

The history of the industrial revolution has taught us that automation equals the loss of jobs, but it doesnt have to be that way in IT.

You will rip my command line from my cold dead hands is a phrase actually heard at networking conferences from time to time. There are also comments about being a network engineer, not a coder.

Nobody likes to see change, especially when years have been spent learning and perfecting doing things in a certain way. But claims about job security are false companies dont employ people because they are adept with a command line, they employ them because they know about networking, front to back, inside and out, design, concepts and most importantly how it relates to the business. The last bit is called institutional knowledge and it cannot be automated nor can it be hired off the street for half the salary.

Further, claims of not being a coder or not understanding the arcane nature of coding are similarly bunk. Network engineers pass multiple levels of increasingly hard rigorous certifications and then are required to take periodical renewal education. The coding for automation, i.e. scripts and other templates, is not even close to the complexity required to earn network engineering certifications to begin with.

The very networking concepts that were so hard-won are the basis of what is required to even do the coding. A full time regular programmer may grasp the syntax more readily, but wont know any of the concepts behind it and essentially cant do the work, despite being a highly trained coder.

Yet there is fear around automation and coding for automation. IT, as an industry, is surprisingly resistant to change, despite being one of the most dynamic and ever changing fields out there. We need to foster the idea that IT is a career of change and learning, one that doesnt stop, ever. IT isnt alone. Good medical doctors are the ones that never stop learning new advancements and techniques. Chefs are always seeking new recipes, trying new things. Continuous change and improvement. Yet the culture of resistance is heavy in IT.

One way IT leaders can encourage engineers and administers is to ask teams to find ways to do things better. Let them be free to try things in the lab and present them to leadership and the team. Allocate budget to the project. This will lead them to automation in a way that they will not reject out of hand. It may not be the automation in the way leadership envisioned, but the benefits will be there anyway.

If the automation is initiated by the team, they will have pride of ownership and actually find ways that IT leaders or vendors likely have not thought of. Requiring adoption of automation tools may get the job done, but it will alienate some and lead to a much lower level of engagement and drastically increase the chances of project failure, or worse, acceptable, but mediocre results implemented by a reluctant team forced into it.

Encourage them to do things better and remind them, they are always looking for better, more efficient ways to do things in their own lives. So why resist it at work?

It will go over better than pithy speeches about inevitable change and motivational posters.

GlobalData is this websites parent business intelligence company.