Building a DevOps culture: the role of leadership in the ...

Peter, the CTO at an e-commerce company, has invested more than two million zlotys in “DevOps transformation” in the last year. He has bought the best CI/CD tools on the market, his teams work on Kubernetes, and a huge monitor with impressive dashboards from Grafana hangs on his office wall. Still, he listens with growing frustration to one team’s daily meeting. “My code has been ready since yesterday,” says the developer, “but it’s stuck because I’m waiting for the Ops team to allocate resources to me on the new test environment.” A few hours later, at the coffee machine, she hears an engineer from the Ops team complaining to a colleague: “Here we go again. The dev team ‘threw us over the fence’ with some unstable code just before the weekend, and now I have to put the system back up at night.” Peter realizes with bitterness that despite millions of dollars invested in technology, the invisible but powerful “wall of confusion” between developers and operations still stands intact. He bought the tools, but didn’t build the culture.

Peter’s story is a universal tale of one of the biggest pitfalls in the world of modern IT. Many organizations, fascinated by the promise of speed and automation, treat DevOps as a purely technological problem - a list of tools to implement. This is a fundamental mistake. Tools are important, but they are only tools. True DevOps transformation is 80% cultural transformation. It’s a revolution in the way people think, communicate and collaborate. Without changing people’s hearts and minds, even the most expensive CI/CD pipeline will be just a shiny facade on an old, dysfunctional building. This article is a guide for technology leaders - architects of change - who understand that their most important task is not to select tools, but to consciously shape the environment in which a true DevOps culture can be born and flourish. We will show that leadership is the key, often missing, ingredient for a successful transformation.

Why is investing in DevOps tools without changing the culture a recipe for failure?

“Improving daily work is even more important than doing daily work.”

— Gene Kim, The Phoenix Project | Source

The phenomenon in which organizations spend huge amounts of money on modern DevOps tools, yet fail to achieve the promised results - faster and safer deployments - is so common that it has even earned its own name: “Cargo Cult DevOps.” This term, taken from anthropology, describes a situation in which people unreflectively imitate external rituals and forms (e.g., building airstrips for airplanes out of bamboo) without understanding the underlying principles, and expect this to bring the same results (the appearance of supply planes).

In the IT world, the “Cargo Cult DevOps” manifests itself precisely through a fixation on tools: “We’ve implemented Kubernetes, so we’re DevOps.” “We use Jira and Jenkins, so we’re agile.” Such an approach is doomed to failure because it ignores the fact that tools are just gas pedals of existing processes and behaviors. If your culture is based on silos, lack of trust and shifting responsibility, modern tools will only allow you to push problems “over the fence” faster and more automatically.

Symptoms of the “Cargo Cult DevOps”:

New tools, old problems: You have an automated pipeline, but deployments still require a series of manual approvals from different, siloed teams (e.g. QA, Security, Ops).
“DevOps team” as a new silo: Instead of integrating competencies, you create a new team called “DevOps,” which becomes a bottleneck. Developers, instead of managing their code themselves, create “tickets to DevOps” to have DevOps build them a pipeline or set up monitoring.
Metrics focused on activity, not value: You measure “number of deployments” or “percentage of automation,” but you have no idea whether those deployments actually bring value to customers and whether the system is stable.
Blame culture: When a failure occurs in production, the first reaction is not to collectively solve the problem, but to look for someone to blame: “It’s a bug in the developers’ code!” vs “It’s a problem with the server configuration by Ops!”.

Investing in tools without first or simultaneously investing in a culture change is like trying to fit a Ferrari engine into the chassis of an old tractor. The tools may whirr, but the whole system won’t go anywhere anyway. Real transformation has to start at the foundation - by changing the way people interact with each other.

What is DevOps culture and what are its fundamental values according to the CALMS model?

DevOps culture is not a vague, esoteric concept. It’s a concrete set of values and principles that, when applied consistently, create an environment conducive to fast and secure software delivery. One of the best ways to understand and define this culture is the CALMS model, popularized by Jezz Humble, one of the authors of the groundbreaking book Continuous Delivery.

