Download our latest eBook, Bridging the Gap: DevOps to SRE!  View here.

DevOps Culture: How to Build a Stronger Team

Trying to improve your DevOps team? We’ll explain what DevOps culture is, how it benefits your team, and how you can build it within your organization.


So what is DevOps culture? The main goals of DevOps culture are to increase collaboration and communication between teams, to give all participants a shared responsibility in the project, and to emphasize learning opportunities instead of spreading blame when things go wrong.

What is DevOps culture?

DevOps culture is a set of values that reinforce DevOps practices. These values include prioritizing collaboration and communication, sharing ownership for projects, finding every opportunity to learn, maintaining continuous improvement, and emphasizing the customer impact in decision making. By following these values when developing practices, you can achieve your DevOps goals.


DevOps culture is important to implement alongside practices. DevOps practices will prove beneficial on their own in improving alignment and development velocity, but they can only be so effective if people are following them because they have to. Instead, having a strong cultural foundation will naturally lead teams to live out these principles in every circumstance.

DevOps culture vs. SRE culture

DevOps and SRE share the philosophy that practice and procedure should emerge from a cultural base and they also overlap across many cultural ideas. By looking at where they have similarities and differences, we can better understand DevOps principles. Here’s a chart  summarizing their relationships:


DevOps Culture SRE culture
Collaboration and communication  Link together development and operations through the software development lifecycle. Contextualize learning for all with concepts and practices  like SLOs and retrospectives.
Shared ownership Every team in the development lifecycle shares responsibility for the maintenance of their code when moving its way through to production. Be blameless when dealing with incidents, and look for shared systemic causes.
Learning from everything Integrate the experience of operations back into development, and share developer’s expertise with operations. Study incidents by using retrospectives to find patterns and grow more resilient.
Maintaining continuous improvement Use continuous integration and continuous delivery to frequently make small incremental changes. Review and revise practices continuously. 
Emphasizing the customer React quickly to changes in customer needs with practices like Agile. Use practices like SLOs to strategically align on what matters most to customers. 


As you can see, they have many of the same focal points in developing culture. They generally want to achieve the same goals. However, DevOps focuses more on the end result of releasing software, whereas SRE focuses on incident management guided by service level objectives (SLOs).

Implementing DevOps culture

Implementing these cultural DevOps principles involves both changing attitudes towards these ideas and creating policies that utilize them. For each principle, we’ll look at how you can implement it, what benefits you’ll see, and what challenges you may face when implementing them.

Prioritizing collaboration and communication

At the heart of DevOps is the relationship between development and operations teams. The two teams collaborate across a lifecycle to create and support code from design to deployment. This relationship reflects the fundamental value of collaboration and communication.


Implementation: Implementing collaboration and communication involves breaking down silos between individuals and their teams. Ensure that resources are shared among everyone, with open meetings to discuss and develop them. Promote the idea that everyone has an insight or perspective that can help, and work to give everyone an opportunity to help.


Challenges: It can be challenging to align different teams. Development and operations often have conflicting goals. Development might want to push new features as soon as possible, whereas operations might want to delay deployments to ensure operational code. To help the teams work together, focus on shared goals that transcend each of their interests. At the fundamental level, all teams are united in wanting to deliver customer satisfaction. Orienting development and operations goals around customer satisfaction will help you find an agreeable medium. 


Benefits: Once silos are broken down, you’ll see profound benefits in your development lifecycle. Not only will you deliver code that the operations team is happy with, you’ll be able to take advantage of the expertise across all teams.

Shared ownership for projects

Communicating and collaborating leads to questions of who has ownership and responsibility for a given project. This DevOps cultural principle encourages you to share ownership of projects broadly among engineers. Rather than development writing code and then “throwing it over the wall” for operations to deploy and maintain, both teams work together through the entire lifecycle.


Implementation: To implement a culture of shared ownership, set up an inclusive process through the entire development lifecycle. Have operations share concerns from the earliest stages of design to ensure they’re capable of running and maintaining the code. Likewise, have development collaborate with operations while the code is in production to improve maintainability.


Challenges: Development and operations might have conflicting priorities at some stages of the lifecycle. Operations might be more risk averse when designing features, focusing on potential problems in maintenance. Development might not want to shift focus to helping maintain old code when working on new features. Help them see eye to eye by emphasizing that sharing these responsibilities leads to less work in the long run. Once they’ve gone through the cycle a few times, they’ll see that they’re spending less time revising old code and making more progress on future development.


Benefits: Once ownership is shared among teams, your improvements and responses will be much faster and more effective. Before, teams might try to pass off the work onto each other, feeling that the other has the responsibility to fix an issue. With shared ownership, they’ll understand their role in how the code was developed, and be able to efficiently solve their share of the problem.


Learning from everything

