A DevOps Wiki

View project on GitHub

DevOps Culture

Culture is probably the most important part of DevOps, both as a philosophy and a practice. Culture enforces all of the principles, methods, and practices of DevOps, and allows it to function across teams.

It is impossible to accomplish the goals of DevOps if there is not a cross-organizational culture that embraces its Values & Principles. Just having a “DevOps team” cannot by itself accomplish inter-team collaboration. It requires multiple teams all working together in the same way.

Common Themes

Lack of Silos

Most companies tend to organize their employees into horizontal teams with specific responsibilities. While these teams can be productive as a single unit, when other teams depend on them for critical tasks in a value chain, inefficiencies develop. Communication breaks down, people don’t trust each other, and this all hurts productivity and quality of work.

In a DevOps culture, all teams that work on a product should be integrated in some fashion. This means engineers, managers, and executives all need to work together, too.


  • In a traditional organization, if a software dev team needs some infrastructure, they may have to use time-consuming, complicated processes, requiring multiple levels of approval, waiting on someone to provide them their resources.

    • In a DevOps culture, the teams work together to find the least painful, most efficient way to accomplish the intended goals of both groups. This would ideally involve reviewing these requests often, removing approvals where they make no sense, and automating the building of infrastructure.

Exposure to different responsibilities

Where possible, it helps to expose team members to the work of other teams. Having software developers have to actually support their code in production, or operations personnel developing software, builds an awareness of what’s necessary to have a successful product. The goal is for everyone to have a holistic understanding of a product system.

Increased Visibility/Transparency

In order for different teams to support one another, they need to be able to see each other’s work and access key information quickly.

If there is an outage, developers may need to see logs, metrics, and get system access quickly to diagnose an issue. And if developers have a backlog of work being blocked by operations, this should be plainly visible to operations.

Being transparent about what didn’t work and owning up to problems is also a cultural thing. [Blameless postmortems] are core to DevOps.

Integrated Teams

A piece of software can’t run in a vacuum. That is to say, eventually someone is going to be running that software, and it won’t be the developers. In order to prevent problems down the road, it’s best to have both software developers and operations engineers working on the same team.

When some infrastructure needs to be prepared or changed, the conversation is already happening as the developers are beginning to write their code. The infrastructure changes can be tracked and discussed in a team scrum while development is taking place.

Another aspect of DevOps is how one team can influence the other to improve their processes. If operations engineers are using DevOps best practices in their own work, they can help software developers modify their own work to be aligned with the same process.

Even more teams can be integrated into the software development process. Quality assurance and software teams can be brought into the software development, and both learn how they will need to use or examine the software, and provide valuable feedback to improve the software at earlier stages.

Growth Mindset

User Empathy

Customer Focus

Some suggestions include actively listening to users, progressively enabling/disabling features, performing continuous experiments, and measuring key performance indicators. Use all available feedback to maximize learnings and influence value. [3]

Team Autonomy

Openness to experimentation

Production First

Understanding cycle time

With DevOps, you don’t look at improving the productivity of a single team. Instead you look at the entire value stream that goes from planning to a money-making product, also known as the “Aha to the Ka-ching!” [1]. By focusing on all the people and processes involved, you can identify the real bottlenecks and improve the things that have the most impact on a product’s end result (what customers want and will pay for).

Making IT cheaper and more efficient doesn’t give you a better product, it just means you spent less on IT. This is part of why DevOps is about inter-team collaboration.

Dealing with Change

This article from IBM details some of the challenges of trying to change a culture.

Prev: Methods | Next: Practices