Why Network Automation Isn't a Job Killer

The meme keeps coming up: As enterprise IT embraces automation, network engineers lose jobs. The basic premise is that automation will allow companies to shed expensive operational expenses in the form of highly-paid networking specialists. The current army of certified engineers will be replaced with less expensive software generalists. 

But that’s not the value of automation; automation is about collaboration. It’s most useful at the boundary of two things: two people, two systems, two organizations. When there is some collaborative action required, automation allows information to automatically be passed to reduce the time required to coordinate activities.

The doomsday theory

Of course, as the refrain from calamity-predictors goes, capitalizing on automation requires companies to turn over their workforces and remove positions entirely, replacing highly paid specialists with lower-paid generalists. They say that while automation helps with agility, the real benefits are in reducing the number of interactions with the infrastructure requiring humans on one end of the workflow.

By eliminating these workflows entirely, the headcount required to support infrastructure can be reduced with little impact on operations.

This theory falls apart pretty quickly.  

Automation is about elapsed time, not keystrokes

The primary value of automation is not simply to remove keystrokes or make provisioning commands easier to key in. For those who argue the major benefit of automation is that complex sequences of keystrokes can be highly automated quickly and without human error, the same benefits can be attained by sending operations teams to a typing class.

For example, connecting a server requires coordination between that server and networking teams. The actual keystrokes to provision the network are not particularly complex. The time it takes for companies to turn up servers is dominated by the time required to coordinate efforts and conduct reviews of proposed changes.

Automating those activities removes the coordination, and that is where the benefit is the greatest.

Automation is about growing, not cutting

But the more salient point that automation-kills-jobs enthusiasts get wrong is somehow more fundamental. 

How much automation would be required to justify a reduction in headcount? Hint: it’s more than a few scripted workflows. Companies would have to change their tooling, introduce DevOps type frameworks, and leverage key programming and systems skills.

automation.jpg

The problem? That would take a couple of years to execute. And until it is ready, it creates a situation where a company has to double-invest: support the legacy infrastructure while building up the new operations frameworks.

The real reason to float OpEx higher is not to reduce costs in the near term -- it’s to change the cost-capacity curve. Companies pursue advanced automation because they are scaling, and they realize that they cannot grow their staff linearly with their application and user needs. If the goal is to change the cost curve to prepare for growth, then companies are unlikely to get rid of people largely because they are going to need those people as they grow anyway.  

Generalists AND specialists

However, it is true that a heavily automated future means changes in how infrastructure is designed, deployed and maintained. Companies that adopt an automation agenda will eventually move from device-led to architecture-led, and even to operations-led. 

Today, most enterprises are device-led while the large cloud providers are operations-led. The former comprises specifying behavior on a device-by-device basis, which will evolve to be more architecture- and eventually operations-led as automation takes root. The large cloud providers, on the other hand, make key operations decisions (like data modeling, telemetry, and API strategies), which shape the architectures and ultimately the devices that are deployed. In this world, the devices and their configuration and commands are subordinate to a broader operations architecture.

Yet someone still has to know how routers and switches work. 

There simply must be specialists like network engineers who understand protocols and troubleshooting. Companies that think they will eliminate these positions in some grand cost-cutting move are essentially playing Russian roulette with their infrastructure. They might do well with a couple of pulls of the trigger, but at some point, networks require people who know networking.

The bottom line

The types of companies that believe they can cost-cut their way into a more competitive position are not the ones that invest in the skills shift that will drive greater agility. The automation movement won’t drive employment down across a meaningful swath of the enterprise IT market. 

But the role of the network engineer is changing. Clever operators will find that expanding their skills to include systems-level design and some programming skills will make them even more coveted in the new world. And, of course, newer jobs that are added will likely favor these generalists as companies pair software and networking to make their automated ambitions convert to realities.