CALMS is an acronym for the five pillars that must be developed simultaneously for a DevOps transformation to succeed.

C - Culture: This is the heart and foundation of everything. It refers to creating an environment based on cooperation, trust and shared responsibility. This means breaking down silos, promoting open communication and, most importantly, building psychological safety where people are not afraid to experiment and make mistakes. A DevOps culture is one in which failure is treated as an opportunity to learn, not to find fault.

A - Automation: This is the technical pillar that supports the culture. It’s about automating everything that is repetitive and prone to human error - from building code to testing to deploying and configuring infrastructure. Automation frees people from tedious work, allows them to focus on creative tasks and creates a fast, reliable feedback loop.

L - Lean (Lean management): These are principles derived from “Lean” (lean manufacturing) thinking, popularized by Toyota. In the DevOps context, it means an obsessive focus on delivering customer value and eliminating waste. Waste is anything that doesn’t add value: partially completed work, long waits in queues, complicated approval processes, manual error correction. DevOps seeks to create small batches of work and ensure that they flow smoothly, quickly through the entire system.

M - Measurement: This is the principle of “you can’t manage what you don’t measure.” DevOps culture is a data-driven culture. Instead of relying on intuition, metrics are collected and analyzed at every stage of the software development lifecycle. But it’s not about arbitrary metrics. It’s measuring what really matters - key metrics such as DORA metrics (deployment frequency, change lead time, failure rate, service restoration time) that reflect both speed and stability.

S - Sharing: The last pillar closes the loop. It refers to promoting a culture of sharing knowledge, experiences and successes across teams and departments. It’s about breaking down information silos. Sharing is done through code reviews, internal technical presentations (tech talks), documentation, joint on-call and programs such as guilds or “Dojo.”

The CALMS model makes it perfectly clear that culture is not just one element of DevOps - it is the overarching framework within which all other practices are contained.

What role does psychological safety play in building trust and cooperation?

One can venture to say that **psychological safety is a key single factor in the success of a DevOps transformation **. This concept, defined by Amy Edmondson of Harvard Business School, means “a shared belief among team members that the team is a safe place to take interpersonal risks.” In practice, it means creating an environment where people:

They are not afraid to ask “stupid” questions.
They are not afraid to admit error or ignorance.
They are not afraid to propose bold, unconventional ideas.
They are not afraid to constructively challenge the status quo or decisions of superiors.

Without psychological safety, all the lofty ideas of DevOps - collaboration, shared responsibility, learning from mistakes - remain empty slogans.

Why is this so crucial to DevOps?

Enables collaboration across silos: For a developer and an operations engineer to work together effectively, they must trust each other. They need to feel safe enough to talk openly about problems and ask each other for help without fear of being judged or ridiculed.
It is a condition for learning from mistakes: In a culture with low psychological safety, when failures occur, the natural reaction is to hide mistakes and look for a scapegoat. This prevents an honest root cause analysis (post-mortem) and learning lessons for the future.
Drives innovation: Innovation requires experimentation, and experimentation inherently involves the risk of failure. If people are afraid of the consequences of failure, they will stick only to safe, known solutions, which kills creativity and progress.
Improves quality: When a developer is not afraid to say “I’m not sure how to test this correctly, can someone help me?”, the quality of the code increases. When a tester is not afraid to challenge requirements that seem illogical to him, better products are created.

How can a leader build psychological safety?

This is one of the most important tasks of a leader in a DevOps culture.

Model sensitivity yourself: publicly admit your own mistakes and ignorance. Show that it is normal and acceptable.
Treat failures as learning opportunities: Proactively defend the team against the blame culture. When something goes wrong, focus on asking “what can we improve in our system?” rather than “who broke it?”.
Listen actively and with empathy: Encourage questions and dissenting opinions. Thank people for their courage when they challenge your ideas.
Create a clear framework for risk-taking: Define where experimentation is desirable and where caution should be exercised.

Psychological safety does not mean a lack of accountability or standards. It means creating an environment where people feel motivated and secure enough to strive for the highest standards without the paralyzing fear of failure.