A big part of breaking down silos is finding opportunities to learn from a wider range of experiences. When operations teams face a challenge in maintaining code in production, it should be shared with developers. When developers have an insight into how changes will affect the code while it's running, it should be shared with operations. By finding chances to learn at every stage and sharing them with every team, your processes will get faster and smoother.


Implementation: Start building processes around documenting learning as it happens. When something goes wrong in production, create an incident retrospective. While designing and developing, document potential issues and leave commentary around why decisions were made. Then set up meetings for both developers and operators to review these documents.


Challenges: People may resist new programs that involve more meetings or more overhead. Engineers are busy, and might not see the benefit to creating documents or making time to review. The easiest way to convince people is with results. It only takes one key insight cropping up from one of these meetings for people to start eagerly awaiting them. Encourage them to take the time by showing how well these practices have worked for other organizations.


Benefits: The insights you gain from learning at all of these stages can be profoundly impactful. The collaboration between teams leads to finding shared issues that can tap into fundamental challenges with the organization. For example, development and operations discussing what led to a bug can reveal needed changes in how features are designed, how roadmaps for releases are developed, and how headcount is allocated. Involve product, customer success, and management teams in these discussions to allow the changes to be even more impactful.

Maintaining continuous improvement

DevOps culture advocates for making small, continuous improvements instead of infrequent major changes. Using principles of continuous integration and continuous deployment, changes can flow into production as quickly as possible, allowing you to react to customer needs immediately. This also minimizes the risk of major failure resulting from deployments, as no disastrously huge mistakes will be deployed.


Implementation: Build processes to integrate and deploy faster. This could involve version control to make change integration more reliable, automation tools to remove toil in deployments, and testing throughout the lifecycle to catch bugs earlier.


Challenges: Some organizations have an established culture around big pushes. They can be seen as opportunities for celebration and ways to punctuate the continuous nature of development. It can be difficult to reestablish the same attitude towards continuous improvement. Try to keep the feeling alive by tracking progress and creating milestones to celebrate. It can also be difficult to build these more complex practices to frequently push code. Focus on the benefits to motivate you.


Benefits: Continuous improvement offers many benefits over big infrequent releases, such as:


  • Responding to changes in customer need faster
  • Reducing the risk of major deployment disasters by making each change smaller
  • Giving more opportunities to catch bugs sooner
  • Encouraging optimization of deployment processes, thereby reducing toil, and
  • Instilling an attitude of wanting to improve all aspects of the system at all times.

Emphasizing the customer

At the end of the day, one factor matters more than any other: customer satisfaction. If your customers are happy to use your service and not leaving, that means things are going well. DevOps principles use this perspective to align teams and prioritize.


Implementation: First, you need to understand what’s important to your customers. Build user journeys to model how your service is typically used. Think about what matters most to customers in these use cases. What steps are essential to function, and which are just annoying if they break? Use this to inform tools like SLOs that let you prioritize around customer happiness. This is an example of SRE practices reinforcing DevOps values.


Challenges: Customer needs can change. When your development objectives are based around customer happiness, these changes can cause major adjustments to your plans. DevOps integrates well with other practices, like Agile, to quickly orchestrate sprints. These can steer your development back towards the latest customer needs.


Benefits: Once you’re aligned on this customer emphasis, you can make decisions with less friction and move quicker towards shared goals. You’ll be able to understand customers’ needs more accurately and respond more effectively. 

Building a team with DevOps values

Cultivating a DevOps culture at your organization is boosted by a team that will model it for others. You have to develop this team from several different angles.


Hiring for DevOps culture: Hiring people who are culturally aligned with your organization will get you off on the right foot. Ask cultural questions in the interview about how they view concepts like collaboration, alignment, and prioritization. Don’t have a specific answer that you’re looking for, but look for people who give thoughtful responses. They’ll be able to understand the value of your perspectives and realign themselves.


Building relationships: Encourage principles of collaboration and communication from the start by building relationships between new and veteran staff. Have engineers champion cultural values to new hires, and make sure they’re working from that perspective from the start.


Coaching for DevOps culture: When managing engineers, do so while emphasizing how behaviors will or won’t align with cultural principles. Rather than just instructing, derive your instructions from this fundamental cultural value. This will help them have greater agency and determination for the task, as they’ll know what their ultimate goal is.


It’s also easy to inspire cultural change when teams align on universal tools and processes. For example, tools that make tasks easier to complete also encourage people to collaborate more often and share information with others, including lessons learned on the job. Blameless SLOs, retrospectives, and runbooks reduce toil and allow teams to establish smooth workflows and shared processes around incident management and SRE practices. To find out more, request a demo!



About the Author
Emily Arnott

Get the latest from Blameless

Receive news, announcements, and special offers.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Schedule a demo with us today!