DevOps: A Cultural Change, Not a Technical Revolution

Before DevOps, development teams often operated in isolation from QA and operations. Each group had its own goals:

• Development: Developers prioritised speed. The faster they could deliver code, the sooner they could move on to new features or projects.

• Quality Assurance: QA teams focused on ensuring accuracy and stability, often requiring lengthy periods to test new code thoroughly before releases.

• Operations: Ops teams valued uptime and stability above all else, striving to minimise risk and ensure high performance in production.

These conflicting goals created natural friction. Developers might push frequent updates to maintain velocity, but QA would resist to avoid disruptions during testing. Operations would further slow the process by imposing additional performance checks. The result was a system where each team's success often came at the expense of others, leading to delays, frustration, and suboptimal outcomes.

The underlying issue wasn’t technical; it was cultural. The teams weren’t aligned on a shared purpose. DevOps emerged as a solution to this misalignment by breaking down silos and encouraging a systems-thinking approach.

Breaking Silos: Shifting to Systems Thinking

The DevOps movement recognised that these challenges couldn't be solved through technical solutions alone. The fundamental issue wasn't a lack of automation or tools – it was the siloed mindset that pitted teams against each other. The solution required breaking down these organisational barriers and shifting focus from individual team metrics to system-wide outcomes.

This transformation meant redefining success criteria. Developers needed to expand their definition of "done" beyond feature completion to include quality and operational stability. Operations teams had to embrace change and speed as essential elements of modern systems. QA teams needed to evolve from gatekeepers to enablers of quality throughout the development process.

This might sound trivial but I have worked with developers who flat out said they would quit if we forced them to do testing. Change is never easy!

The Toyota Example: Lessons from Manufacturing

The cultural shift required for DevOps is similar to the changes that Toyota implemented when improving their production system.

In the 1980s, Toyota was producing higher quality and cheaper cars than their American competitors. To continue selling cars in the US, the US government mandated that they would need to assist the US companies. A team from General Motors visited a Toyota assembly line to understand how Toyota was so far ahead of them. They noted the layout of the line and what each person did. At one station they noted that the operator was surrounded by shelves to store parts for the four different car models they produced. As needed, the operator would retrieve the correct parts from the shelves.

When GM attempted to replicate this in their own factories, they failed. They returned to Toyota and noticed something had changed: the operator no longer used shelves. Instead, parts now traveled with the cars on the assembly line.

When GM asked why the process had changed, Toyota explained that they had begun producing more than four models, and the shelves became inefficient. To adapt, an upstream operator started sorting and delivering the correct parts with each car. This change required upstream operators to do more work, but it improved the system’s overall efficiency.

This optimisation would be counterintuitive in a function-focused system where each station prioritised its own efficiency. Toyota, however, was looking at the performance of the system as a whole. With this mindset it is easy to get one function to take on more work if it helps improve the performance of the system.

No QA and NoOps? A Fear of Redundancy

As DevOps gained traction, fears emerged that traditional QA and operations roles might disappear. Would automation eliminate the need for QA testers? Would developers take over the responsibilities of operations teams?

In practice, the opposite happened. DevOps freed these roles to focus on higher-value work:

• QA: With repetitive testing automated, QA professionals transitioned to exploratory testing, uncovering nuanced issues and ensuring a better user experience.

• Operations: Instead of manually configuring servers or troubleshooting deployments, operations teams embraced infrastructure automation and monitoring, focusing on performance optimisation and reliability engineering.

Rather than being replaced, QA and operations evolved, becoming integral to the DevOps ecosystem. By automating routine tasks and fostering collaboration, it creates space for more strategic and impactful work.

Conclusion: Cultural Change Beyond DevOps

The cultural shift introduced by DevOps doesn’t stop at software delivery. As organisations embrace cross-functional teams during research, design, and development phases, similar cultural changes are required. Success depends on breaking down silos, aligning goals, and fostering collaboration across diverse disciplines.

DevOps teaches us that technical tools and processes are only part of the equation. Real transformation happens when people change how they work together, shifting from a collection of isolated functions to a unified system focused on delivering value.