How can a leader break down silos and promote shared responsibility (shared ownership)?

Organizational silos - that is, isolated, often competing departments (Dev, Ops, QA, Security) - are the biggest enemy of DevOps value flow and culture. The role of leadership is to consciously and systematically tear down these walls and build bridges based on common goals and shared responsibility.

1 Create common, overarching goals: Silos often arise because each department is optimized and rewarded for something different. The development team is measured from “number of features delivered” (speed), while the operations team is measured from “uptime” (stability). This naturally creates conflict. The leader must define common, overarching goals for all teams involved in the product lifecycle. Instead of separate KPIs, introduce common DORA metrics or OKRs that measure both speed and stability. When everyone is rewarded for the same outcome (e.g., “reducing time from idea to customer value while maintaining 99.95% availability”), they start playing on the same team.

2 Change the structure to reflect the flow of value: As Conway’s Law says, the architecture of a system reflects the communication structure of the organization. To break down silos, you often need to change the organizational structure. Instead of teams organized around functions (Dev, Ops, QA), create cross-functional product teams (stream-aligned teams) that have all the competencies needed to deliver value from start to finish. Such a team, consisting of developers, a QA engineer and an Ops/SRE specialist, takes full responsibility for its product - “you build it, you run it.”

3 Enter practices that promote cooperation:

Joint on-call rotation: Include developers in production on-call. Nothing builds empathy and a sense of responsibility for code quality more than having to get up at 3 a.m. to fix a bug you created yourself.
Joint sessions and workshops: Hold regular interdisciplinary sessions, such as threat modeling workshops, planning sessions or “blameless post-mortems” (discussed further below) that include representatives from all roles.
Rotation programs: If possible, consider temporarily “lending” people between teams - for example, an operations engineer might spend one sprint working with the development team to better understand their challenges.

4 Build a common “space.” Both in the physical and virtual sense.

Co-location (if possible): Placing members of one product team in the same physical space drastically improves communication.
Common tools: Make sure everyone uses the same tools for communication (Slack/Teams), work management (Jira) and monitoring (Grafana). This creates common ground and transparency.

Tearing down silos is a difficult process that is often met with resistance. It requires a leader’s determination, consistency and continuous communication of the vision of “one team” working together for product success.

How do we create a blameless post-mortems culture and turn failures into learning opportunities?

“Blameless Post-mortem” (incident analysis without blame) is one of the most important and transformative rituals of DevOps and SRE (Site Reliability Engineering) culture. It is a structured meeting that takes place after any significant production failure or incident. Its goal is not to find a culprit, but to understand the systemic causes that led to the problem, and to develop specific actions that will prevent it from happening again in the future.

Why is “blameless” so important? Traditional failure analysis often turns into a witch hunt. We look for “human error” and the person who made it. This approach is destructive. It leads to fear, hides problems and discourages honesty. People, fearing punishment, will not share key information, making it impossible to get to the real root cause.

The “blameless” philosophy starts from a fundamental premise, popularized by Sidney Dekker: “People do what makes sense to them at any given time with the knowledge they have.” Human error is not the cause of failure, but a symptom of it. Instead of asking “Who broke it?”, we ask “Why did our system allow one person’s mistake to cause the whole system to fail? What safeguards failed? What processes can we improve?”

How to conduct an effective “Blameless Post-mortem”?

Start with facts, not opinions: The meeting should begin by creating a precise timeline of the incident, based on data from logs, metrics and alerts. When did the problem start? When was it detected? What actions were taken?
Focus on systemic causes: Instead of stopping at “Johy implemented bad code,” ask a series of “why?” questions. (5 Whys technique):
Why did Janek implement bad code? -> Because there was no test to catch it.
Why wasn’t there a test? -> Because the code review process was not rigorous enough.
Why was the process not rigorous? -> Because the team was under time pressure.
…and so on until you get to the deeper, systemic causes.
Work out specific corrective actions (Action Items): The outcome of the meeting must be a list of specific, owner-assigned and time-bound tasks to improve the system. These can be technical tasks (e.g., “Add a new automated test”, “Improve the alert system”), process tasks (e.g., “Revise the pre-implementation checklist”) or educational tasks (e.g., “Organize training on X”).
Make the results public: The post-mortem report should be publicly available to the entire organization. Transparency builds trust and allows other teams to learn from mistakes.

