Culture, as an abstract collection of ideas and behaviors, is hard to pin down to a proscriptive set of requirements. In a technical team, itâs much more easy to talk about what kinds of tools to use and how to use them; the tools themselves are accessible as constructs. The people that will use those tools are complex.
The traditional friction between teams thought of as âdevelopmentâ and teams thought of as âoperationsâ boils down to a few key cultural characteristics.
A DevOps culture is one created through lots of discussion and debate. Traditionally siloed technical teams interact through complex ticketing systems and ritualistic request procedures, which may require director-level intervention. A team taking a more DevOps approach talks about the product throughout its lifecycle, discussing requirements, features, schedules, resources, and whatever else might come up. The focus is on the product, not building fiefdoms and amassing political power. Production and build metrics are available to everyone and prominently displayed. The current infrastructure is documented, and maybe someone went to the trouble of having it printed on a plotter, which is totally cool.
One of the early controversial aspects of what became DevOps was the assertion that Engineering should be doing on-call rotations. In fact, this idea was presented in a way that made it sound like your developers would want to be on call if they were truly dedicated to building the best possible product, because they were the ones responsible for the code.
I donât remember now who first articulated this point; my personal DevOps epoch begins with John Allspaw and Paul Hammondâs Flickr talk at Velocity 2009, and they may have mentioned it. Regardless, the cultural characteristic here is empowerment. The people who are empowered to directly make an improvement are the ones who are alerted to the defect.
Likewise, your team is incentivized around your core goal: creating an awesome product for your customers, whatever that product happens to be. Development isnât rewarded for writing lots of code. Operations isnât punished when all that code doesnât run as expected in production. The team is rewarded when the product is awesome, and shares in the improvement process when the product could be more awesome.
All team members should respect all the other team members. They donât actually all have to like each other, but everyone needs to recognize the contributions of everyone else, and treat their team members well. Respectful discussion and listening to otherâs opinions is a learning experience for everyone. No team member should be afraid to speak for fear of being abused or rudely dismissed.
Trust is a massive component of achieving a DevOps culture. Operations must trust that Development is doing what they are because itâs the best plan for the success of the product. Development must trust that QA isnât really just there to sabotage their successes. The Product Manager trusts that Operations is going to give objective feedback and metrics after the next deployment. If any one part of the team doesnât trust another part of the team, your tools wonât matter. Additionally, if you donât trust the people who work for you, why are they working there? Why are you?
Get Building a DevOps Culture now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
