The history of the industrial revolution has taught us that automation equals the loss of jobs, but it doesn’t 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 don’t 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.
Automation and the culture of change resistance
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 won’t know any of the concepts behind it and essentially can’t 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 doesn’t stop, ever. IT isn’t 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.
How well do you really know your competitors?
Access the most comprehensive Company Profiles on the market, powered by GlobalData. Save hours of research. Gain competitive edge.
Thank you!
Your download email will arrive shortly
Not ready to buy yet? Download a free sample
We are confident about the unique quality of our Company Profiles. However, we want you to make the most beneficial decision for your business, so we offer a free sample that you can download by submitting the below form
By GlobalDataEngagement is key
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.
