DevOps and Efficacy

As I always do I was checking out the DevOps group on LinkedIn and a question caught my attention “How can you gauge a company’s commitment to DevOps philosophy?” I thought that was an interesting question, and it turned out to be a very interesting discussion. Below is my reply.

This has turned out to be a very interesting discussion. I’m surprised that people seem to put rock-stars into the same category as ‘jerks’. While I’m a big advocate of the “no asshole rule” (it’s a great book, if you haven’t had the chance to give it a read I would suggest checking it out).

Not all rock-stars are jerks. Actually in my experience it’s quite the opposite, I’ve had the opportunity to work with a lot of so called “rock-stars” in my career many of which freely shared information and mentored other junior members inside of a company. On the flip side I have had the chance to work with people who were threatened by the “rock-star” type, stuck in their ways and unable to look at new ways of doing things. These people are not “rock-stars” they are a culture destroying poison that should be eliminated.

Back to the question, how do you gauge a company’s commitment to DevOps philosophy? Well I think it comes down to efficacy. First and foremost a company needs to define what are the expected outcomes from a DevOps philosophy. We can measure how many deployments happen every day, we can measure how long it takes to implement a change, we can measure a whole slew of things which tell us nothing about our commitment to DevOps. First, we need to define what the desired outcomes are.

Why is it important for our particular company to deploy 100 times per day? What is the outcome of that? I think the comment about “highly effective collaboration between Dev and Ops” is part of it; the question comes down to, yet again, what is the efficacy.

If all fascists of the organization are aligned to common outcomes (and in most companies they are not which is a huge part of the problem) DevOps starts to happen, culture and collaboration start to happen, and the commitment to DevOps starts to be measurable and obvious. There is this idea in the DevOps community around incentive, part of the problem has been that operations teams are incentivized by stability and uptime, while development teams are incentivized by feature delivery, since these two organizations are aligned around different outcomes a break down starts to occur. By creating a common set of goals, or outcomes, and align business units around those outcomes organizations can start to be successful at DevOps.

It doesn’t matter how much automation a company implements if each organization in the delivery train from development to operations are aligned to different goals, the entire structure breaks down and DevOps is a failure. It doesn’t matter how often developers and operations engineers go play ping pong if their defined outcomes are different DevOps is still a failure.

I think a big reason companies like Esty have been so successful at DevOps is because of efficacy, they might not call it that but the leadership team is aligning business units around outcomes, a common set of outcomes, and from that a whole stream of amazing things start to happen inside of the organization.