Building a strong DevOps culture: A guide for business leaders

Core pillars of DevOps culture

Although the notion of a DevOps culture might seem fluffy at first, it's a concrete concept that aligns with specific DevOps values and practices. An effective DevOps culture is based on the following core characteristics.

1. Collaboration

The core purpose of DevOps is to enable collaboration. Traditional approaches to DevOps emphasized collaboration between software developers and IT operations teams, but the concept now often also brings other stakeholders -- such as QA engineers and security engineers -- into the fold. To do DevOps effectively, organizations need these various roles to collaborate and coordinate around software delivery and management.

To that end, DevOps culture is marked by a collaboration-first mindset. Engineers should instinctively aim to work together on completing tasks whenever appropriate, with or without formal collaboration structures in place.

Engineers should also assess how their areas of focus -- such as software development or security -- complement others, with the goal of ensuring that the work they perform never comes at the expense of other priorities. For instance, when developers plan a new application feature, they should think, "How will this affect post-deployment manageability for the IT ops team?" or "What are the security implications?"

When thoughts such as these are a natural part of DevOps processes, it's a sign that the organization has a healthy DevOps culture.

2. Shared ownership and accountability

Shared ownership and accountability go hand in hand with collaboration. It's only when engineers think in terms of our goals and responsibilities, rather than my goals and responsibilities, that collaboration fully flourishes.

This doesn't mean that engineers embracing a DevOps culture perform all work collectively or don't have individual areas of responsibility or focus. On the contrary, a diverse range of specializations and roles are central to DevOps. At the same time, stakeholders should consider how their work affects team outcomes.

Equally important, when something goes wrong -- such as a major software defect that engineers fail to detect before deploying an app -- the response should center on improving processes for the team as a whole to prevent the mistake from recurring, rather than blaming individuals.

3. Automation

A cultural emphasis on automation advances DevOps by inclining engineers to prefer automation whenever possible.

This is important because, although automation is essential for scaling DevOps processes and making them more efficient, stakeholders can sometimes be reluctant to fully embrace it. They might worry that they can't trust automations or that if they automate too much, their jobs will go away. The latter concern has become especially relevant as AI has become increasingly common in workflows.

A healthy DevOps culture is characterized by positive views of automation. Engineers should view automation tools as a way to reduce toil and tedium, not as a way to replace humans. They should also understand that keeping humans in the loop by requiring human oversight of automated processes is important for mitigating risks, such as tools taking undesirable automated actions.

4. Learning and continuous improvement

A final pillar of effective DevOps culture is a desire to learn and improve continuously.

DevOps should never be a one-and-done affair; organizations shouldn't adopt DevOps tools and practices and assume they've fully optimized software delivery. Instead, they must continually seek ways to make DevOps more impactful. They should, for example, seek newer automation approaches or better process designs to further speed software delivery.

Engineers who make learning and continuous improvement a cultural priority must also be open to tracking the effectiveness of current operations and finding ways to improve. They should view evidence of shortcomings, such as missed software release targets, as opportunities to improve rather than shameful failures.

Leadership's role in enabling DevOps culture

To be effective, DevOps culture must permeate the organization, not just be a value for leaders. But leaders play an important role in enabling DevOps culture.

They should start by modeling core DevOps cultural values, such as collaboration, accountability, shared responsibility and continuous improvement. When engineers see business leaders embracing these priorities, they're more likely to do the same.

Another important step for business leaders is to align incentives and KPIs with DevOps cultural values. For example, to encourage a culture that values continuous improvement, executives should reward DevOps teams not just for how often they achieve target software release velocity metrics, but also for the rate at which they improve those metrics over time.

Finally, business leaders can encourage DevOps cultural values by allowing teams the autonomy they need to operate effectively, while also setting clear boundaries. In general, it's a best practice to define what each team is -- and isn't -- expected to do within the context of DevOps and software delivery, while granting teams the freedom to decide for themselves how they'll fulfill their mission.

This is important because it sets clear expectations surrounding what teams need to do and how those expectations align with DevOps goals and cultural values. But at the same time, it gives engineers the room they need to put DevOps culture into practice on their own terms without feeling like it is being foisted upon them by leadership.

How to build a DevOps culture in practice

The exact process for putting DevOps culture into practice will, of course, vary from one organization to the next. But in general, the following are key practices that can help make DevOps cultural values an everyday part of the way organizations operate:

• Eliminate organizational silos. Collaboration doesn't work well when different types of stakeholders, such as developers and IT ops engineers, struggle to identify or communicate with one another. It's critical to remove the organizational or bureaucratic barriers that hamper cross-functional interaction.
• Evolve the organizational structure. Structural changes, such as the hiring of cross-functional roles spanning both software development and IT ops, might be needed in some cases to build an organizational foundation that can embrace DevOps culture.
• Integrate DevOps culture into hiring. Hiring processes should be designed to assess how candidates view DevOps cultural values. This can be done in a concrete way by, for example, requiring finalists for developer jobs to collaborate on coding tests with other engineers at the company, rather than the more typical practice of assigning coding work for applicants to complete on their own.
• Adopt blameless principles. DevOps culture becomes easier to put into practice when an organization adopts blameless principles: treating mistakes not as failures on the part of individuals but as failures of the organization as a whole and finding ways to improve processes in response.
• Provide learning opportunities. Leadership can help foster a DevOps culture of continuous learning by providing engineers with access to training and certification opportunities. Allowing protected time for engineers to focus on learning -- rather than completing assigned tasks -- also helps.
• Communicate clearly about automation. To mitigate the risk that engineers will be wary of automation, business leaders should clearly define the roles they expect engineers to fill in highly automated environments. This sends the message that automation will depend on humans rather than replace them.
• Seek feedback. In a healthy DevOps culture, it should be easy for anyone at any level of the organizational hierarchy to share ideas for improving DevOps culture or practices. This is another important step toward building an organic DevOps culture rather than one imposed from the top down.
• Measure DevOps cultural effectiveness. Continuously measuring the effects of DevOps culture on the business is important for finding ways to improve on an ongoing basis.

Measuring DevOps culture and maturity

It's common for businesses to track a variety of DevOps metrics, such as software deployment frequency, change lead time and failure rate. These are, at their core, technical metrics.

However, these metrics reflect not just the technical effectiveness of DevOps tools and practices but also of DevOps culture. A slow deployment frequency, for example, could result from collaboration failures rather than tooling problems.

Hence, the importance of distinguishing cultural signals from tooling outputs as a way of measuring the health and maturity of DevOps culture. To do this, organizations must invest in qualitative analysis of DevOps metrics. When quantitative data on DevOps processes yield anomalies, business and engineering leaders should dig into the data to determine the role culture plays and whether cultural changes can help mitigate undesired outcomes.

For instance, if deployment frequency is slow due to poor collaboration, leaders should assess whether bureaucratic hurdles are hindering smooth collaboration and, if so, break down those silos. This is an example of an actionable change that can streamline the implementation of DevOps culture and, in turn, improve measurable DevOps outcomes.

Conclusion: A meaningful approach to DevOps culture

It's easy to talk about DevOps cultural values or claim that an organization has a DevOps culture. It can be much harder to implement and scale a DevOps culture in practice.

But it can be done through intentional leadership that adopts actionable practices -- such as those described above -- for modeling DevOps values and encouraging their organic adoption across the organization. When this happens, businesses benefit from a cultural foundation that maximizes speed, reliability and scale through all stages of the software delivery process.

Chris Tozzi is a freelance writer, research adviser, and professor of IT and society. He has previously worked as a journalist and Linux systems administrator.