I first heard the term “DevOps” from a friend in the software business when I was working at Dell HQ in Round Rock, Texas. He recommended I read “The Phoenix Project,” by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a longtime network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me.
It was enough to pique my interest, though, and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.
So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams—a typical step in any Agile transformation—doesn’t result in new dev test or agile dev teams; they remain simply “dev teams.” Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, “working in an Agile or DevOps way” becomes simply “working.”
This is why many DevOps promoters, myself included, have a negative reaction to seeing “DevOps” in job titles, job descriptions or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skill set, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department, instead of a philosophy internalized by the organization.
Of course, the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing; evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt.
Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong.”
I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps.” Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely,” but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear: The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus, being empathetic isn’t just being a good citizen, it’s also being a good businessperson.
Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology.” The statement seemed ridiculous on its face. After all, the term “DevOps”—literally a portmanteau formed from the words “developers” and “operations”—was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (systems thinking, amplify feedback loops, culture of continual experimentation and learning), to John Willis and Damon Edwards’ CAMS (culture, automation, measurement, sharing), to Dave Zweiback’s ICE (inclusivity, complex systems, empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school—DevOps principles are sound.
I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something,” adding, “not necessarily a bad thing, just buyer beware.” This wasn’t a criticism of tool providers—many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed tool set or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work.
It might take months or years of practice, but maybe one day we can all stop talking about DevOps.