The role of the leader: The leader must be the guardian of the blameless culture. He or she must proactively interrupt any attempts to find fault and consistently steer the discussion toward a systemic track. He must also ensure that the corrective actions developed are actually implemented, showing that the process has real meaning. Creating such a culture is one of the most powerful investments in an organization’s long-term resilience and ability to learn.

What changes to the metrics and employee evaluation system are needed to support DevOps goals?

The system of how we measure and reward people has a huge impact on their behavior. If you want to build a collaborative culture while measuring and evaluating people based on individual, often conflicting, goals, your transformation is doomed to failure. Implementing a DevOps culture requires a fundamental overhaul of your metrics and employee evaluation system.

The problem with traditional metrics: Traditional IT departments often use metrics that reinforce silos and promote inappropriate behavior:

Development team: Measured from “velocity” (the number of “story points” delivered in a sprint) or the number of features delivered. This motivates rapid “push” of code, often at the expense of quality.
QA team: measured from “number of bugs found.” This can lead to antagonism with developers and a focus on trivial bugs to “boost” statistics.
Operations team: Measured from “uptime” (uptime) and number of closed tickets. This motivates resistance to any change, as any change is a potential source of instability.

These local optimizations lead to global disaster. Each department, seeking to maximize its metrics, sabotages the work of others.

Shift to system and team metrics: In a DevOps culture, move away from individual and siloed metrics to metrics that measure system-wide performance and promote collaboration.

Focus on DORA metrics: The four key DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service) are ideal because they measure both speed and stability. Moreover, these are metrics that are influenced by all teams - Dev, QA and Ops. Improving these metrics requires collaboration.
Measure business outcomes (outcomes), not activity (outputs): Instead of measuring how many features were delivered, measure what impact those features had on key business metrics (e.g., increased conversions, decreased customer churn). Use the OKR framework to link the work of technical teams to the company’s strategic goals.
Evaluate and reward teams, not individuals: Move from individual bonuses and evaluations to evaluating and rewarding entire product teams for achieving common goals (e.g., meeting OKRs). This promotes cooperation and mutual assistance within the team.

Change in employee evaluation: In addition to changing hard metrics, “soft” evaluation criteria should also be changed. In addition to goal achievement, the a

ual evaluation should include criteria such as:

Cooperation and helping others: How actively did the person share knowledge and help members of his and other teams?
Contribution to process improvement: What improvement initiatives did the person propose and help implement?
Development and learning: What new skills did the person acquire and how did they put them into practice?

Changing the metrics and evaluation system is a powerful lever for cultural change. It sends a signal to the entire organization that “the old rules no longer apply” and that the new highest value is to work together toward a common goal.

What role do programs such as “Dojo” or internal guilds play in scaling the culture?

As an organization grows, maintaining a consistent culture and effectively spreading best practices becomes a huge challenge. What worked in a small IT department of 30 people will not work in an organization of 300 engineers. Scaling a DevOps culture requires creating conscious, structured mechanisms for learning and knowledge sharing. Two such powerful mechanisms are “Dojo” and “Guilds.”

“Dojo” - an immersive learning center: The “Dojo” concept, taken from Japanese martial arts, is, in the context of IT, an immersive, physical or virtual environment in which teams “immerse” themselves for several weeks to learn new ways of working under the guidance of experienced trainers (coaches).

How does it work? The product team comes to the Dojo with its real business problem or a piece of the product to work on. For 4-6 weeks, they work on this task, but in a completely new way - using practices such as Test-Driven Development (TDD), pair programming, CI/CD, containerization, etc.
Role of coaches: Dedicated, experienced coaches (internal or external) work side-by-side with the team to teach, mentor and help overcome obstacles in real time.
Goal: The goal of the Dojo is not just to “deliver functions.” The main goal is for the team, once they leave the Dojo, to be able to continue working independently in a new, more efficient way. It’s deep, hands-on learning that changes habits and mindsets.

