operations teams and people have to change

I've worked in operations for a long time. I've enjoyed working with very smart and technically gifted individuals. They have largely been Engineers of systems, networks, and databases. They dive deep on their specific knowledge domains and perform magic. Engineers are accustomed to clear rules and constraints. One of those constraints generally is placed around the knowledge domain which all to often manifests as an operational silo. I dislike silos and always become a bit disappointed when I hear Operations people use phrases such as

  • "That's not my problem"
  • "We infrastructure guys don't care about what runs on the server"
  • "I'm a network engineer and I don't work above layer 3"
  • "That's a developer problem"

(Disclaimer: I've heard disappointing things from Developers as well, but I'll save that for another post)

I also have conversations with Developers. I am aware of the frustrations felt by them when having to interact with Operations. Developers will seek advice and assistance from operations. When developers receive responses like the ones just mentioned, things aren't off to a good start. The Developers are often left to fend for themselves until their creativity interferes with Operations. They are a clever and resourceful bunch.

James Turnbull has a very good take on the need to treat developers more kindly in Arrested DevOps Episode 31. From the show notes:

James points out that empathy for developers is something sysadmins need to cultivate, because you don’t manage infrastructure for infrastructure’s sake.

So why am I worried about Operations?

Essentially it comes down to a couple of things.

the need for innovation

The first of of those worries is for the business. Companies need to innovate in order to remain relevant. Historically innovation has always been placed on the shoulders of Developers. There is an ever present drive for new features to stay ahead of the competition. This innovation translates directly into change. Every Operations person knows that change introduces instability. This means that Operations has the challenge to prevent new features from causing issues. In turn this presents Operations with the opportunity to also innovate. That innovation can come in many forms. For example:

  • opportunities to give Developers better environments for testing
  • opportunities for allowing Developers to self-serve
  • opportunities to move faster via automation
  • opportunities for Operations to identify stability and performance improvements
  • opportunities for automatic scaling and self-healing

These items can have a direct impact on the ability to innovate as well as the speed at which that innovation takes place. To boot, Operations will bring genuine new value to the business and begin changing the historic view of Operations as necessary evil and cost center.

job security

The second worry is for individual Operations staff. The need for pure Operations people will decline. The ability to spin up servers and provision networking is increasingly shifting toward outsourcing, [cloud services](http://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2015-state-cloud-survey#Public Cloud Leads in Breadth of Adoption), and automation tools. I suspect that before long pure Systems and Network engineers will mostly work either for very large cloud companies or small shops who aren't ready to move on. I see the number of available Operations jobs diminishing and, more importantly, salaries shrinking. This was also very eloquently suggested by Tom Limoncelli on this episode of Arrested DevOps.

I believe there are two reasons why Operations jobs will decline. The first is this: many Operations tasks are pretty straight forward to define. The steps can be outlined and handed to someone inside or outside the organization, if not automated entirely. Spinning up a Virtual Machine or turning up a switch port aren't difficult tasks. Even if a company retains a person or two with those skills, it will likely be a fairly senior role focused on architecture and design who will delegate much of the work to outsourced or (and?) low paid individuals. It's not bad yet, but I believe that's where it's heading. The second reason goes back to IT Operations being viewed as a cost center. If the considerations are purely focused on cost, then that's where the pressure will be applied and the Operations careers will take the hit.

the choice

The trends will continue. Ultimately Operations simply has to change to become a true asset to the organization. While I fully understand and appreciate the efforts which go into running stable systems, the business needs more than stability. Innovation is key and right now the Developers have the edge. Even if going all out on a DevOps adoption isn't in the chosen path, there are many ways in which Operations Teams and Individuals can increase their value to the business. Those who do so stand a much better chance of success.