There’s been a recent buzz about DevOps that has continued to grow louder over the past few years. We’ve seen content that certainly makes a good argument that it’s explicitly a cultural change. Likewise, we’ve seen articles insisting that it’s not a culture, but a concrete process. The truth is that in order to take advantage of the benefits and values offered within DevOps, you have to consider both process and culture. The goal of DevOps is continuous delivery; and to do that well you’ll need these two concepts to come together successfully.

It’s Never Someone Else’s Problem

Our teams consist of a careful balance of skills and experience generated from years of creating products, building applications, and maintaining infrastructures and networks. When a new team is assembled, we compile the players necessary to scope, implement, deliver, manage and even enhance a service. Those skills include a spectrum of knowledge that includes traditional application developers, IT operations veterans, security engineers and network architects. Their experience levels bring together senior staff members with strong opinions, deep knowledge and perspective who are pairing side by side with the likes of conventional IT operations members. We focus on assembling talents from various backgrounds to create a team of very proficient generalists, rather than bringing in a cadre of specialists for various project needs. As a result of forming a team with such a diverse background, we have a constant opportunity to grow through daily cross training and exposure to new experiences.

We turn those assorted backgrounds into four roles on our teams: Engineers, Engineering Managers, Product Analysts, and Product Owners. Everyone contributes. All engineers, including the engineering manager, check in code daily. Each feels a responsibility for the customer experience. And, we all have an obligation to ensure consistent uptime of the platform. As a result of our DevOps culture, we all hold each other accountable for the quality of the service that we create and support.

Dev + Ops


One of the key practices that we use to create this shared accountability is through pair programming. Bringing together team members from a developer and an IT operations background, and then asking them to work closely together in pairs creates long lasting results for the team and for the product. Team members with a system administration background will now better understand the application’s architecture and technology stack, while developers will learn more about the environments in which the application will run. Sharing that foundational knowledge about the full infrastructure and application stack creates a very resilient team and an even better customer experience.

We’re in this Together

The team interaction and involvement with one another doesn’t stop with pair programming alone, however. Those engineers in our teams, who were once called developers and IT operators, attend planning meetings with product owners and analysts together as a team. We all attend daily stand ups to discuss current work in process. We also collectively participate in release activities in order to create and to maintain a shared understanding of what each other is working on and how the service is performing. As a result, all members of the team understand the key performance and availability metrics to measure, and track them against larger business goals.

All engineers are also on call. The same set of resources are responsible for support requests, minor and major enhancements, and urgent operational issues. This responsibility helps to solidify the “you build it; you run it” culture. It also creates a different perspective for the developer knowing that they, or their team, might have to deal with subpar quality code. This mindset helps all of us to hold each other accountable for the value of our work. Personally dealing with any of the challenges in the service also exposes each of us to the opportunities to make the service better. We automate as much as possible, and we look for ways to reduce any failure opportunities and manual intervention.

Peaches and Rainbows

Though we’ve come to find a nice balance of development and operational practices within our teams, it’s not all peaches and rainbows. Different backgrounds and experience generally lead to each member of the team having different value structures. So, where an operational background might value internal tools for performance visibility, a development background might value more creative development within the user interface. To balance those influences, the product owner is constantly working to find areas for automation and to demand consistency within the customer experience. It’s critical to ensure that all members of the team hold a shared consciousness of the vision and goals for the product.

Getting Better All the Time

In the end, our job is to solve problems. Our DevOps approach is about bringing together people who have good experience, with varying perspectives to help solve problems in the most effective way in a short period of time. We deliver on our promises to the business, and to our customers. We continually work on developing collaboration, clear communication and trust between our team members. The results of a well-balanced and motivated team are obvious. Our speed to deploy new features improves, given that we have good visibility of the challenges in front of us due to the mix of experience. We have less issues with quality concerns when we release a new feature based on the array of skill sets and knowledge coming from previous roles. Further, if we do encounter unexpected challenges, our mean time to repair has shortened due to the deep understand that each of our team members have related to the full solution stack. This creates an environment that encourages a consistent, reliable customer experience.

We are continually learning and improving as a team. We spend less time fighting fires and more time focusing on great work. When you don’t have to spend time triaging as a result of bad code or poorly designed infrastructure, there is more time to focus on improving the service and creating an even better customer experience. In DevOps, the culture enables the practices, and vice versa. You can’t do one without the other.