The Dojo is an extremely effective, albeit expensive, way to “instill” DevOps DNA in more teams and create internal experts who can then become coaches themselves.

Guilds - horizontal communities of practice: Guilds, popularized by the so-called Spotify model, are informal, company-wide groups of people who share a common passion or area of interest, regardless of which product team they work in.

How does it work? Anyone can start a guild or join one. Examples include “Front-end Guild,” “Security Guild,” “Automated Testing Guild” or “AI Guild.”
Purpose: Guilds are a platform to horizontally share knowledge, discuss issues, establish good practices and standards, and promote innovation throughout the organization.
Form of operation: Guilds hold regular meetings, maintain dedicated channels on Slack, organize internal presentations (tech talks), and maintain shared documentation and libraries.

Guilds are the answer to the problem of knowledge silos forming in organizations based on autonomous product teams. They ensure that a front-end developer from team A can learn from a front-end developer from team B, and that good practices developed in one place are quickly spread throughout the company.

Implementing programs such as Dojo and Guilds is a conscious investment in building a “learning organization” - an organization that is able to systematically improve its skills and adapt to changes in scale.

What are the biggest mistakes leaders make when trying to build a DevOps culture?

The road to a mature DevOps culture is full of pitfalls, and many transformations end in failure or disappointment. Most often, the cause of these failures is not technical problems, but mistakes made at the leadership level. Here are the most common ones:

1. delegating transformation (“the IT department’s problem”): The CEO or CTO a

ounces that “we’re doing DevOps,” allocates budget for tools, and then delegates all responsibility to middle managers and forgets about the issue. It doesn’t work. DevOps transformation is a profound organizational change that requires continuous, visible and active support from top management. The leader must be the primary sponsor and evangelist of the change.

2 Lack of clear and consistent “why” communication: Leaders often focus on communicating “what” we’re doing (we’re implementing Jenkins) and “how” we’re doing it (we’re moving to sprints), but they forget the most important thing - the “why.” Why is this change necessary? What business problem are we trying to solve? How will it affect the daily work and future of the company? Without an inspiring and coherently communicated vision, people will see the change as just another meaningless “initiative from above” and will resist.

3. expecting immediate results and underestimating the scale of the change: Cultural transformation is a process that takes years, not months. Leaders who expect spectacular results in a single quarter quickly become discouraged and withdraw support. Worse, they often underestimate how profound a change in mindset and habits DevOps requires, leading to frustration and unrealistic expectations for teams.

4 Ignoring the “frozen middle” (frozen middle management): Often the greatest resistance to change comes not from engineers, but from middle managers. In a DevOps culture, where autonomy and self-organization of teams is promoted, their traditional role, based on control and micromanagement, is threatened. Unless a leader invests time in convincing, training and redefining the role of these managers (e.g., as coaches and mentors), they will become active or passive saboteurs of the transformation.

5 Inconsistency between words and actions: The leader talks about a “blameless culture” at every meeting, but when the first major failure occurs, he publicly seeks to find fault. He talks about “cooperation,” but still rewards individual “stars” and promotes rivalry between departments. Such hypocrisy is immediately palpable and destroys trust, which is the foundation of any cultural change. A leader must be a living embodiment of the values he promotes.

Avoiding these mistakes requires the leader to have self-awareness, empathy, patience and great determination. This is the most difficult, but also the most important part of his job.

What does the DevOps culture maturity matrix look like and what role does the leader play in it?

The table below presents a DevOps culture maturity model that can serve as a tool for leaders to diagnose the current state of the organization and plan next steps. It shows the evolution in five key dimensions of culture and highlights how the role of the leader changes at each stage.

