I had the opportunity, recently, to attend AutomaCon, an exciting new conference dedicated to all things automation. It was three days of sharing and discussion around systems automation. Attending, one question that floated in the back of my mind was: what is DevOps?

I don’t subscribe to the school of thought that DevOps is a job title. Likewise, devops can’t be distilled to a set of tools (though certainly its practitioners espouse configuration management, continuous delivery and performance-based monitoring). To say that it is a job title, or a set of tools, divorces it from the true change it’s trying to accomplish.

“Empathy” is one distillation for the goal of DevOps. This ideal comes from bridging the divide between developer and operations staff to make sure software delivery is a harmonious process. It’s a fine goal; noble in intent. However, I think it fails in providing helpful, practical direction. Witness: though I lead with one word, it took this paragraph’s second sentence — twenty-one words — to explain how it relates to our industry’s technical endeavors.

Rather, I prefer this distillation: DevOps seeks to reduce the penalty of failure to as near minimum as possible. Why is this important? Developers represent innovation; operations staff represent stability — usually these are at odds. By acknowledging each and building a system that copes with the inevitable tension, we enable each to perform better.

Buzzwords abound in tech. Our job as technologists is to sift the useful from the distracting and apply them to our benefit. DevOps is a revolution in our industry, but making it relatable and practical is still a challenge. I’ve shared a definition of DevOps that’s useful to me; what, in DevOps, is useful to you?