Is DevOps a Position?

I’ve heard a lot about the term DevOps. Mostly from employers or from technical recruiters looking to fill these roles. When I hear people talk about DevOps, they’re largely talking about Chef, Puppet , CFEngine or just more general configuration management. While I believe the whole Infrastructure as Code movement is extremely helpful, that’s not the end-all be-all of DevOps.

</p>

The more I learn about the DevOps movement, the more I realize it’s already falling victim to the bandwagon types in our industry. People are scrambling to build DevOps teams in addition to their development and operations teams, which defeats the purpose of DevOps entirely. DevOps is not a position, but a mindset. It’s an organizational structure. It’s a methodology. The idea of taking developers and operations staff and destroying the barriers and silos that exist between them is key to the DevOps movement.

</p>

People are finding different ways of doing this, but I think one of the best solutions might be embedding operations staff members into stream teams. This will go a long way to ensuring that the needs of the Operations staff are being considered during the development cycle and maximizing collaboration across the organization. It also pleases the separation of duties concerns of auditors, regulators and general compliance wonks.

</p>

Building a new DevOps team doesn’t work for a few reasons. First, it simply replicates the issues that currently exist, which is silos of staff members who often have disconnected goals and incentives. The goal of Operations is to keep a stable system. What better way to stabilize a system then to thwart change? The goal of developers is to deliver new features and functionality to the end user. You can’t do “new” without “change”, so these two goals are instantly at odds with one another.

</p>

If you add a DevOps silo to this picture, it will naturally land right between these two tribes. The DevOps team’s existence lends itself to the idea that it’s supposed to bridge the divide, but in reality it will become a dumping ground. Developers don’t need to worry about integration or its impact on the system, because that’s DevOps’ job. Operations doesn’t need to worry about how new deployments will impact production, because that should be vetted out by DevOps in the QA phases. Before long DevOps is reduced to simply serving as a QA Operations team and Release Engineering. This doesn’t solve the problem though. The poison still runs through the veins of the organization. You’ve just taken the antidote and diluted it.

</p>

Like a lot of problems in the world, the issue boils down to incentives. Not just monetary incentives, but the actual goals of the team and the company. The silos you build, the more you fragment the overall goals of the organization. Silos lead to blinders on to the goals of others. Imagine a team of 4 people building a car. The goal is to make a car that is “fast and cheap”. Then you split the group into 2 teams and give one group the responsibility of “fast” and the other group the responsibility of “cheap”. You can imagine the outcome.

</p>

Whether you agree with my approach to DevOps or not, what is undeniable is that DevOps is not a job title. To implement DevOps in your organization, it does require a very specific skill-set. You need developers who understand systems and the impact design and coding choices have on the servers. You need administrators that understand code at a deeper level than simple if/then/else constructs. But rebranding your people under the DevOps moniker, or worse, creating a new DevOps team is no solution.

</p>

comments powered by Disqus