People often explain DevOps by first saying what it is not. DevOps isn’t a tool. It’s not something you can purchase off a shelf. It isn’t a team name or a job title. Experts and practitioners broadly agree: DevOps is a culture — a way of working. The strength of that culture ultimately determines whether DevOps succeeds or struggles inside your organization.
Building a strong DevOps culture is easier said than done. It starts by knowing what you are aiming for, then ensuring your entire team is working toward culture-specific goals and measurable outcomes.
“Culture can be an amorphous and ambiguous thing. Leaders can provide tangible support for DevOps initiatives by identifying specific metrics and trends that are expected to improve as a result of introducing new DevOps capabilities.”
Matt Poepsel, Senior Vice President, The Predictive Index
To consistently improve your DevOps culture, you need to assess where your culture stands today — and revisit that assessment at regular intervals. The five diagnostic questions below are worth asking yourself and your team often.
1. Are People Frequently Trying New Things?
When DevOps is working well, teams have the safety and the tooling they need to experiment, says Daniel Viveiros, CTO at CI&T. They are comfortable trying new ideas without fearing catastrophic failure.
“In our experience, we found that the new culture helps to foster an experimentation mindset. Moving things to production more often allows your company to test new ideas faster and more effectively.”
Daniel Viveiros, CTO, CI&T
High-frequency deployment and a culture of experimentation reinforce each other. As Viveiros explains: “Any company that deploys code several times a day understands the importance of breaking down big user stories into small, manageable pieces. This process is very similar to the one used to transform bold ideas into a set of hypotheses that should be quickly validated. Each hypothesis can be developed and deployed for a subset of your customer base. The collected metrics will help define the best next step.”
If experimentation is scarce, the root cause may be an emotional intelligence (EQ) deficit rather than a technical one. Steve Burton, CI/CD and DevOps evangelist at Harness, puts it directly:
“Focus as much on EQ as IQ. Make sure engineers and operators can give and receive feedback while building a DevOps culture from the ground up. The notion of ‘fail fast and learn fast’ can only evolve if feedback is received regularly and acted on by teams. Blame-game cultures are toxic and will divide teams instead of uniting them.”
Steve Burton, CI/CD and DevOps Evangelist, Harness
A practical signal to watch: do post-incident reviews focus on systemic causes, or do they devolve into finger-pointing? Teams that conduct blameless retrospectives tend to experiment more freely because failure carries a lower personal cost.
2. How Does the Rest of the Business Perceive DevOps?
Can your DevOps team clearly articulate how their work benefits the business? If not, you may be inadvertently creating an “us-versus-them” dynamic. Ben Grinnell, Managing Director and Global Head of Technology and Digital at North Highland, warns against the “trailblazer” trap:
“So often, companies run these ‘trailblazer’ projects without thinking about the fact that if you want to scale, these projects must leave a trail that others can and want to follow. Trailblazing teams are usually staffed by confident people new to the organization who have done it before elsewhere. They are encouraged to disrupt and break the rules that others are supposed to follow. It’s easy to see how you end up with an ‘us-and-them’ culture, which inhibits the transfer of skills and knowledge.”
Ben Grinnell, Managing Director, North Highland
The fix is to anchor DevOps work explicitly to business outcomes. Burton frames it this way: “Your company hired engineers to build cool things. Make sure those cool things translate to measurable business outcomes. For example, do you want your DevOps engineers to be in the business of building tools and automation, or building innovation that your customers can experience?”
Eran Kinsbruner, Lead Technical Evangelist at Perfecto, adds that business alignment also demands the right internal questions:
- Are we focusing on the most important projects to the business?
- Are we using the right technologies to deliver software that works and matches current advancements?
- Do we have sufficient visibility into everything we develop within the DevOps pipeline?
- How can we optimize the entire process, remove waste, reduce costs, and deliver more reliably?
- How can we automate more manual processes and move toward a full continuous deployment model?
Aligning DevOps teams with business goals also unlocks two cultural benefits that reinforce each other: autonomy and accountability. As Burton notes: “You can’t expect a DevOps team to have the right culture if they are boxed in with constraints and red tape from surrounding teams. Autonomy with accountability means engineers are trusted to make decisions fast and understand the impact of their actions.”
3. Who Is Blocking DevOps?
If you want to build a strong DevOps culture, you must actively look for two types of people: critics and champions. Both have an outsized influence on how quickly DevOps culture scales — or stalls.
Resistance can come from engineers who have been burned by failed transformation efforts in the past, from middle managers who see DevOps as a threat to their authority, or even from senior leadership. Mike Bursell, Chief Security Architect at Red Hat, describes one of the most common structural blockers:
“If your organization works on a model where managers are incentivized to build large teams, set specific short-term targets, micro-manage their resources, and just keep accruing larger and larger budgets, then the adoption of DevOps will be an overwhelmingly negative experience for them. They will fight against it, refuse to assign their team members to DevOps projects, and, when pushed into doing so, will attempt to stop them from participating fully in the DevOps process and generally find ways to be obstructive.”
Mike Bursell, Chief Security Architect, Red Hat
The takeaway: incentive structures and cultural blockers are inseparable. If your management incentives reward empire-building over collaboration, no amount of DevOps tooling will overcome the friction. Identifying who is blocking progress — and understanding why — is an essential diagnostic step before you can address it.
4. Are Teams Feeling Supported?
Psychological safety is a foundational ingredient of effective DevOps teams. When engineers feel supported — by their managers, their peers, and their tooling — they take appropriate risks, share knowledge freely, and escalate problems early rather than hiding them.
Signals that support is lacking include high on-call burnout, reluctance to raise issues in retrospectives, and teams siloing knowledge to protect themselves. Regular one-on-ones, clear escalation paths, and explicit recognition of collaborative behavior all contribute to a culture where people feel safe enough to do their best work.
5. Is Collaboration Being Rewarded?
In many organizations, performance systems reward individual heroics — the engineer who single-handedly saves a critical production incident, for example. DevOps culture, by contrast, rewards shared ownership: teams that prevent incidents through good practices, document their systems so others can contribute, and actively reduce bus-factor risk.
Ask yourself: does your recognition and promotion process favor individual stars, or does it celebrate teams that consistently deliver reliably together? If the answer is the former, your incentive structure is working against the culture you are trying to build.
Putting It Together: Culture as an Ongoing Practice
None of these five questions has a permanent answer. DevOps culture is not a destination — it is an ongoing practice that requires regular reflection and deliberate reinforcement. Teams change, organizational priorities shift, and new people bring new assumptions.
Treat these questions as a recurring retrospective agenda, not a one-time checklist. Revisit them quarterly, after major incidents, or whenever you onboard a significant number of new team members. The organizations that improve their DevOps culture fastest are the ones that make honest self-assessment a habit — not an event.
Original article concept sourced from enterprisersproject.com.