Dimensions of Culture	Stage 1: Silo (Adversarial)	Stage 2: Collaborative.	Stage 3: Integrated (DevOps)	The role of the Leader at a given stage
Collaboration	Departments (Dev, Ops, QA) see each other as enemies. Communication is formal and conflictual.	The first "bridges" and informal relationships are formed. Teams begin to talk to each other to solve problems.	There are no more "dev" and "ops." There are cross-functional product teams working together toward a common goal.	Breaking down walls: initiating joint meetings. Defining common goals. Mediating conflicts.
Responsibility	"It's not my problem." Shifting responsibility "over the fence" is the norm.	Teams are beginning to take responsibility for their part of the work, but a global view is still lacking.	"You build it, you run it". The product team takes full responsibility for its code from conception to production and maintenance.	Changing the structure: Product team design. Introducing joint on-call teams. Delegation of authority.
Approach to failure	Witch hunt. Looking for the guilty party is the priority. Failures are being covered up.	Failures are analyzed, but the discussion often focuses on human error. Fear still exists.	A "blameless post-mortems" culture. Failure is treated as an opportunity to learn and improve the system.	Protecting the team: Modeling a blameless culture. Taking responsibility publicly. Directing discussions to systemic causes.
Processes and Automatio	Processes are manual, slow and bureaucratic. Automation is seen as a threat.	Automation "islands" appear in individual silos. Lack of a consistent, integrated process.	There is a fully automated, integrated CI/CD pipeline that is owned by the product teams.	Investing in tools and removing obstacles: Providing a budget for automation. Removing bureaucratic barriers. Promoting standardization.
Measures of Success	Each silo has its own, often contradictory, KPIs (e.g. Dev - speed, Ops - stability).	The discussion of common metrics is beginning. Measuring activity (outputs) still dominates.	The entire organization measures and optimizes against the same systemic metrics (e.g., DORA) and business outcomes (outcomes).	Changing the incentive system: Implement DORA/OKR metrics. Rewarding teams rather than individuals. Link IT goals to business goals.

Need testing support? Check our Quality Assurance services.

Let’s discuss your project

Have questions or need support? Contact us – our experts are happy to help.

How does ARDURA Consulting, as a strategic partner, support leaders in cultural transformation?

At ARDURA Consulting, we firmly believe that a successful DevOps transformation is first and foremost a transformation of leadership and culture. Technology is important, but it’s the people, their habits and how they interact with each other that ultimately determine success. As your strategic partner, we act not only as technical experts, but more importantly as coaches and facilitators of cultural change.

1 Diagnosis and transformation strategy: Our work often begins with a workshop with your leadership team. Using models such as CALMS or the maturity matrix, we help you diagnose the current state of culture in your organization, identify key barriers and resistances. Then, together we create a pragmatic and realistic cultural transformation roadmap that goes hand-in-hand with a technology implementation roadmap.

2 Coaching and mentoring for leaders: We work directly with leaders at all levels, helping them understand and embrace their new role in DevOps culture. We conduct individual and group coaching sessions, teaching how to build psychological safety, how to effectively communicate a vision and how to model desired behaviors.

3. workshops and training for teams: we help build bridges between silos. We organize and facilitate interdisciplinary workshops, such as “Value Stream Mapping” sessions that help teams understand the entire process and identify waste. We provide training in practices that promote collaboration, such as blameless post-mortems and pair programming.

4 Support in the implementation of structures and processes: We help with the practical implementation of organizational changes. We advise on how to design cross-functional product teams, how to launch a Security Champions program, or how to implement the OKR framework to connect the work of teams to the company’s strategy.

5 Stock the transformation with talent: Often, cultural change requires an “injection” of new blood - people who already have DevOps DNA. In flexible models such as **Staff Augmentation **, we can provide experienced DevOps engineers, SREs or agile coaches who will not only bring the necessary technical skills, but also be natural ambassadors and catalysts for the new culture in your teams.

At ARDURA Consulting, we don’t offer magic solutions. We offer partnership, experience, and pragmatic support in the difficult but extremely rewarding journey of building a high-performing, learning organization.

If you’re a leader who wants to build more than just an automated pipeline - if you want to build a sustainable culture of engineering excellence - consult your project with us. Together, we can unlock the full potential of your people and your organization.

Building a DevOps culture: the role of leadership in the transformation from silos to collaboration