Building bridges with DevOps
Five Questions for Katherine Daniels: Thoughts on adopting DevOps effectively, the importance of empathy, and new essential skills for today’s ops professionals.
Boardwalk bridge (source: Abdecoral via Pixabay)
Katherine is co-author, along with Jennifer Davis, of O’Reilly Media’s Effective DevOps, and is presenting on the topic of “Building bridges with DevOps” at Velocity New York in September. We recently sat down to discuss what it’s like when an organization adopts DevOps, and how that transition can be improved. Here are some highlights from our conversation.
You’ve written extensively on DevOps—including the book Effective DevOps with Jennifer Davis. What do organizations usually get wrong when “going DevOps”?
One of the big issues I’ve seen is organizations that look to “DevOps” as a solution without a clear understanding of what problems they are trying to solve. DevOps is not a magical one-size-fits-all panacea that can be applied the same way to every organization—what works for Etsy is not what will work for Netflix is not what will solve problems at Chef and so on and so forth. Simply copying what some other organization is doing without understanding what problems they were solving, why their solution made sense to them, and how those problems are similar to (and different from) your own is unlikely to lead to any lasting successful changes. You can’t cargo cult DevOps!
Learn faster. Dig deeper. See farther.
Ultimately, the organizations that are the most successful when it comes to DevOps are those that involve people throughout the organization working together to solve their specific problems from both technical and cultural perspectives. Adding or renaming a “DevOps team” so that you can say you’re “doing DevOps” is not setting anyone up for success. DevOps is ongoing work, not something you can do once, check off, and be done with. People throughout the organization should be encouraged to experiment with new tools, processes, and structures to help them work together more efficiently, with room to learn (and fail) in a blameless environment. DevOps has to be supported from the top down, but is often most successful when it is driven from the ground up.
What does “empathy” mean for an IT organization?
Empathy means being able to understand and identify with someone else’s problems or feelings, even if you haven’t directly experienced them yourself. It is the opposite of a shrug and a, “Well, it works on my machine.” For operations, this means understanding that not everyone wants or needs to have a deep understanding of Linux internals in order to do their jobs, and helping to create solutions and services that work for teams and individuals without the same level of operational knowledge. It is caring about the people you support and wanting to help them, rather than being a cranky BOFH.
But empathy can and should be applied throughout the entire organization, not just in IT. It is relevant to everyone who has to interact with other human beings in order to get their job done which, last I checked, was pretty much all of us! Empathy means getting to know the other people and teams you work with and understanding their goals and motivations, rather than making assumptions. It means caring about problems that don’t directly impact you, whether that be another team in your org that is being judged against different KPIs or an industry that is generally hostile to people who don’t look like you. Empathy allows us to create teams and organizations that are greater than the sum of their parts, by creating environments where more people can effectively contribute ideas and work together in order to solve problems.
There are a whole host of tools that people consider “DevOps tools”: Chef, Docker, Jenkins, etc. Is adopting these new toolsets sufficient for “doing DevOps”?
Absolutely not! Tools help us to solve problems, but not every tool is the right fit in every situation. If your dev and ops teams aren’t communicating with each other, hiring a “DevOps team” and sticking them in between is not going to help your communication issues—more likely it will exacerbate them. Similarly, adding new tools into your engineering environment won’t help you move faster or build a better product if you don’t understand the issues preventing you from moving faster or building the awesomest kittens-as-a-service product in the first place. Tools by themselves will not fix underlying cultural problems.
DevOps is much more about culture, about how we use tools to enable us to work together more efficiently, rather than about which tools you use. Etsy is often lauded as being a leader in the DevOps space and we run PHP on bare metal; you don’t have to upgrade to a shiny new bleeding-edge tech stack to create a culture of learning and collaboration. Using the cloud/docker/microservices/serverless/<insert tomorrow’s trendy new technology here> is neither necessary nor sufficient for creating and maintaining a DevOps culture. DevOps is less about which technology is being used to solve problems and more about how people are using technology together—the specific tools will change over time, but communication, collaboration, and empathy will always be used.
What are the essential skills for an ops professional in this day and age?
While operations is never going to go away completely (noops isn’t a real thing, serverless is made of servers, and anyone who’s used computers knows they aren’t actually in danger of taking over any time soon), operations as a profession is certainly changing, and skills and attitudes have to change with it. Gone are the days when you could get job security in ops by hiding away in the data center and grumpily hoarding all your mysterious ops magic to yourself. Don’t pride yourself on writing bash scripts so inscrutable that only you (and maybe not even you) can figure out what they’re supposed to be doing.
A good operations engineer these days needs to care about the experiences of the people and teams they are supporting. We should be helping our fellow engineers to create products and services that are maintainable and monitorable, viewing ourselves as guides and enablers rather than gatekeepers. Documenting our knowledge to help other people work more effectively and collaborating with other teams to understand and meet business requirements is essential. While nobody needs to be a “10x full-stack unicorn” engineer, the most valuable ops engineers are those who understand things like what makes something usable or why testing your code is important (even in ops! really!) and how to empathize and work with other people. Regardless of what team you are on, the best engineers I know are the ones who instead of saying, “Well, that’s not my problem” ask, “How can I help you create a solution?”.
You’re keynoting at the Velocity Conference in New York this September. What presentations are you looking forward to attending while there?
It’s a great lineup overall this year, and it looks like I’ll be faced with the conundrum of every multi-track conference of having to choose. (I hate choosing! Though at least all the video will be available later so I won’t miss out too much!) I’m really looking forward to hearing from Tom Limoncelli about teaching DevOps principles to ops people, learning some database infrastructure scaling from Tammy Butow, and of course hearing some quality serverless containerized webscale rants from awesome people like Bridget Kromhout and Charity Majors.