Wind River has unveiled a continuous integration and continuous delivery (CI/CD) model for Wind River Linux customers.

By following a CI/CD process customers will have access to new releases every few weeks. This will allow teams to begin to build their own continuous integration and delivery systems for their customers, get a head start on building new platforms sooner, and enjoy similar benefits of Common Vulnerabilities and Exposures (CVE) management, technical support, and quality typically found in annual and Long Term Support (LTS) releases.

“In the 5G era, as companies are racing to innovate, they have a greater need for frequent software updates and nonstop security monitoring. Many update their software on a weekly basis, and some are updating applications every day or even hourly,” said Michel Genard, vice president of product, Wind River. “Companies want a continuous stream of updated code and features from a trusted source. On a daily basis, Wind River tests and validates a variety of use cases relevant across industries, with thousands of test cases every night. This testing, coupled with constant feedback and active engagement from customers, is designed to ensure high levels of quality for our deliverables.”

Using CI/CD practices to advance its own DevOps culture and deliver high-quality software, Wind River is providing continuous delivery that enables customers to integrate Wind River Linux into their continuous integration processes. The development and maintenance processes for Wind River releases are certified for quality under ISO 9001:2015. Wind River is the first company to ever be OpenChain conformant, which means that certification for open source license compliance and usage allows users to trust the open source from which software solutions are built.

CI/CD best practices contribute to a culture of continuous improvement by enabling teams to adopt, adapt, and implement small changes rapidly and reliably. As connectivity rises across sectors, new data and applications are under constant change, and companies must adjust their processes in order to incorporate, validate, and deliver new features and applications.

According to Wind River, embedded system developers who are interested in CI/CD but do not yet have the infrastructure for that development model will be able to get support from the company. Customers who currently develop software on a fixed version of the Linux kernel due to tight restrictions around certifications, such as those creating medical systems, can continue to work with Wind River Linux LTS yearly releases.

More common in the enterprise realm, container usage is typically a challenge in the embedded space, due to the need for a highly optimised software stack. Existing frameworks often lack the right design or support for mission-critical industries that employ embedded devices with extremely long lifecycles that require lighter-weight software with a smaller footprint. Wind River Linux already includes pre-built containers, tools, and documentation and support for frameworks such as Docker and Kubernetes, which can help developers deploy applications across the intelligent edge using cloud-native methods. Wind River Linux has added the capability to asynchronously update containers and the base operating system (OS) separately. When running multiple applications, with each in its own container, on top of Wind River Linux, these containerised applications can be updated without having to update or reboot the host OS.

Linux tools often require special adaptations for embedded software development. Wind River is now providing new commercial tooling options for Linux application developers to enable their use of the latest open source innovations.

A new version of the Eclipse-based Wind River Workbench for Linux LTS provides an application development environment for build, debug, and system analysis tools.

Wind River also has teamed with partners such as Percepio AB to ensure that there is both an open source and a commercial ecosystem of tools that address the needs of Wind River Linux developers. The Percepio Tracealyzer trace visualization tool provides a large number of high-level views to make it easier to spot anomalies in program execution and to trace them to the root cause without requiring a great deal of Linux kernel expertise.

Wind River is providing a Linux subscription in order to provide long term support and maintenance, including security updates, for the upstream Wind River Linux content.

Wind River’s security team is constantly monitoring the CVE database, security notifications from U.S. government agencies and organisations such as NIST and US CERT, and public and private security mailing lists. By leveraging commercial grade ISO 9001:2015–certified Wind River Linux, support, and services, teams are able to significantly reduce production and maintenance costs and accelerate development cycles in comparison to in-house efforts.

The latest version of Wind River Linux also includes a robust collection of full-featured board support packages (BSPs).

Software Is Now Critical Infrastructure

From the smartphone in your pocket to the power grid serving an entire city, virtually every system people rely on daily runs on layers of complex software. That dependency is not shrinking—it is accelerating. As the volume of data generated globally continues to expand at an extraordinary rate, the pressure on software teams to ship reliable code quickly has never been higher.

This is precisely the environment that made DevOps indispensable. DevOps—the cultural and technical movement that breaks down silos between development and operations teams—was originally adopted as a competitive differentiator. It is now a survival requirement for any organization that builds or depends on software.

What Happens When Software Updates Go Wrong

The consequences of poor software delivery practices are not abstract. Several high-profile incidents illustrate how much is at stake:

• Power grid outages: A faulty software update contributed to widespread power outages affecting the San Francisco Bay Area when utility provider Pacific Gas and Electric (PG&E) pushed a problematic release.
• Aviation safety failures: The Boeing 737 Max crashes, linked in part to a software defect in flight-control sensor logic, resulted in the loss of more than 150 lives—demonstrating that software quality failures can have fatal consequences.
• Consumer device failures: A software patch released by Google rendered Google Home and Nest Hub devices inoperable for users across the world.

These examples share a common thread: insufficient testing, release management, or rollback capability at the point of deployment. A mature DevOps practice—with automated testing pipelines, staged rollouts, and rapid rollback mechanisms—directly addresses each of these failure points.

The Business Case for DevOps Culture

DevOps is not only about preventing disasters. Organizations that invest in a genuine DevOps culture gain concrete competitive advantages:

• Faster time to market: Shorter release cycles allow teams to test ideas with real users and iterate based on feedback, rather than betting on long development cycles.
• Greater reliability: Continuous integration and continuous delivery (CI/CD) pipelines catch defects earlier, reducing the cost and impact of bugs.
• Scalability: Containerized, cloud-native architectures—exemplified by platforms like Kubernetes—let organizations scale individual services independently rather than over-provisioning monolithic systems.
• Developer productivity: Removing friction from the build, test, and release process allows engineers to focus on building features rather than managing manual handoffs.

Large-scale acquisitions have reflected the market’s confidence in DevOps tooling and culture. IBM’s acquisition of Red Hat and Microsoft’s acquisition of GitHub are frequently cited examples of enterprise-level investment in the open-source and developer tooling ecosystems that underpin DevOps workflows.

Continuous Delivery and the Move Toward Liquid Software

The concept of Liquid Software—a term associated with JFrog and others in the binary management space—describes a future state where software updates flow continuously and invisibly to end users, much like a utility. Rather than scheduled releases, software is updated in real time with no user-visible downtime or manual intervention.

This vision extends CI/CD pipelines to their logical conclusion: fully automated, policy-driven delivery of verified binaries directly to production and to edge devices. Achieving this requires not just tooling, but a cultural shift in how development, security, and operations teams collaborate.

DevOps at Scale: Containers and Multi-Cloud

Containers have become the default packaging format for modern applications. Google has cited running over two billion containers per week across its infrastructure, spanning services from Gmail to YouTube to Search. While that scale is unusual, the underlying pattern—containerized microservices deployed and orchestrated automatically—is now common across organizations of all sizes.

Alongside containerization, multi-cloud strategy has become a practical reality. Organizations routinely run workloads across a mix of on-premises infrastructure and multiple public cloud providers. Platforms such as Google Anthos, and similar offerings from other vendors, reflect the market demand for portability and flexibility—avoiding lock-in while preserving the ability to optimize cost and performance across environments.

Effective DevOps in a multi-cloud environment requires:

• Infrastructure-as-code practices that are cloud-agnostic or portable
• Centralized artifact management so binaries are built once and promoted across environments
• Unified observability across all deployment targets
• Security policies enforced at the pipeline level, not applied manually per environment

Building a Developer-First Culture

Technology choices alone do not create a DevOps organization. The cultural dimension—how teams communicate, how work is structured, and who owns quality—is equally critical.

A Developer First mindset means that the tools, workflows, and organizational policies are designed around reducing friction for engineers, rather than imposing process overhead that slows delivery. This includes:

• Self-service infrastructure provisioning so developers are not blocked waiting for operations teams
• Automated security scanning integrated into CI pipelines (DevSecOps), rather than a separate sign-off gate
• Postmortems and blameless retrospectives that treat failures as system problems, not individual errors
• Communities of practice that allow engineers to share knowledge across teams and learn from peers

Educational institutions have also contributed to this shift. Computer science programs that incorporate full-stack development and DevOps practices graduate engineers who arrive in the workforce already fluent in CI/CD, version control, and cloud-native architectures. This has raised the baseline expectation for how software teams operate.

DevOps Is Expanding Beyond Technology Sectors

While DevOps originated in software product companies, the practices are increasingly relevant to any organization that depends on software to deliver services—which, at this point, means virtually every industry.

Healthcare organizations use software to manage patient records, diagnostic equipment, and clinical workflows. Financial institutions run trading platforms, fraud detection systems, and customer-facing applications. Government agencies deliver public services digitally. In each case, the reliability, speed, and security of software delivery directly affects outcomes for real people.

Organizations in these sectors that adopt cloud-native architectures and DevOps practices gain the same benefits as technology companies: faster iteration, greater resilience, and the ability to respond to changing requirements without long release cycles.

The Talent Dimension

Demand for DevOps engineering skills remains strong. The role spans a broad set of competencies: CI/CD pipeline design, infrastructure automation, container orchestration, cloud architecture, observability, and security. Engineers who combine these skills with an understanding of software delivery culture are positioned well for senior engineering and leadership roles.

For organizations, the implication is that hiring and retaining DevOps-capable engineers requires more than a competitive salary. It requires an environment where those engineers can practice what they know—with modern tooling, meaningful ownership, and a culture that values quality and speed equally.

Key Takeaways

• Software failures in critical infrastructure—power, aviation, consumer devices—demonstrate the real cost of poor release practices.
• DevOps culture accelerates delivery while improving reliability when implemented genuinely, not just as a rebranding of existing processes.
• Containerization and multi-cloud strategies are now standard architecture patterns, not emerging trends.
• The Liquid Software vision—continuous, invisible updates—is the logical destination of a mature CI/CD practice.
• DevOps is expanding into healthcare, finance, government, and other sectors as software becomes central to every industry’s operations.
• Cultural change—developer-first mindset, blameless postmortems, shared ownership of quality—is as important as tooling.

Organizations that treat DevOps as a checkbox exercise rarely see the expected results. Those that invest in the cultural foundation—not just the pipeline tooling—are the ones that consistently ship better software, faster, and with greater confidence in its reliability.

What Makes Software High Quality?

Software quality is often described across three dimensions, sometimes called the software quality triangle:

• Operation: How well the software functions day-to-day. This covers correctness (does it do what it claims?), usability, integrity, and reliability.
• Transition: How easily the software moves between platforms, environments, or systems. Key attributes include portability and interoperability — the ability of the software to work alongside other programs and APIs.
• Revision: How maintainable, testable, and modular the codebase is. This dimension becomes especially critical when scaling, because poor revision characteristics slow every team that touches the code.

With those dimensions in mind, here are seven actionable tips for preserving software quality as your DevOps practice grows.

1. Keep Things Simple

Complexity is the enemy of quality at scale. Simple code is easier to review, easier to test, and easier to hand off to new team members. Strive for clean interfaces, clear naming conventions, and short, single-purpose functions.

Automation is a powerful lever here. Static analysis tools and linters can automatically flag unnecessary duplication, overly long methods, and high cyclomatic complexity before code ever reaches a reviewer. Integrating these checks into your CI pipeline means quality gates run on every commit, not just at release time.

When evaluating new tooling, also ask whether it reduces cognitive load for developers or adds to it. The best DevOps toolchain is the one your team will actually use consistently.

2. Make Data-Driven Decisions

Gut feeling has a poor track record when it comes to prioritizing quality improvements. Instrument your software to collect meaningful metrics: error rates, latency percentiles, deployment frequency, mean time to recovery (MTTR), and user behavior signals such as feature adoption or drop-off points.

For example, usage analytics can reveal which features drive the most user engagement, so your team can invest disproportionately in stabilizing and improving those paths. Conversely, low-traffic areas may be candidates for deprecation rather than maintenance overhead.

Observability tooling — distributed tracing, structured logging, and real-time dashboards — makes this data actionable in production, not just in retrospectives.

3. Build for Users, Not Just for Checklists

DevOps frameworks and compliance checklists exist for good reason, but they are a floor, not a ceiling. It is easy for teams under delivery pressure to tick boxes while shipping software that nobody actually wants to use.

User-centric development means involving real users early — through usability testing, beta programs, and feedback loops — and treating their experience as a first-class quality metric. A feature is not done when it passes automated tests; it is done when it demonstrably helps users accomplish their goals.

Embedding product thinking into DevOps teams (sometimes called DevOps + Product) helps ensure that velocity is directed toward outcomes, not just outputs.

4. Meet Established Code Quality Standards

Industry standards provide a useful external reference point for code quality, especially when scaling into new markets or regulated industries. The Consortium for IT Software Quality (CISQ) publishes automated quality characteristic measures based on the ISO 25010 standard, covering reliability, security, performance efficiency, and maintainability.

Practically, this means paying attention to patterns that degrade quality at the code level: unsafe buffer handling, unbounded loop computations, poor exception management, and tightly coupled architecture. Code review checklists, architecture decision records (ADRs), and regular dependency audits all help teams stay aligned with these standards without relying on manual heroics.

5. Practice Continuous Testing

Testing should not be a phase that happens before release — it should be a continuous activity woven into every stage of the delivery pipeline. This means:

• Unit and integration tests run on every commit.
• Performance tests run against staging environments to catch regressions before they reach production.
• Security scanning (SAST, DAST, dependency vulnerability checks) is automated in the pipeline.
• Penetration testing is scheduled regularly, not just annually, especially after significant architectural changes.
• API contract tests prevent breaking changes from propagating across services in a microservices architecture.

The goal is a fast feedback loop: developers should know within minutes, not days, whether a change has broken something. Slow feedback is one of the most common reasons quality degrades at scale.

6. Follow Up on Assessments and Audits

Assessments — whether they are security audits, architecture reviews, or retrospectives — produce recommendations. Those recommendations have zero value unless someone owns them and drives them to completion.

Build follow-up into your process explicitly. Track audit findings as backlog items with owners and due dates. Use blameless post-mortems to generate improvement actions, and review whether those actions actually moved the needle in the next retrospective. Some useful self-assessment questions to ask regularly:

• Is our automation reducing toil, or has it introduced its own complexity?
• Did the changes we made after the last review produce the outcomes we expected?
• Are there manual steps in our pipeline that are still candidates for automation?
• Are our quality metrics trending in the right direction over the past quarter?

7. Prioritize Reliability and Efficiency

Scaling something unreliable just delivers failures faster. Reliability engineering — defining SLOs (Service Level Objectives), tracking error budgets, and designing for graceful degradation — must be a first-class concern before you scale, not after.

Efficiency matters too, both in the software itself (response time, resource consumption) and in the delivery process (lead time, deployment frequency). Inefficient infrastructure or bloated pipelines add cost without adding value. Regularly profile both your runtime performance and your CI/CD pipeline performance to find and eliminate waste.

Together, reliability and efficiency define whether scaling DevOps creates real business value or simply increases the blast radius of existing problems.

Bringing It Together

Every tip above serves a single underlying principle: software quality is not a property you bolt on at the end of a sprint — it is a discipline you maintain continuously as your team, codebase, and infrastructure grow. The teams that scale DevOps successfully are those that treat quality as a shared responsibility, automate quality gates early, and measure outcomes rather than just activity.

Start with the areas where your current process is weakest — whether that is test coverage, observability, or follow-through on audit findings — and build from there. Incremental, measurable improvement is far more sustainable than a big-bang quality initiative.

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.

Background: Listening at DOES19

The DevOps Enterprise Summit (DOES) is one of the most respected annual gatherings for technology leaders navigating large-scale DevOps transformations. At the 2019 London event, Mark Smalley spent three days at the GamingWorks booth speaking with delegates about a single question: What is your biggest DevOps transformation challenge right now?

The answers clustered into seven recurring themes. What follows is a summary of those themes, enriched with practitioner commentary. If you recognize your own organization’s struggles here, you are far from alone.

1. Business Value

• Understanding the link between day-to-day IT work and overarching business strategy.
• Gaining end-to-end visibility and transparency across the delivery chain.
• Measuring the right things — team performance expressed in terms of business outcomes, not just technical metrics.

Commentary: Many IT professionals struggle not only to understand the business value of their work but also to articulate it clearly to non-technical executives. Bridging this communication gap requires a shared vocabulary and agreed-upon outcome metrics that resonate beyond the engineering team. Frameworks and whitepapers on the business value of DevOps — such as those produced by the DevOps Agile Skills Association (DASA) — offer useful starting points for structuring that conversation.

2. Governance

• Finding the right balance between centralized standardization and team-level autonomy.

Commentary: Governance is frequently cited but rarely well-defined. The core tension is this: standardization can drive efficiency and compliance, but applied too broadly it creates bureaucracy that slows down the very teams it is meant to support. In complex, unpredictable systems, professionals need latitude to exercise judgment. The guiding question should always be: Does this standard actually improve outcomes for the value stream, or does it simply satisfy an organizational need for uniformity? If the answer is the latter, decentralized decision-making often produces better results — even if it costs slightly more to operate.

3. Velocity

• Delivering quickly without sacrificing quality.

Commentary: Speed versus quality is a false binary. The real challenge is sustaining all five dimensions simultaneously: better, value, sooner, safer, and happier — a framing popularized by Jonathan Smart and Sonja Blignaut at Deloitte under the hashtag #BVSSH. Resilient operations, co-created customer value, and regulatory conformance must all remain in the picture as delivery cadences increase. Automating quality gates within CI/CD pipelines is one of the most effective levers teams have for maintaining this balance.

4. Value Streams

• Breaking down organizational silos.
• Improving collaboration across team and departmental boundaries.
• Granting teams greater autonomy over their work.
• Integrating DevOps practices into predominantly non-DevOps parts of the value stream, and vice versa.

Commentary: At conferences, value stream thinking is widely understood. In most IT departments, it remains an alien concept. There is a real risk that practitioners develop an echo-chamber view of how far adoption has spread. The practical implication: when beginning a transformation, meet teams where they are rather than where you wish they were. Cross-team collaboration consistently ranks as one of the hardest soft skills to develop — something confirmed by DevOps Institute (DOI) skills surveys that identify it as a top-priority competency. It may be called “soft,” but it is anything but easy.

5. Operations (Ops)

• Defining what modern ops looks like in a DevOps context.
• Transitioning from traditional, process-heavy ops models to leaner, more adaptive ones.

Commentary: The evolution of ops is one of the most active areas of change in the industry. Frameworks such as ITIL 4 have moved toward a less prescriptive, more value-oriented model — emphasizing value streams, co-creation with service consumers, and human judgment over rigid process compliance. However, ops work is fundamentally different from development work: it is often more interrupt-driven, involves higher stakes around availability, and requires different patterns of working. A healthy DevOps culture must accommodate and respect those differences rather than simply importing dev-centric practices wholesale into ops teams.

6. Organizational Change

• Sustaining momentum after the initial enthusiasm fades.
• Overcoming resistance and organizational inertia.
• Accepting the full consequences of committing to DevOps.
• Unlearning decades of entrenched working habits.
• Building the skills needed to lead and execute transformation.
• Assessing and managing the risks of transformation itself.
• Sharing practices across teams and learning from peers.
• Scaling what works beyond pilot teams.

Commentary: Organizational change is where most DevOps transformations succeed or fail. Too often there is enthusiastic talk at the executive level followed by underwhelming commitment in practice. There is no shortcut. As Taiichi Ohno, the architect of the Toyota Production System, observed: “You have to think for yourself and face your own difficulties instead of trying to borrow wisdom.” Borrowed frameworks and copied playbooks can only take you so far. Genuine transformation requires deep, context-specific problem-solving. Notably, similar patterns were observed at the DOES18 USA event, suggesting these are systemic, industry-wide challenges rather than isolated organizational issues.

7. Culture and Emotions

• Building diverse, cross-functional teams.
• Getting people with very different personalities and working styles to collaborate effectively.
• Building mutual trust across team and organizational boundaries.
• Addressing the perception that non-DevOps teams are less valued.

Commentary: Culture is finally getting the serious attention it deserves in enterprise DevOps conversations. Psychological safety — the degree to which team members feel comfortable speaking up, raising concerns, and being themselves — is a foundational enabler of high performance. Research by Amy Edmondson at Harvard Business School has made this concept mainstream, and it regularly surfaces in Phoenix Project simulation workshops as a critical factor in team effectiveness. Burnout researcher Dr. Christina Maslach offers a sharp analogy that captures the stakes: “You want less toxic mines, not more resilient canaries.” Resilience is a virtue, but it should never substitute for fixing the systemic conditions that cause harm in the first place.

8. Tooling

• Navigating tool sprawl and confusion in the DevOps ecosystem.
• Integrating disparate tools into a coherent, orchestrated toolchain.

Commentary: The DevOps tooling landscape is vast and grows more complex each year. Teams frequently struggle with two distinct problems: first, selecting the right tools from a crowded market; second, making those tools work together reliably in a coherent pipeline. Tool selection should follow strategy, not precede it. Defining what outcomes you need to achieve — faster deployments, better observability, automated security scanning — and then choosing tools to serve those outcomes is far more effective than adopting tools because they are popular or because a vendor presented them well.

Key Takeaways

The challenges reported at DOES19 London are not new, and they are not unique to any single organization or industry. The fact that the same themes — business value alignment, governance balance, collaboration, culture, and sustainable change — recur at every major DevOps event points to something important: these are deep, structural challenges that no tool, framework, or conference talk will solve on its own.

Progress requires honest self-assessment, genuine executive commitment, and the patience to build capability incrementally. Start from where your organization actually is. Measure outcomes that matter to the business. Invest as heavily in people and culture as in tooling and process. And share what you learn — the DevOps community grows stronger when practitioners are candid about what is hard, not just what worked.

Original reporting and commentary by Mark Smalley, published on devops.com. Mark Smalley is a DevOps practitioner, DASA contributor, and speaker known as “The IT Paradigmologist.”

Intro

Continuous integration/continuous delivery (CI/CD) is the next logical step in the evolution of software development, packaging, and deployment. It utilizes automation to deploy software changes faster, safer, and more frequently than ever before. Next generation toolkits are now available to implement CI/CD methodology.

What’s the earliest build tool you remember using? Tools such as GNU Make, Scons,  and Autoconf date back to the 1990s and beyond. They give many seasoned developers unpleasant memories of hours of fruitless struggle and broken configurations. As infrastructure became more complex and dynamic, build tools needed to become more automated and sophisticated. This led to increasing automation, along with rapid development tools and methodologies.

Today’s toolkits handle everything from configuration to testing to packaging to deployment. In fact, modern build systems have enabled a new paradigm of software and configuration management: continuous integration and continuous delivery (CI/CD). In the eBook Modern App Builds for Modern App Builders, we explain where our complicated toolkits originated and how an organization can rethink their tools for CI/CD.

What is CI/CD?

The expectation for software has outgrown the old deployment models. Modern architecture is far more diverse and complex, and customers expect more frequent deployments. Instead of just deploying to a handful of servers, deployment targets clusters of VMs, clouds, and on-prem data centers. These changes in scope mean that reliability, flexibility, and scalability are more necessary than ever.

An infrastructure using CI/CD leverages the latest technology to keep deployed applications up to date. CI/CD integrates well with modern project management practices such as Scrum and Agile. These new tools and techniques have increased not only the speed of deployment but also the quality and adaptability of modern software.

Projects that benefit from CI/CD employ a wide variety of technology and deployment targets, including Docker containers, OS packages and bundled programming libraries. Modern automated application build tools manage all of these deliverables.

Continuous Integration

The first part of the CI/CD formula is continuous integration. This means that code and configuration changes from developers are frequently committed to the master branch of a project – sometimes multiple times per day. Every time a commit to the master branch occurs, a new build and test cycle is triggered to determine if the new code is ready to be packaged and released. With continuous integration, code freeze is a thing of the past.

Continuous integration used to be just a novel technique to avoid development headaches, a way to make sure that bad code wasn’t introduced to the master branch. Today, it has become an essential tool in the modern software development lifecycle. CI quickly determines if new show-stopping bugs have been introduced, or if code changes have caused regression failures and packaging issues. This prevents many bugs from being released in deployed code and, when done correctly, makes project development move swiftly and smoothly. Extreme programming (XP), an agile methodology introduced in the 1990s, was one of the first to embrace CI.

CI isn’t just a technique, however. It relies on sophisticated modern toolchains that help automate everything from source code change management to quality assurance to software builds. Integrating all of these moving parts to enable automation is a daunting task, but it’s necessary to achieve continuous integration.

Continuous Delivery

The other half of the CI/CD methodology is continuous delivery. This is the practice of automatically deploying successful builds to production environments. Once changes have passed the automated steps in the continuous integration phase, they are considered ready for deployment. As you can imagine, more automation is needed for this step.

The CI process is a critical prerequisite for CD. The automated testing and building that are core to CI inform the CD toolchain if new versions are ready for production deployment. Automation during the deployment phase can include everything from distributing packages to provisioning VMs, containers, and additional cloud resources. Thanks to modern DevOps automation techniques, CD can also include configuration changes down to the OS and networking levels of an application’s infrastructure.

In the past, products that were updated too often were viewed with suspicion, because they were frequently riddled with new bugs, faulty installations, and poor quality control. However, innovations in automated integration, testing, and packaging have changed our expectations for software. Frequently, continuous deployment happens so smoothly that end users are completely unaware. For example, today’s web applications and mobile apps update constantly, and these upgrades are now expected, rather than viewed with trepidation by users. Continuous deployment is vital to the success of a modern application.

Finding Your Path to CI/CD

Even with the best team of developers you can find, your application will never find a foothold in the market without the right build and deployment tools. You can’t skip steps in the journey to automated CI/CD. Start smart, with test-driven development, version control, and automated build and dependency systems. To drive innovation and build quality software for today’s world, you’ll need a good automation toolchain and a strong DevOps culture.

A modern CI/CD methodology will help your team shed the burdens of manual release processes and the headaches of dealing with complex IT environments. If you’re planning to implement CI/CD for your team, our eBook is a great place to start. Each manual process removed from the equation will improve not only the lives of your development team, but the final quality of your deployed software product.

When Bad Code Has Real-World Consequences

In March 2018, one of Uber’s autonomous test vehicles struck and killed a pedestrian in Tempe, Arizona. The incident became one of the most scrutinized software-related accidents in recent memory. Investigations revealed a troubling combination of factors: the safety driver behind the wheel was reportedly watching a streaming video on a personal device instead of monitoring the road, and the vehicle’s self-driving sensor system failed to correctly classify and react to the pedestrian in time to apply the brakes.

The National Transportation Safety Board (NTSB) investigated the crash extensively. While the full chain of causation involved human distraction, vehicle design decisions, and operational policies, software behavior was a central element of the NTSB’s findings. For the DevOps and software engineering community, the incident served as a stark reminder: the code teams write can have consequences far beyond a degraded user experience or a missed sprint deadline.

Ethical Pressure Inside the Organization

The Tempe accident did not arise in a vacuum. Prior to it, Uber had already attracted significant negative attention for a range of alleged internal practices. Former software engineer Susan Fowler published a widely read account in early 2017 describing a culture of sexual harassment and management misconduct. Separately, Uber faced accusations that its engineering teams had built tools designed to exploit driver earnings, evade regulatory oversight, and deny service to passengers in ways that skirted legal boundaries.

These allegations, if accurate, represent a scenario in which software developers were asked—explicitly or implicitly—to write code in service of goals that were ethically or legally questionable. This raises an important question for every engineering organization: what happens when the people with the ability to build something are also the first line of defense against building something harmful?

What Developers Say They Would Do

Stack Overflow’s annual developer survey, which at the time of the original reporting included responses from more than 100,000 developers worldwide, offered some data on how engineers think about ethical responsibility. When asked what they would do if asked to write code for an unethical purpose:

• 58.5% said they would refuse to write it.
• 36.6% said their response would depend on the specific situation.
• 4.8% said they would write it.

On the surface, these numbers are encouraging. A strong majority of developers report a willingness to refuse unethical work. However, Stack Overflow noted a significant grey area in the findings: developers were largely uncertain about how they would report an ethical concern, and they held widely differing views about who bears ultimate responsibility when unethical code is shipped. That ambiguity is the real problem.

The Grey Area: Responsibility and Reporting

Knowing that you should refuse to write harmful code is not the same as knowing what to do next. In practice, engineers face a layered set of pressures: sprint deadlines, management directives, fear of retaliation, uncertainty about whether their concern is legitimate, and a general sense that someone higher up the chain must have already considered the implications.

This diffusion of responsibility is well-documented in organizational psychology. In software teams, it can manifest as a situation where no individual developer believes they are personally responsible for the ethical dimensions of a system, even as the system as a whole causes harm.

What DevOps Teams Can Do

Torsten Volk, an analyst at Enterprise Management Associates (EMA), argued that DevOps is uniquely positioned—and uniquely obligated—to build ethical guardrails into development culture. He identified several concrete mechanisms:

1. Full Audit Trails

Maintaining clear, immutable records of who wrote what code and when creates accountability at the individual contributor level. Volk noted that knowing an audit trail exists makes developers more likely to raise concerns with team leads before problematic code ships. Source code management systems like Git already provide the technical foundation for this; the cultural commitment to treating those records as an ethical tool is what organizations often lack.

2. Documented Ethics Discussions

When a developer flags an ethical concern, the outcome of that conversation should be documented—ideally in the same source code management or issue-tracking system the team already uses. This transforms a potentially invisible conversation into a traceable decision, and it protects the developer who raised the concern.

3. Psychological Safety for Raising Concerns

No audit trail matters if developers fear retaliation for speaking up. Organizations must actively cultivate an environment where raising an ethical red flag is treated as a professional responsibility rather than insubordination. This means leadership modeling the behavior, not just writing it into a policy document.

4. Connecting Ethics to Business Risk

Volk also argued that organizations should frame ethical coding practices in terms that resonate at the executive level: risk management and bottom-line impact. Unethical code is not just a moral failure; it is a liability. Regulatory penalties, reputational damage, and the cost of incident response all have quantifiable business consequences. Drawing a direct line between ethical engineering practices and reduced organizational risk is one of the most effective ways to secure sustained leadership buy-in.

Volk drew a parallel to GDPR compliance, suggesting that organizations could similarly recognize and publicize outstanding examples of ethical conduct in development—signaling to customers and partners that responsible engineering is a competitive differentiator, not just a cost center.

Building an Ethical Engineering Culture

The Uber case should not be read as an indictment of autonomous vehicle technology or of DevOps culture writ large. The majority of software developers, as the Stack Overflow data suggests, want to do the right thing. The challenge is structural: organizations must make it easy—and safe—for developers to act on their ethical instincts.

Practical steps for engineering leaders include:

• Adding an ethics review checkpoint to your Definition of Done or pull request template.
• Including ethical risk assessment in architecture decision records (ADRs).
• Running scenario-based ethics training as part of onboarding and continuing education.
• Establishing a clear, non-punitive escalation path for engineers who have concerns about a feature or system they are being asked to build.
• Ensuring retrospectives can surface ethical concerns, not just process inefficiencies.

Software is not neutral. The decisions made during a sprint—what a sensor system is optimized for, how an algorithm weights certain outcomes, which edge cases are treated as acceptable losses—can ripple outward in ways that affect real people. DevOps culture, with its emphasis on shared responsibility, continuous feedback, and transparency, is well suited to make ethical accountability a first-class engineering concern rather than an afterthought.

Having a strong DevOps culture is like having good taste. Everyone wants it – but is everyone equipped with the skills, instincts, and sheer luck needed to actually have it?

The reality is, building a great DevOps culture is easier said than done. Here are the major challenges facing strong DevOps cultures and how to overcome them.

1. Inability to give and listen to feedback

Teams must learn how to give and receive feedback if they are to improve and take each other forward in the process. Engineers and operators are smart cookies with high IQs, but many need to improve their EQs to collaborate more effectively as a team. Teams with high EQ will always destroy those with low EQ because they can learn and achieve more. 

Feedback is about sharing what is working and what can be improved every single day. It’s important that teams don’t just focus on the good or the bad, but rather keep a sharp focus on feedback and bias.

2. The revolving door problem


Part of the challenge facing DevOps culture is the short tenure of DevOps professionals themselves. The average tenure of a DevOps engineer is less than three years. Engineers often find themselves lured away for the promise of better compensation, better equity, or the “next hot startup company.”

This doesn’t do any favors to the ongoing battle to achieve true alignment between Dev and Ops teams: How they can play together when team members are constantly jumping ship, leaving behind unfinished projects, and forcing new people to join and ramp up quickly? If there were more stability in engineering teams, it might be easier to build the foundations of a stable and durable DevOps culture.

3. Well-meaning but time-wasting acts of heroism

Often you’ll be at a developer conference and an enthusiastic, well-meaning presenter is gushing about the unbelievably complex, bespoke platform that her team has built – one that has nothing to do with their core competency. She demonstrates how they spent six months and $300,000 to create it and the whole room bursts into applause.

The “build it not buy It” mentality is one that truly holds back top-performing engineering teams. In 2018, the platform you need has likely been built – and built extremely well – by a third party. Save your engineering heroics for what your customer actually requires; the rest is a needless waste of time and resources. Be an expert in your business, not the tools business.

4. The term “DevOps” is a problem

If you ask many high-performing engineering teams about DevOps, the response you’ll often get is an eye roll – even if those teams are uncommonly good at DevOps. The word has been beaten down, over-publicized, and over-discussed. (I know, this article doesn’t help that situation.)

If DevOps refers to the cultural alignment of development and operations so that both teams are responsible for the success of production environments, then the term has enormous value. But if the word has been drained of all meaning by a tsunami of think pieces and keynote presentations, then it’s difficult to have a meaningful discussion about it.

Try to remember that the concept has value, even if it’s been beaten down by so many analyses, conversations, and misunderstandings.

5. The right culture isn’t modeled from above

You all know the truth of this statement: There’s no culture unless it’s shown by example, set by the teams above. It takes a superhuman effort for a team to enact its own unique culture within an organization that doesn’t itself value culture or take it seriously.

If you have an organization where the executive and management team isn’t truly facilitating team alignment, including between the developer and operations teams, how can a DevOps team survive and thrive? Culture comes from the top.

6. DevOps goals aren’t aligned to business goals

99.9 percent of companies using DevOps are wielding it as a catalyst to drive business outcomes faster, and a strong DevOps culture is one that truly understands the levers of its business. DevOps is not about having a team of “rock stars” that improves technical KPIs; in fact, measuring availability is pointless unless you can measure and report the real business impact.

 Technical metrics are great, but goals drive behavior – and goals that focus on the needs of the business constitute the foundation of a solid DevOps culture.

How to beat the DevOps barriers

I’ve spent a lot of time describing the barriers that keep DevOps teams from reaching their full potential. But the reality is, there are plenty of positive forces helping DevOps teams build strong cultures. For one, the will to do so is stronger than ever: Companies want strong DevOps organizations to help them achieve business goals. For another, technology is better than ever and can help teams focus on the same shared metrics and set of goals.

Wherever you find the twin enablers of genuine will and solid technology, a strong DevOps culture can’t be too far behind. In addition to will and technology, companies seeking to build that culture must:

• Focus as much on EQ as IQ, making sure engineers and operators really listen to each other while building a DevOps culture from the ground up. This will also help maintain collaboration and stability on Dev and Ops teams, making constant turnover less of a cultural and business problem. (See our related story: 10 things leaders with emotional intelligence never do.)
• Stay in the business you’re in: Allow engineers to focus on what your company was created for, rather than distracting them.
• Have open discussions on what DevOps really means, and what it means to your teams, independent of the hype that the word has taken on in recent years.
• Ensure leadership is taking DevOps seriously by showing, not telling, how to build a collaborative culture – and by linking DevOps goals directly to business goals.

A security champion is a developer, tester, or engineer embedded within a product team who takes on a formal secondary responsibility for security awareness, guidance, and advocacy. They are not a replacement for dedicated security engineers or penetration testers, but they act as a distributed security presence across every team in the organisation.

Why DevOps Teams Need Security Champions

In traditional software delivery models, security was a gate at the end of the development lifecycle. A separate security team would review the finished application, find issues, and send it back for remediation. This model is incompatible with the short sprint cycles and continuous deployment pipelines that define modern DevOps practice.

Security champions solve this mismatch by pushing security knowledge and decision-making into the teams that write and ship code. Rather than relying on a central security team to catch every issue after the fact, champions ensure that security considerations are part of daily development conversations — during design, during code review, and during testing.

This approach also relieves pressure on team leads. Instead of a single person needing to track security posture across an entire project, champions distribute that responsibility across the team structure, each acting as an informed first line of defence.

Step 1: Define Your Teams and Map Responsibilities

Before assigning anyone to a champion role, you need a clear picture of how your development organisation is structured. This means identifying:

• How many discrete product or feature teams exist
• How many engineers are in each team
• Which programming languages, frameworks, and platforms each team works with
• The current maturity level of security practices within each team
• Who the technical leads, product owners, and decision-makers are

Document this mapping. The goal is to distribute security responsibility proportionally across teams, and you cannot do that without first knowing how those teams are organised. Speak with technical managers and product owners early in the process to get accurate answers. Teams using different languages or deployment targets will face different threat landscapes and will need champions with relevant knowledge.

Step 2: Define the Security Champion Role Clearly

Ambiguity kills champion programmes. If the people taking on this role are not certain what they are responsible for, they will default to their primary engineering work and the champion function will quietly fade. Every security champion should have a written set of objectives covering:

• Security review cadence: Champions should conduct regular security reviews aligned with sprint milestones or release gates, not just at project completion.
• Threat modelling participation: Every significant new feature should be evaluated from a threat perspective. Champions facilitate this conversation within the team.
• Snag list ownership: Security issues discovered during development, code review, or automated scanning should be logged and tracked. Champions are responsible for ensuring these items are not dropped.
• Framework alignment: The security framework or standard the organisation follows — whether that is OWASP, NIST, an internal standard, or something else — should have been selected before development begins. Champions ensure their team’s work stays consistent with that framework.
• Automated scanning integration: Champions should advocate for and help integrate static analysis (SAST), dependency scanning, and where appropriate, dynamic testing (DAST) into the team’s CI/CD pipeline. Teams should not wait for an external penetration tester to find what automated tooling can surface continuously.

It is important to emphasise that security is everyone’s responsibility, not solely the champion’s. The champion role is about leadership and coordination, not about being the single person who catches all security issues. Developers on the team are expected to raise potential vulnerabilities when they encounter them, and to apply secure coding practices as a matter of course.

Step 3: Choose the Right People

Selecting the right individuals is one of the most consequential decisions in building a champion programme. The selection is typically driven by project managers and product owners, though input from the team itself often results in better acceptance and a smoother working relationship.

Good candidates for the security champion role typically share a few characteristics:

• Genuine curiosity about how software can be attacked or misused
• Strong communication skills — they will be the bridge between their team and the central security function
• Enough technical credibility within the team that their guidance will be taken seriously
• A collaborative rather than adversarial working style

Be realistic about motivation. Most engineers already have demanding workloads, and asking someone to take on additional security responsibilities without acknowledgement or incentive is unlikely to produce a committed champion. Make the value proposition clear. Security champion experience is a genuinely marketable credential. It provides direct exposure to product owners and senior leadership, opens doors to security engineering career paths, and typically includes access to training and conferences that would otherwise be outside a developer’s normal scope. Frame the role as a career opportunity, not an administrative burden.

Once champions are in place, define a minimum amount of time per sprint or per week that should be allocated to security-related work. Without this, other priorities will always crowd it out.

Step 4: Keep Security Information Flowing

A security champion programme only works if information moves freely — between champions and their teams, between champions and the central security function, and between champion peers across different teams.

Practically, this means establishing:

• A dedicated communication channel for champions. This could be a Slack channel, a Teams channel, a mailing list, or a recurring call — whatever fits your organisation’s working style. The point is that champions should be able to share what they are seeing and ask questions without routing everything through formal processes.
• A shared knowledge base where security guidelines, past findings, remediation patterns, and framework documentation are stored and accessible to all teams. Centralising this information reduces duplicated effort and prevents teams from solving the same security problems in isolation.
• Regular champion syncs with the central security team or a security lead. These meetings keep champions current on emerging threats, changes to tooling, and organisational security priorities.

The communication tooling itself matters less than the discipline to use it consistently. Champions who are well-connected and well-informed are far more effective than those who receive sporadic guidance and are expected to operate independently.

What a Mature Security Champion Programme Looks Like

When the security champion model is working well, a few things become observable across the organisation:

• Security issues are raised and discussed during sprint planning and design reviews, not discovered weeks later during a penetration test.
• Automated security tooling is embedded in CI/CD pipelines and treated as a first-class part of the build process.
• Threat modelling happens early, and findings are documented and tracked.
• Team leads spend less time on security audit and remediation because issues are being caught and addressed within teams in real time.
• Champions begin proposing their own security initiatives — new tooling, process improvements, training sessions — rather than waiting to be directed.

This last point matters. A programme that reaches this stage has genuinely changed the security culture of the organisation. Champions become advocates and initiators, not just compliance enforcers. That shift — from reactive to proactive security culture — is the real end goal of the security champion model in a DevOps environment.

Summary

Security champions are a practical mechanism for scaling security expertise across engineering teams without requiring every team to have a dedicated security engineer. By mapping your team structure first, defining the role with clear objectives, selecting motivated individuals, and maintaining strong information flow, you can build a programme that makes security a genuine part of your DevOps culture rather than an afterthought bolted on at the end of the pipeline.

It is widely accepted in software engineering that the more changes you make to a codebase, the greater the chance something breaks. But code bugs are not the only thing that can derail a delivery pipeline. Organizations pursuing DevOps transformations frequently encounter a parallel class of problem: cultural bugs. Misplaced expectations, eroding team cohesion, and unhealthy perfectionism are just as capable of stalling a DevOps initiative as any deployment failure.

The good news is that cultural bugs, like code bugs, can be diagnosed and fixed. Below are three of the most common DevOps culture mistakes—framed deliberately as bugs—along with proven remediation strategies.

Bug #1: Letting Success Hinge on a Shiny New Tool

What Goes Wrong

Good DevOps practice does not come pre-packaged in a product. Yet many teams fall into the trap of believing that the right automation platform, CI/CD tool, or observability solution is the missing piece that will unlock DevOps success. When one tool fails to deliver the expected transformation, the response is often to add another tool on top of it, creating a brittle patchwork that is expensive to maintain and difficult to reason about.

The underlying problem is a category error: tools are placed at the center of the strategy rather than in their proper supporting role. This leads to over-investment in tooling evaluations, vendor lock-in risks, and—critically—neglect of the cultural and process changes that actually drive improvement.

The Fix: Adopt a Holistic, People-First Approach

• Culture and process first. Before evaluating any tool, define how your teams communicate, how work flows across boundaries, and what success looks like for each role. Tools should amplify these patterns, not impose new ones.
• Choose tools pragmatically. Select only the tools that match the way your people actually work. A tool that engineers resist using provides no value, regardless of its feature set.
• Prioritize shared visibility. Effective tooling should surface metrics across teams—build times, deployment frequency, mean time to recovery (MTTR), change failure rate. Shared dashboards create healthy transparency and allow teams to learn from one another’s successes and failures.
• Audit regularly. If your organization is continuously reaching for new tools to patch problems, treat that pattern as a signal that a process or culture issue is going unaddressed.

Bug #2: Teams That Once Clicked Are Now Breaking Apart

What Goes Wrong

Building a high-functioning, cross-functional DevOps team—one where developers, operations engineers, QA, and security professionals share goals and speak a common language—is genuinely hard. Organizations that achieve it often find the results transformative. But the culture that makes it work is not self-sustaining.

Mergers and acquisitions, leadership changes, reorganizations, and natural attrition all introduce external forces that can quietly erode shared values and routines. Over time, teams can lose the common goals and rituals that made collaboration feel natural. The symptoms often appear gradually: silos re-form, blame resurfaces, and the cadence of shared learning breaks down.

The Fix: Perform a Soft Reset

When team cohesion starts to slip, resist the urge to add process overhead. Instead, revisit the fundamentals that made the culture work in the first place. Ask these diagnostic questions honestly:

• Are milestones and successes still being celebrated visibly?
• Is progress still being measured, shared, and discussed across team boundaries?
• Does management actively support the team’s work and remove blockers?
• Are culture, process, and tooling still being reviewed on a regular cadence?

If the answer to any of these is no, restoring those relatively simple habits will have an outsized impact. External factors—a new manager, a reorg, a merger—cannot always be controlled. What teams can control is their ability to adapt, communicate openly about the change, and re-anchor around shared goals.

Bug #3: The Team Grows Frustrated With Constraints

What Goes Wrong

Once a DevOps model is running well, teams often begin attending conferences, reading industry blogs, and benchmarking themselves against the most advanced practitioners in the field. This is generally healthy—but it carries a risk. Engineers can become fixated on organizational or regulatory constraints that prevent them from replicating what they read about or hear at events.

When this happens, attention shifts away from the genuine improvements already achieved. Engineers feel blocked rather than empowered. Morale dips, and the culture of continuous improvement gives way to a culture of complaint.

The Fix: Reject Perfectionism, Embrace Pragmatism

Every organization operates within constraints—regulatory requirements, compliance mandates, budget limits, legacy architecture, and organizational inertia. These are facts of engineering life, not signs of failure. A healthy DevOps culture acknowledges constraints clearly and works within them incrementally, rather than treating them as insurmountable barriers.

• Celebrate incremental progress. If a team is continuously delivering high-quality software to an upstream test environment in a measurable, repeatable way—even if the final production deployment still requires a manual approval step—that represents a meaningful improvement over the previous state. Name it. Recognize it.
• Right-size your ambitions. A smaller organization almost certainly does not need the same deployment frequency as a hyperscaler. The relevant benchmark is improvement relative to your own baseline, not absolute comparison with organizations operating at a fundamentally different scale and with different risk profiles.
• Treat constraints as a backlog. Regulatory or architectural constraints that cannot be removed today can often be addressed incrementally over time. Log them, prioritize them, and make steady progress—rather than letting them become a source of demoralization.

Conclusion: Commit to Continuous Diagnosis

No DevOps culture is permanently free of bugs. Teams change, organizations evolve, and the pressures of delivery create new tensions over time. The organizations that sustain DevOps success are not the ones that get everything right from the start—they are the ones that build a habit of honest self-assessment and continuous improvement into the culture itself.

Just as you would not ship code without a mechanism for detecting and fixing defects in production, do not run a DevOps organization without a mechanism for detecting and fixing cultural defects. Diagnose early, fix deliberately, and commit to the long game.

Culture shifts such as DevOps take a lot of hard work, because you need every single person to buy into the new culture. The most successful adoptions we’ve seen of the DevOps mindset start with an organic, bottoms-up approach.

Where to start with DevOps culture

Start with a concrete, immediate problem. For example, at many cloud software companies, engineers are paged when an error occurs. Since no one enjoys being paged, the engineers who are frequently paged are motivated to figure out ways to get a more restful night’s sleep. At one organization we worked with, an engineer realized that pages (errors) correlated with new releases of the application. So she decided to introduce “canary deployments:” running a new version with a small percentage of real traffic side-by-side with the old version and gradually increasing traffic over time. Other developers in the organization saw the success of this approach and adopted it for their own services.

At this company, a developer – in search of more sleep – introduced an operational best practice that an organization then adopted.

We’ve seen this pattern repeatedly. At its core, it comes down to recognizing two facts:

• For IT pros, the most credible recommendation for a better approach comes from their peers. Managers, vendors, and technical journals are all good sources of information, but a peer recommendation carries special weight.
• Developers are biased to adopting solutions that make their immediate lives easier.

Based on what we’ve observed in DevOps environments (including within our own company, Datawire), consider these steps to nurture a DevOps culture:

1. Start small and solve specific, concrete problems

2. Support the problem-solving engineers

It’s essential to let the engineer who is experiencing the problem personally try to solve it. If that engineer doesn’t have the know-how or skills to directly solve the problem, give him or her the right resources (other people, training, time) to tackle the problem. The engineer who is closest to the problem will be able to validate that the solution actually works.

3. Create forums to share successes

Internal DevOps Days, lunch-and-learns, regular engineering meetings, and blog posts are all good ways to share successes and create awareness.

4. Make time to help spread the solution

The engineer who built the canary system wouldn’t have been able to drive adoption if she hadn’t been given time to document her approach – and coach other teams through it.

5. Encourage engineers to engage outside your organization

Valuable outside interaction happens through conference talks, speaking engagements, or public engineering blogs (e.g., the Yelp engineering blogor the Lyft engineering blog). External validation and recognition of an engineer’s work helps with internal advocacy (wow, all these other engineers love this person’s work!). It also gives the engineer a different type of personal satisfaction.

Cultural shifts are not successful unless they’re internalized by the entire team. So, think carefully about how you nurture grassroots efforts when adopting DevOps in your organization.

DevOps Arrives in the Telco World

The rise of DevOps—the collaborative union of development, operations, and quality assurance teams aimed at delivering products and services faster and more reliably—has been one of the defining shifts in enterprise technology over the past decade. Yet its adoption is uneven, and nowhere is that tension more visible than in the communications service provider (CSP) industry.

Telecommunications companies operate some of the most complex technology estates on the planet. Legacy network infrastructure, strict regulatory requirements, and enormous organizational scale have historically made CSPs resistant to the kind of rapid iteration that DevOps promises. And yet several of the world’s largest carriers are now deep into DevOps transformations—with measurable results.

Adoption Is Real, But It Takes Time

DevOps is not a switch that gets flipped. Analytics firm Logz.io’s DevOps Pulse 2017 survey of approximately 700 technology companies found that roughly half had either not fully implemented DevOps or had only done so within the previous year. Among those that had implemented it, 42 percent reported that the process took more than a year to complete.

This matters because one of the core promises of DevOps is faster time-to-market. The irony is that getting there is itself a slow process. Cultural change, toolchain selection, team restructuring, and workflow redesign all take sustained investment before they pay off.

What Major Carriers Are Actually Doing

Several of the largest U.S. carriers have publicly committed to DevOps at scale:

• AT&T drew significant industry attention when it made DevOps a central pillar of its network modernization strategy, aiming to reduce reliance on proprietary hardware and move toward software-defined infrastructure.
• T-Mobile embedded DevOps principles into its broader “Un-Carrier” philosophy, treating deployment speed as a competitive differentiator in product launches and customer-facing features.
• Verizon has pursued DevOps adoption across a large number of internal engineering teams, framing it explicitly as an enabler of business agility.

Ross Clanton, then director of global technology services at Verizon, put the business case plainly:

“At the end of the day it’s about enabling business agility by improving time to value. Getting from business ideas to prioritizing, designing, building and delivering those ideas so they add value to customers as quickly as possible is really what it’s all about.”

Ross Clanton, Director of Global Technology Services, Verizon

Scale: Over 1,000 Teams at a Single Carrier

A common criticism of DevOps in large enterprises is that it works beautifully in small, autonomous product teams but breaks down when applied at enterprise scale. Clanton pushed back against this directly, citing Verizon’s internal numbers:

“We have over 1,000 teams at Verizon practicing DevOps to some degree. These teams have all seen significant improvements in their deployment frequency and overall time to value, with most able to deploy/release changes to their applications weekly or even daily.”

Ross Clanton, Verizon

Weekly or daily deployments represent a significant shift for an industry where release cycles historically spanned months. The goal is continuous integration, delivery, and deployment—what practitioners often call “continuous everything.”

Complexity Is a Reason To Adopt DevOps, Not Avoid It

One of the most persistent objections to DevOps in the CSP context is the sheer complexity of telecommunications networks—legacy switching systems, real-time traffic management, multi-vendor hardware ecosystems, and interdependencies that span decades of incremental build-out.

Clanton’s counterargument is that this complexity is precisely why DevOps practices are necessary, not why they should be avoided. Highly complex systems benefit most from disciplined automation, clear ownership, rapid feedback loops, and observable deployments—all of which are foundational DevOps practices.

This perspective is supported by the broader industry context. As noted in the Ericsson Technology Review, the DevOps approach directly addresses the competing demands of rapid change and system stability—a balance that is particularly critical for 5G rollout, where ultra-low latency, massive device density, and high reliability requirements must coexist with the need to iterate quickly on services and network slices.

Culture Is the Hardest Part—and It Isn’t Unique to Telco

DevOps is as much an organizational philosophy as a technical practice. Large telecommunications companies are not typically celebrated for their cultural agility, which raises a legitimate question: can organizations of this scale and heritage genuinely adopt the collaborative, iterative, blame-free culture that DevOps requires?

“Culture is the most important aspect of DevOps transformation, but I don’t think cultural challenges are unique to CSPs. Verizon absolutely has the desire to make DevOps work at a large scale and we are investing in the cultural changes needed to ensure it is successful.”

Ross Clanton, Verizon

Clanton described Verizon’s cultural investment as including both internal engineering community events and external collaboration efforts designed to build cross-functional relationships and encourage horizontal knowledge sharing across the organization. This kind of deliberate community-building is a recognized pattern in large-scale DevOps transformations: without it, DevOps tends to remain siloed in individual teams rather than propagating across the enterprise.

Automation: The Most Tangible Win

While cultural transformation is the long game, automation delivers nearer-term value. Don Jones of Pluralsight described “obsessive automation” as one of the clearest signs of a genuine DevOps team:

“They know that the job of DevOps is to provide the smoothest, safest, fastest and most reliable path between the developers’ keyboards and a production deployment, so that each new coding sprint can quickly result in a tested production deployment.”

Don Jones, Pluralsight

In a CSP context, this translates to automating processes across the software delivery pipeline: automated testing, infrastructure provisioning, configuration management, deployment pipelines, and rollback procedures. Each of these has standalone value—even organizations that never complete a full cultural DevOps transformation can capture meaningful efficiency gains simply by automating previously manual steps.

This is an important practical point: you don’t have to wait for culture change to get value from automation. The pipeline improvements compound over time, reduce human error, and create the feedback loops that help teams move faster with confidence.

What This Means for 5G and Beyond

The stakes of this transformation are rising. As CSPs build out 5G infrastructure and begin delivering network-slicing, edge compute, and virtualized network functions as services, the pressure to iterate on software quickly—while maintaining carrier-grade reliability—will only intensify.

DevOps practices, including continuous delivery, automated testing at scale, and observable distributed systems, are not optional extras in this environment. They are prerequisites for managing the operational complexity that 5G introduces.

The job market reflects this reality. Engineering roles combining deep network knowledge with DevOps toolchain expertise—CI/CD pipelines, container orchestration, infrastructure-as-code, observability platforms—have become standard listings at major carriers worldwide.

Key Takeaways for Practitioners

• Complexity is not a blocker. The scale and complexity of telco environments make DevOps harder, but also more valuable. Start with automation on the highest-friction parts of your delivery pipeline.
• Culture change is mandatory, not optional. Tooling without cultural alignment produces islands of productivity, not enterprise-wide transformation.
• Full implementation takes time. Budget more than a year for meaningful DevOps adoption across a large organization. Set milestones around deployment frequency and mean time to recovery (MTTR), not just toolchain adoption.
• Automation delivers value independently. Even partial DevOps adoption with strong automation practices yields measurable efficiency gains.
• 5G raises the stakes. The operational demands of 5G make DevOps competency a strategic requirement, not a nice-to-have.

There Is No Step-by-Step Guide to DevOps Culture

Adopting a DevOps culture is not something an organization can mandate in a single meeting. Declaring “we are doing DevOps now” changes nothing on its own, because the transformation is fundamentally cultural rather than procedural. It requires ongoing conversation, iterative adjustment, and genuine commitment from every level of the business — starting with executive leadership and extending all the way to individual contributors on development and operations teams.

Because every organization has a unique history, structure, and set of incentives, there is no universal roadmap. What works at a cloud-native startup will not map directly onto a decades-old enterprise. The cultural shift must be shaped around the specific realities of each company.

Learning from Failure: A Core DevOps Principle

Among the many cultural shifts that DevOps demands, one stands out as both the most important and the most difficult to internalize: treating failure as a learning opportunity rather than a liability. If an organization does not place genuine value on understanding failures in its processes, tooling, and team practices — and on using those failures to drive continuous improvement — its DevOps initiatives will stall regardless of which tools it adopts or which methodologies it follows.

This is precisely why the phrase “DevOps culture” comes up so frequently in the industry. The tooling — CI/CD pipelines, infrastructure as code, monitoring and observability platforms — is the relatively easy part. The hard part is building teams that can honestly examine what went wrong, share that information openly, and act on it without fear of punishment.

Why Fear of Failure Slows Organizations Down

It is entirely understandable that businesses want to minimize outages, bugs, and service disruptions. Incidents carry real costs: direct financial impact from downtime, customer churn, and reputational damage. But a culture that prioritizes preventing all failure above learning from it creates a subtle and damaging trap.

• Slower iteration: Teams that cannot tolerate failure become risk-averse. They deploy less frequently, run fewer experiments, and fall behind competitors who iterate quickly.
• Hidden problems: When failure is punished, engineers hide mistakes. Small issues that could be caught and corrected early go unreported until they become major incidents.
• Stagnation: Genuine improvement — in software quality, in system reliability, in team capability — requires confronting what is not working. A culture that avoids failure effectively avoids growth.

Attempting to prevent every mistake is not only exhausting — it is practically impossible in complex software systems. The goal should be resilience and rapid recovery, not the illusion of perfection.

Psychological Safety: Creating Space for Honest Conversation

For a failure-positive culture to exist, teams need a safe environment in which to be honest. This concept is sometimes called psychological safety — the shared belief that team members will not be punished or humiliated for speaking up about mistakes, questions, or concerns.

Psychological safety does not mean tolerating carelessness. It means that when something goes wrong, the instinctive response is curiosity rather than blame. It means engineers feel comfortable saying “I made a mistake, and here is what I learned” instead of quietly hoping no one notices.

Building this environment is a leadership responsibility. If leaders respond to incidents with recrimination, the message is clear: silence is safer than honesty. If leaders instead model curiosity — asking “what can we learn from this?” rather than “whose fault is this?” — that tone cascades through the organization.

Blameless Postmortems: Structuring the Learning Process

One of the most practical tools DevOps teams use to institutionalize learning from failure is the blameless postmortem. A postmortem is a structured review conducted after an incident or project milestone, focused on understanding what happened and what can be improved — not on identifying individuals to hold responsible.

Key characteristics of an effective blameless postmortem include:

• A focus on systems, not people: Most failures are the result of process gaps, tooling limitations, or unclear communication — not individual incompetence. Postmortems should examine the system that allowed the failure to occur.
• A clear timeline: Reconstructing what happened, in what order, helps teams understand contributing factors and decision points.
• Documented action items: A postmortem that produces no follow-up actions is a missed opportunity. Concrete, owned action items are what turn analysis into improvement.
• Wide sharing: Postmortems should be readable by the broader team, not locked in a private document. Shared knowledge prevents the same mistakes from recurring elsewhere in the organization.

Rewarding Transparency Over Silence

In organizations where a “heads will roll” mentality prevails, employees quickly learn that the safest behavior is to say nothing when something goes wrong. This incentivizes cover-ups, delays problem resolution, and compounds technical debt. The organization loses the opportunity to learn from every incident that goes unreported.

Some organizations that have successfully embedded DevOps principles take the opposite approach: they actively recognize and reward engineers who surface failures, document them clearly, and propose solutions. This is not about rewarding the failure itself — it is about rewarding the transparency and initiative that turn a failure into a systemic improvement.

When surfacing a problem is professionally safe — or even professionally beneficial — the information that flows to engineering and leadership becomes far richer and more actionable.

Trust Is the Foundation

Everything described above depends on trust. Trust that leadership will respond constructively to bad news. Trust that colleagues will engage with postmortems honestly rather than defensively. Trust that the organization values improvement over the appearance of infallibility.

Trust of this kind cannot be mandated — it is built over time through consistent behavior. Leaders who model vulnerability, who publicly acknowledge their own mistakes and what they learned from them, do more to build a failure-positive culture than any policy document could.

Key Takeaways

• DevOps culture cannot be installed; it must be grown through ongoing behavioral change at every level of the organization.
• Learning from failure is a prerequisite for continuous improvement — not an optional nice-to-have.
• A culture that punishes failure incentivizes silence, which makes systems less reliable over time.
• Blameless postmortems are a practical mechanism for turning incidents into institutional knowledge.
• Psychological safety and organizational trust are the foundations on which all of this depends, and both start with leadership.
• Teams empowered to learn from failure adapt faster, build more reliable systems, and contribute more directly to business outcomes.

What Is DevOps Intelligence?

Most DevOps transformations focus on tooling and process: CI/CD pipelines, infrastructure-as-code, automated testing. But a critical next step is often overlooked—using the data those pipelines generate to make smarter decisions. That practice is called DevOps Intelligence.

DevOps Intelligence means collecting, analyzing, and acting on data from across your entire software delivery lifecycle—from code commit to production deployment. The goal is to deliver software more efficiently, with less risk, and with measurable business value. As both the demand for faster software and the complexity of modern applications continue to grow, building intelligence into your delivery process is no longer optional—it is a competitive requirement.

Below are seven concrete benefits of making DevOps Intelligence a priority.

1. Faster Release Cycles

End-to-end visibility into your delivery pipeline makes it possible to identify and eliminate waste. With real-time metrics, teams can pinpoint bottlenecks—whether that is a slow test suite, a manual approval gate, or an environment that is consistently unavailable—and take targeted action to remove them.

Key metrics to track include:

• Deployment frequency – how often you ship to production
• Lead time for changes – from commit to live deployment
• Deployment success rate – the percentage of deployments that complete without rollback
• Cycle time per team – where handoffs are slowing overall throughput

When this data is visible in real time, teams stop guessing and start optimizing with evidence.

2. Higher Quality Software

DevOps Intelligence enables tighter, faster feedback loops—the foundation of iterative development. When teams can see immediately how a change affects test pass rates, error budgets, or user-facing error rates, they can course-correct before problems compound.

Feedback loops are especially valuable for experiments: A/B tests on new UI patterns, feature flags, or canary deployments. Because failures are fast, small, and contained, the cost of learning is low and the speed of improvement is high. DevOps Intelligence provides the signal that tells you whether an experiment succeeded or should be rolled back.

3. Increased Business Value of Software

Shipping faster is only valuable if what you ship matters to customers. DevOps Intelligence closes the loop between delivery and outcome by surfacing data such as:

• Which features customers actually use
• Which flows they abandon
• How behavior changes after a release

This post-release intelligence supports impact analysis—did the work you delivered actually move the needle for users? Those answers feed directly into prioritization decisions for the next iteration, reducing the risk of building the wrong thing.

4. Greater Transparency Across the Organization

A common friction point between IT and the rest of the business is the perceived black box of software delivery. Stakeholders ask when a feature will ship; engineers struggle to give a reliable answer. DevOps Intelligence replaces that uncertainty with shared, real-time dashboards that anyone in the organization can read.

This transparency has practical benefits:

• It is easier to justify requests for additional time or resources when you can point to data.
• Release dates can be driven by measurable readiness criteria rather than arbitrary calendar commitments.
• Non-technical stakeholders can track progress independently, reducing the overhead of status meetings and one-off requests to IT.

5. Proactive and Predictive Delivery Management

Reactive management—fixing problems after they appear in production—is expensive and stressful. DevOps Intelligence shifts the posture toward proactive management by combining real-time monitoring with historical trend analysis.

Real-time signals provide early warnings: a deployment that is taking longer than usual, a spike in test failures after a particular commit, or an environment showing resource pressure before it causes an outage.

Historical data enables prediction: which types of changes historically correlate with incidents, how long certain release tasks typically take, and where capacity constraints tend to emerge at scale. Together, these inputs support smarter planning and fewer production surprises.

6. Simplified Compliance and Audit Readiness

In regulated industries—finance, healthcare, government—audit readiness is non-negotiable. DevOps Intelligence automatically captures an auditable record of your delivery process: who did what, when, whether defined processes were followed, what failed, and what remediation steps were taken.

Instead of reconstructing this trail manually from scattered logs and emails during an audit, teams can query their delivery data directly. This reduces compliance overhead and provides early warning when process gaps might put compliance status at risk.

7. A Stronger, More Empowered DevOps Culture

Culture change is harder to measure than pipeline metrics, but DevOps Intelligence contributes to it in a concrete way. When data about delivery performance is visible across the organization, it does several things:

• It surfaces team and individual contributions that might otherwise go unrecognized.
• It gives engineers objective evidence to support process improvement proposals.
• It invites people outside IT—product managers, support teams, business analysts—to participate meaningfully in decisions about how software is built and shipped.

Shared data creates shared ownership. That is a prerequisite for a genuinely collaborative DevOps culture rather than a superficial one.

Building the Infrastructure for DevOps Intelligence

None of these benefits are automatic. Realizing them requires building the infrastructure to capture, centralize, and analyze data from across your toolchain—version control, CI servers, test frameworks, deployment platforms, monitoring systems, and ticketing tools.

As organizations mature their DevOps practices and adopt release orchestration platforms, they gain the ability to aggregate this data automatically and surface it in actionable dashboards. The result is a delivery organization that can measure its own performance, improve continuously, and demonstrate its value to the broader business in terms that non-technical stakeholders understand.

DevOps Intelligence is not a single tool. It is a discipline—and investing in it is what separates teams that ship fast from teams that ship well.

By now, most people in IT and product management understand DevOps. The power of DevOps, like Agile, is that there’s no strict rule set to follow, nor is there a standard to adhere to. It’s open to interpretation and adaptation according to your own corporate, customer, product, or cultural situation.

However, corporate culture sits square in the cross hairs of what DevOps aims to improve. With this in mind, is it better to change corporate culture at the time you adopt a DevOps practice, or wait for your DevOps practice to influence cultural change organically over time? As usual, the answer is: it depends. But here are some suggestions for a smooth transition.

Who does DevOps affect?

Typically, DevOps is cited as helping unite and influence the culture and work processes of an organization’s:

• Software developers – those tasked with creating and modifying software
• IT operations personnel – those tasked with keeping systems available
• Quality assurance (QA) staff – those tasked with finding issues before users do

One goal is to remove barriers and silos that derive from IT’s role to keep things stable, developers’ role to disrupt (through new features), and QA’s role to uncover issues early and avoid risk. These obtuse goals can put people in these groups in adversarial positions (i.e. developers taking QA’s bug findings personally, and IT blaming developers for issues in the environments they’re responsible for). Therefore, it’s important to ensure everyone learns to work together towards the same end-goals: customer satisfaction and business growth.

Expanding the culture of DevOps

However, the three groups above aren’t the only ones your DevOps practice should focus on. Arguably, it’s just as important to include your customer support staff, product management, and even executives in your DevOps practice.

The biggest reason to include support staff is so that there are no surprises when new or modified features (even removed features) are released. I’ve heard horror stories of support staff getting customer calls on a Monday because of changes that occurred over the weekend, which they had no idea was even planned. When your own staff hears about application changes from your customers first, you should improve your culture of communication as soon as possible.

As for executives, there’s immense value in understanding the hidden business impact of top-down decisions. DevOps can also help influence future executive business direction based on feedback loops from within the organization as well as actual software users and customers. A culture where executives are disconnected from what happens on the front lines hurts morale, customer satisfaction, and ultimately the business.

The DevOps turnstile: Continuous cultural improvement

Let’s look at some specific cultural changes you should enact ahead of time or expect over time with a DevOps practice. However, regardless of whether a specific cultural change is listed as either “before” or “after” DevOps is implemented, all of them should be considered subject to continuous improvement. For example, team building to instill trust isn’t something that’s done just once; it’s a continuous process. Let’s begin with some changes to enact when you begin your DevOps journey:

Exposure to real user feedback: It’s amazing how many organizations never hear from or know who their users are. I’ve experienced this multiple times myself. Understanding firsthand that the product they support has positive impact on real people can go a long way towards improving motivation. There’s no need to wait on this one; encourage communication with users right away.

Team building: As stated previously, this helps instill trust between teams, avoids finger pointing, and helps to align individual motivation. Teams that connect on a personal level tend to work more as a unit. This culture of cooperation will strengthen as everyone sees the benefits.

Create channels of collaboration: This goes beyond installing instant messaging or other real-time collaboration tools. It starts with team building and continues with cross-functional team meetings, and the encouragement of unofficial meetings and gatherings. Instead of working to silence disagreements or frustrations, help teams constructively voice their concerns or criticisms. Proper coaching can help teams grow stronger together even when they disagree at times, have differences of opinion, or get frustrated with one another.

Sharing roles: Have developers take part in IT staff procedures, such as software deployment and system monitoring. Additionally, include IT in software development sprint planning to provide feedback into software design and feature development. After all, both groups have valuable insight into system behavior, but from different points of view. The cross pollination eliminates bottlenecks, and helps people feel more valuable to the overall process.

The following cultural changes are best influenced over time, aftera DevOps practice is in place:

Design for testability: Including QA in sprints helps to build software for testability—even though the main goal is to meet customer needs—because a system that’s testable tends to be of higher quality. In fact, I once worked in a group that required a test plan along with each story. After all, if you don’t know how you’re going to test a new feature, how do you know you’re building it right? This culture of QA goes a long way towards increasing customer satisfaction through quality.

Create a culture of autonomy and mastery: In this change , each contributor has fewer dependencies on others to achieve personal and organizational success. In turn, each team member feels empowered to make a bigger difference. This is definitely a cultural change that takes time to develop and refine, especially since it varies by individual. The rewards are many, for both the team members and the organization, as this approach builds both confidence and velocity.

Reduced fear of failure: This is another cultural change that will take time in most organizations, and it’s best to build confidence in your DevOps practices before expecting everyone to feel comfortable with failure. Of course, failure is never the actual goal. However, in a true lean, agile organization, failure is encouraged early in order to make corrections sooner rather than later.

Encourage knowledge and skill sharing: It takes time to expect people to grow comfortable enough to share their knowledge and skills, and in effect level the playing field by losing what they feel makes them uniquely valuable. However, as a successful DevOps practice eliminates bottlenecks, no one will want to be identified as a bottleneck themselves due to lack of transparency. As team members witness first-hand the benefits of sharing and transparency, they’ll open up more and more, making themselves more valuable in the process.

Continuous maturity

As your organization matures along with its DevOps practice, you should see positive cultural improvements as a natural offshoot; it’s best not to force it. And although the goal is to better serve your users while growing the business, there’s no reason not to enjoy the process while doing it.

Why Getting DevOps Right Matters

DevOps adoption has grown substantially across organizations of all sizes, with a large proportion of enterprises and small-to-medium businesses reporting that they have adopted at least some DevOps practices. The promised benefits — greater agility, improved customer satisfaction, higher employee morale, and measurable business growth — make the approach attractive. But adoption alone does not guarantee results.

Survey data from Puppet’s State of DevOps research highlights a stark performance gap: high-performing DevOps teams deploy code far more frequently than low performers, recover from incidents significantly faster, and experience lower change failure rates. Workers at those high-performing organizations are also notably more likely to recommend their employer as a great place to work.

The CA Technologies study reported that organizations with more advanced DevOps practices saw meaningful improvements across IT costs, business growth, operational efficiency, application quality, employee productivity, customer experience, and talent retention — compared to less mature peers.

The difference between thriving and struggling frequently comes down to a handful of avoidable mistakes. Here are nine of the most common ones.

Mistake 1: Emphasizing Speed Over Quality

The primary draw of DevOps for many organizations is faster delivery. However, chasing speed while letting quality slip defeats the purpose. Releasing broken or poorly tested code faster simply accelerates the delivery of problems to production.

The antidote is shift-left testing — integrating testing as early in the development lifecycle as possible, ideally writing tests alongside code at the point of check-in. Despite widespread awareness of this practice, adoption remains low. The Sauce Labs / Dimensional Research “Testing Trends in 2017” report found that only 19% of development teams follow the best practice of writing tests when they check code in.

Key action: Treat test coverage as a first-class deliverable, not an afterthought. Make it a gate in your CI pipeline so that untested code cannot proceed.

Mistake 2: Deploying Too Infrequently

The flip side of the speed problem is not moving fast enough. Puppet’s research found that high-performing teams averaged roughly 1,460 deploys per year — multiple times per day — while low-performing teams might deploy as rarely as seven times per year. The resulting difference in lead times was orders of magnitude apart.

Infrequent deployments mean larger batch sizes, which in turn mean more risk per release, harder rollbacks, and longer feedback loops. Small, frequent releases are safer and easier to reason about.

Key action: Build a deployment pipeline that makes releasing small changes routine, safe, and boring — not an occasional high-stakes event.

Mistake 3: Staying Permanently in the Experimental Stage

Starting small with DevOps is sensible advice. Piloting the approach on a single team or project lets organizations learn without widespread disruption. The problem arises when the pilot never graduates into broader adoption.

RightScale’s 2017 data showed that only 30% of organizations had adopted DevOps company-wide. The Sauce Labs study put company-wide adoption even lower, at 10%. The CA Technologies research concluded that only around a third of businesses had achieved any real maturity in their DevOps practice — and that lack of maturity translated directly into higher costs, slower growth, and lower customer satisfaction.

Key action: Define a deliberate roadmap for expanding DevOps practices beyond the initial pilot. Set milestones for broader rollout and track them.

Mistake 4: Failing to Change the Culture

Tools and processes are the visible parts of DevOps transformation, but culture is the foundation. Without a genuine shift in how teams collaborate, share responsibility, and respond to failure, the tools will not deliver their potential.

In the CA Technologies survey, 34% of respondents identified organizational culture and mindset as too resistant to change, and 28% pointed to a lack of senior management commitment. Leadership must actively model the behaviors they want to see — a willingness to experiment, to learn from failure, and to break down silos between development and operations.

Key action: Treat blameless post-mortems, cross-functional collaboration, and shared on-call responsibilities as non-negotiable cultural practices, not optional extras.

Mistake 5: Moving Forward Without Sufficient Training and Expertise

Culture change requires capable people. DevOps tooling and practices have a real learning curve, and teams that lack the necessary skills will struggle to realize the benefits — or will adopt tools superficially without changing their underlying workflows.

The SDxCentral 2016 Cloud Automation and DevOps Report found that 68% of organizations not using DevOps tools attributed this to a lack of expertise. The CA Technologies study found that 32% cited inadequate in-house skills as a key obstacle to implementation.

Key action: Budget for formal training, internal knowledge sharing, and where necessary, bringing in experienced practitioners to accelerate the learning curve across the team.

Mistake 6: Relying on Manual Deployment Processes

Manual steps in deployment pipelines are a source of risk. A widely cited example is the 2012 Knight Capital incident, in which a manual software deployment to eight servers went wrong on one of them — reportedly because an employee missed a step. The resulting runaway automated trading caused losses of approximately $440 million and effectively destroyed the company’s stock value within hours.

Puppet’s research supports the case for automation, noting that the use of continuous delivery practices — including deployment automation, continuous integration, continuous testing, and version control for all production artifacts — predicted lower deployment pain, higher IT performance, and lower change failure rates.

Key action: Automate every repeatable step in your build, test, and deployment pipeline. Treat manual deployment steps as technical debt to be eliminated.

Mistake 7: Using the Wrong Tools — or No Tools at All

In the CA Technologies survey, 36% of respondents cited integrating the right tools and techniques as a major obstacle, and 35% pointed to tool availability as a problem. Tooling matters, but the relationship is more nuanced than simply buying a continuous deployment platform or adopting container technology.

The wrong tools — or tools that teams resist using — will not drive improvement. The best tool is one that fits the team’s actual workflow, integrates cleanly with the rest of the pipeline, and that practitioners understand well enough to maintain and extend.

Key action: Evaluate tools against your team’s specific requirements and existing stack. Involve the engineers who will use them day-to-day in the selection process.

Mistake 8: Allowing Too Many Long-Lived Branches

Teams transitioning from traditional waterfall environments often carry over the habit of working in long-lived feature branches. In a DevOps context, this creates integration problems, delays feedback, and makes continuous integration effectively impossible.

Puppet’s State of DevOps research identified trunk-based development practices as a meaningful contributor to high performance: specifically, branches or forks with lifetimes of less than a day before being merged into the trunk, fewer than three active branches in total, and daily merges into trunk or master.

Key action: Adopt trunk-based development or, at a minimum, enforce short-lived branch policies. Use feature flags to decouple code deployment from feature release rather than relying on long-running branches.

Mistake 9: Treating Security as an Afterthought

Security is consistently the top-cited obstacle to DevOps maturity. The CA Technologies survey found that security concerns were identified by 38% of respondents as their primary DevOps barrier. Yet Puppet’s research also found that high-performing DevOps teams spend significantly less time remediating security issues than low performers — suggesting that when security is integrated into the development process early, it becomes less of a burden, not more.

The emerging practice of DevSecOps addresses this directly, embedding security reviews, automated security testing, and policy enforcement into the CI/CD pipeline rather than layering them on at the end.

Key action: Shift security left alongside testing. Introduce static analysis, dependency vulnerability scanning, and infrastructure-as-code policy checks as automated pipeline stages from the start.

Summary: The Common Thread

Most of these nine mistakes share a common root: treating DevOps as a set of tools to deploy rather than a continuous improvement discipline that touches people, process, and technology equally. High-performing teams automate aggressively, release frequently, test early, keep branches short, integrate security throughout, and invest in the skills and culture that make all of it sustainable.

Avoiding these pitfalls will not happen overnight, but recognizing them is the necessary first step toward building a genuinely high-performing engineering organization.

What Is Groupthink, and Why Does It Matter in DevOps?

The term groupthink was introduced by social psychologist Irving Janis in 1972 to describe a psychological phenomenon in which the desire for harmony or conformity within a group overrides realistic appraisal of alternatives. Members prioritize consensus over correctness, and dissenting voices are quietly suppressed—sometimes without anyone realising it is happening.

On the surface, groupthink in a DevOps context sounds contradictory. DevOps teams are deliberately cross-functional, bringing together engineers with genuinely different priorities: a security engineer and a release engineer rarely share the same definition of “done.” You would expect those differences to generate productive friction, healthy debate, and well-rounded decisions.

Yet tightly knit, high-performing teams are among the most susceptible to groupthink. The same trust and psychological safety that enable fast delivery can also make team members reluctant to challenge a colleague, question an informal leader, or slow down a sprint to raise an uncomfortable concern.

Why DevOps Teams Are Particularly Vulnerable

Several structural characteristics of DevOps teams create fertile ground for groupthink:

• Deference to domain experts. When a problem touches a specialist’s area—say, infrastructure-as-code or container orchestration—other team members often defer rather than probe. This is efficient, but it concentrates decision-making and sidelines alternative perspectives.
• Speed pressure. Continuous integration and continuous delivery pipelines are optimised for velocity. Teams internalise a norm of deciding quickly and moving on, which leaves little room for deliberate second-guessing.
• Informal authority. In flat DevOps teams, informal leaders emerge based on tenure, reputation, or communication style. Their opinions carry disproportionate weight, and others self-censor to avoid conflict.
• Fixed mindsets from functional silos. Even after silos are formally dissolved, individuals carry ingrained assumptions from their discipline. When those assumptions go unchallenged, they quietly shape group decisions.
• Amplification of individual bias. Group discussion does not always average out biases—it can amplify them. A team that starts a meeting leaning toward one solution may leave fully committed to it, having talked themselves into certainty.

Warning Signs of Groupthink in a DevOps Team

Groupthink rarely announces itself. It masquerades as alignment, efficiency, and team cohesion. Look for these specific signals:

• Illusion of invulnerability. The team consistently believes its architecture, process, or plan is sound without rigorous stress-testing of that belief. Post-mortems are short because “we already know what happened.”
• Consistent agreement with little discussion. Retrospectives and architecture reviews end quickly, with no meaningful objections raised. Everyone nods, but the silence may be self-censorship rather than genuine consensus.
• Collective rationalization. When warning signs appear—a flaky test suite, an alert that keeps firing, a dependency that keeps causing incidents—the team collectively explains them away rather than treating them as signals worth investigating.
• Self-censorship. Individual team members privately hold reservations but do not voice them in group settings, particularly in stand-ups, sprint reviews, or change advisory discussions.
• Stereotyping outsiders. Feedback from security, compliance, or product teams is routinely dismissed as “they don’t understand how we work,” without genuine engagement.
• Pressure on dissenters. When someone does raise a concern, the response is social pressure to get on board rather than substantive engagement with the concern itself.

The Real Cost: Deliberation Failures in Delivery

In a DevOps context, deliberation failures are not abstract—they have concrete consequences. A team that groupthinks its way through an architecture decision may ship a system that is operationally fragile. A team that defers too readily to the loudest voice on incident response may adopt a fix that treats symptoms rather than root causes. A team that never questions its deployment pipeline may accumulate hidden risk until a high-severity outage reveals it.

The irony is that these failures often surface during the moments DevOps practices are meant to protect against: production incidents, failed deployments, and security breaches.

Practical Strategies to Counter Groupthink

Awareness is necessary but not sufficient. Teams need deliberate structural interventions:

Assign a Devil’s Advocate

Rotate the role of formal challenger in architecture reviews and incident post-mortems. When dissent is a named responsibility rather than a personal choice, it becomes safer to exercise and harder to ignore.

Use Pre-Mortems

Before a major deployment or architectural change, ask the team: “Assume this has failed six months from now. What went wrong?” Pre-mortems surface concerns that self-censorship would otherwise suppress, and they do so before failure rather than after.

Write Before You Discuss

Ask team members to write down their individual assessment of a proposal or incident before the group discussion begins. This preserves independent thinking and prevents the first speaker from anchoring the entire conversation.

Invite Outside Perspectives

Periodically include someone outside the team—from a different squad, a platform team, or a security review board—in design reviews. External reviewers have no social investment in the team’s existing decisions and are more likely to ask uncomfortable questions.

Create Safe Channels for Dissent

Some concerns are easier to raise asynchronously than in a live meeting. Anonymous retrospective tools, written RFC (Request for Comments) processes, and one-on-one conversations with a tech lead can give quieter team members a path to surface concerns without social risk.

Distinguish Consensus from Unanimity

Make it explicit that the goal of a team discussion is the best decision, not a decision everyone loves. Decisions can be made and committed to even when some team members disagree—but those disagreements should be heard and recorded, not suppressed.

Building a Culture of Constructive Disagreement

The long-term antidote to groupthink is a team culture in which disagreement is valued, not merely tolerated. This requires explicit modelling from senior engineers and engineering managers. When a team lead visibly updates their position in response to a junior engineer’s objection, or publicly credits a dissenting voice for preventing a bad decision, it signals that speaking up is rewarded rather than punished.

DevOps teams that navigate this challenge well tend to ship more reliable software, run more honest post-mortems, and make better architectural trade-offs—not because they argue more, but because every voice in the room is genuinely in play.

Recognising groupthink is the first step. Building the structures and norms that prevent it is the real work—and it is continuous, much like the delivery pipelines these teams are built to run.

Effective collaboration and communication are highly valued by the DevOps culture, and it’s been like that for a reason. It is an industry where even departments within the same company tend to distrust one another, and where distributed offices full of crucial roles are the norm. Thus, any possible positive improvement in the interaction between people is welcomed, especially for an organization where several moving parts need to collaborate in order to create a product on time and within a budget limitation. You need to master communications if you want to master DevOps. Getting your operations and development teams to work together is the concept on which the success of DevOps hinges. These DevOps tips can help you lay out the basis for a DevOps communication plan that’s sustainable.

1. Always remember why you’re doing what you’re doing. The whole system would continue to pick up efficiency and speed if the employees moved from one bottleneck to the next and improve each one. People tend to focus on how they’re performing a task and forget why they’re doing in the first place, also not taking into account the whole IT organization.

2. Value the importance of continuous feedback. Because for creating a successful DevOps plan and measuring its effectiveness, continuous feedback is crucial. Product management, design, development, and every other part of the manufacturing process can use it, because continuous feedback is important for enabling the employees to learn from their mistakes, and to not maintain a linear view of the delivery process, in order to grow.

3. Address security as soon as possible. Security must not be looked as something that can be decided upon later in the development cycle. It needs to exist as a feature of the product, so creating DevOps without addressing the matter of security can be very dangerous to your organization.

4. Always stay transparent. Share all progress and information across the whole organization. Send failure notification and status updates in order to help your organization increase speed, productivity, and stay on the same page.

5. Promote mutual respect and teamwork. These two things cannot be understated, because all of the employees have to work together for the common goal, thus stay on the same page. It is important to have a clearly defined internal communications plan, use communication channels and chat rooms where everyone can discuss the ongoing work, and make sure that the flow of the organization as a whole can’t be interrupted by any one team.

6. The collaboration of the IT and development teams must not be interfered with. It is crucial to prevent any corporate policy do this, because the success of the DevOps will be empowered when the development teams have enough resources and freedom. This will lead to shorter release cycles and reduced deployment downtime. However, the support of this change in organization culture lies in proper management, so the barriers between these two company segments get broken down.

7. Encourage dialog. Are the communications your employees receive open for discussion or are made as statements? Do they seem like they were written by someone who has already decided on the best approach and is just notifying the rest of us? This should be prevented by asking employee’s input for their area of expertise. Always make sure to ask for feedback in the communications by asking flat out what issues they see, through a response to the message, or a requested meeting.

8. Establish an effective time management plan. The need for it comes from the need to achieve process excellence and improve communication. If you want to use DevOps, know that your team may need to change the way they pace their day, tweak schedules, and change long-held habits. The use of it leads to various changes in terms of how people work, why they organize their work in different ways, and what they are asked to do in their job position. Effective time management comes to combining individual and organizational excellence to provide your working team the flexibility to work as efficiently as possible. They need to maintain enough structure to stay on the same page and motivated, while having the freedom to find the methods that work best for them.

As rapid deployment becomes the norm, every business centered around producing software will be challenged by collaboration and communication. Thus, leaders and managers should always pay attention to how their departments work together as a whole. The more familiar your employees are with each other, the better communication will be, and that’s what you need in the process of production.

What Is a Blameless Culture?

A blameless culture is one in which individuals can report failures, near-misses, and mistakes honestly — without fear of punishment or reprimand. Instead of asking “who broke it?”, the team asks “what in our system made this failure possible, and how do we prevent it happening again?” The focus shifts from individuals to systemic weaknesses, producing insights that actually reduce risk rather than simply assigning accountability.

Collaboration Naturally Reduces Blame

The foundation of a healthy DevOps culture is genuine collaboration — not just between development and operations, but across every team involved in delivering software: product, QA, security, and business stakeholders. When everyone shares the same goal — delivering a high-quality product as quickly and safely as possible — the instinct to deflect blame onto another team diminishes naturally.

Failures will occur in any sufficiently complex system. The question is not whether incidents will happen, but how the organisation responds when they do. Teams that have established strong collaborative norms treat failures as shared learning opportunities rather than opportunities to assign fault. Blameless post-mortems (also called retrospectives or after-action reviews) are the primary tool for turning failures into system improvements. The explicit goal of a blameless post-mortem is to surface root causes, identify corrective actions, and share findings broadly — not to identify a guilty party.

Failures Are System Problems, Not Personal Failures

A core principle of blameless post-mortems is that system failures are the product of complex, interacting factors — not the result of a single person’s carelessness. When an engineer makes a decision that leads to an outage, that decision made sense to them at the time given the information, tools, and pressures they were operating under. Understanding why it made sense is far more valuable than establishing who was at fault.

Punishing or reprimanding individuals after an incident has a direct, measurable negative effect on future incident analysis: engineers become reluctant to share full context, omit details that might reflect poorly on themselves, and focus on self-protection rather than learning. The result is an incomplete picture of the failure — one that leaves the underlying vulnerabilities unaddressed. The same incident, or a closely related one, is then likely to recur.

Blame — even directed inwards — is a negative thing and doesn’t help to gain insight into the context of the situation or how to reduce risk in the future.

Look at the Bigger Picture: System Conditions Over Human Error

Labelling “human error” as the root cause of an incident is a dead end. It is descriptive rather than diagnostic — it tells you that a person made a mistake, but gives you nothing actionable to prevent the next mistake. Effective post-mortems dig deeper:

• What conditions allowed the error to occur? Poor tooling, missing guardrails, unclear runbooks, inadequate monitoring?
• What information did the engineer have — and not have — at the time? Gaps in observability or documentation?
• Could the system have been designed to make the error impossible, or at least much harder? Automated checks, access controls, deployment gates?
• Were there earlier warning signals that the team was not equipped to detect? Alert fatigue, missing dashboards?

By systematically closing the gaps that made a failure possible — rather than simply reprimanding the individual who triggered it — organisations build systems that are demonstrably more resilient. Management plays a critical role here: leaders must model the behaviour they want to see. If a senior engineer or manager responds to an incident by visibly shifting blame, the rest of the team will draw the obvious conclusion about what safety really means in that organisation.

Remove the Fear of Repercussions to Unlock Innovation

The benefits of a blameless culture extend well beyond incident response. Once engineers know they can discuss mistakes openly without career consequences, several positive dynamics emerge:

• Proactive knowledge sharing. Engineers who have made a mistake become motivated to share what they learned — through internal documentation, team talks, or runbook updates — helping colleagues avoid the same pitfall.
• Greater willingness to experiment. Fear of failure is one of the strongest inhibitors of innovation. When that fear is removed, engineers are more willing to try new approaches, propose improvements, and challenge existing assumptions.
• Faster feedback loops. Issues that might otherwise be concealed — for fear of blame — are surfaced sooner, when they are cheaper to fix.
• Higher psychological safety. Teams with high psychological safety consistently demonstrate stronger performance on complex, collaborative tasks.

Taken together, these dynamics produce a culture of continuous improvement: one where every incident, near-miss, and successful experiment contributes to a more capable, more resilient system over time.

Practical Steps to Build a Blameless DevOps Culture

Declaring a culture “blameless” is not enough. The following practices help make blamelessness real:

1. Adopt a structured blameless post-mortem format. Document the timeline, contributing factors, and corrective actions — not the names of individuals who made decisions.
2. Share post-mortems widely. Publishing findings internally (sanitised where necessary) normalises failure as a learning event and distributes the lessons learned.
3. Train managers first. Leadership behaviour sets the cultural tone. Managers who respond to incidents with curiosity rather than anger signal safety to the entire team.
4. Separate accountability from blame. Individuals can still own corrective actions without being blamed for the original failure. Accountability is about fixing the system; blame is about punishing the person.
5. Track action items from post-mortems. Nothing undermines blameless culture faster than a post-mortem that produces a list of improvements that are never implemented. Assign owners, set deadlines, and review progress.
6. Celebrate learning, not just success. Recognise teams that surface and resolve issues proactively, not only those that ship features without incident.

Blamelessness Is Core to DevOps, Not Optional

Continuous delivery, infrastructure automation, and monitoring tooling are the visible artefacts of a DevOps organisation. Blameless culture is the invisible foundation that makes those artefacts effective. Without it, post-mortems become political exercises, incidents go unreported, and the same failures repeat indefinitely. With it, every failure becomes a source of organisational learning — and the system grows safer and more capable over time. That compounding improvement is what DevOps, at its best, is designed to produce.

Originally sourced from sandhata.com (2017). Rewritten and expanded for accuracy and completeness.

From Niche Concept to Business Imperative

DevOps reached mainstream status by solving a fundamental tension inside technology organisations: the conflict between the pace of development and the stability demands of operations. When those two functions work in silos, releases slow down, incidents multiply, and innovation stalls. When they work together under a shared DevOps culture, delivery accelerates and quality improves simultaneously.

Industry research such as the annual State of DevOps Report (published by DORA, now part of Google Cloud) has repeatedly documented a performance gap between high-performing DevOps organisations and low performers — across deployment frequency, lead time for changes, mean time to recover, and change failure rate. Organisations that consistently score in the elite tier on those four metrics tend to outpace competitors on both revenue growth and customer satisfaction.

Why DevOps Translates to Competitive Advantage

Sacha Labourey, CEO of CloudBees, has summarised the strategic value well:

“A DevOps approach enables companies to respond much more quickly to customer needs, competitive pressures and realise faster time to innovation. Because DevOps is all about a culture of shared goals, and processes that accelerate software delivery through smaller, incremental releases, issued more frequently.”

Sacha Labourey, CEO, CloudBees

That framing highlights three concrete advantages:

• Speed to market. Smaller, more frequent releases mean new features and fixes reach users faster. A company shipping valuable updates weekly outpaces one shipping quarterly, all else being equal.
• Responsiveness to customers. Continuous feedback loops — enabled by monitoring, alerting, and frequent deployments — let teams course-correct before small problems become large ones.
• Faster innovation cycles. When deployment risk is low and rollback is straightforward, engineers experiment more freely. That experimentation is the engine of product innovation.

Cultural Change Is Non-Negotiable

Labourey also cautions that tooling alone will not deliver these benefits. DevOps only reaches its full potential when the entire organisation is aligned — from engineering teams to leadership to business stakeholders. Deploying a CI/CD pipeline without addressing the underlying cultural dynamics is a common and costly mistake.

Successful DevOps adoption requires:

• Internal education at all levels. Developers, operations engineers, security teams, product managers, and executives all need to understand the structural and cultural shift that DevOps represents. A VP who still measures success by headcount rather than deployment frequency will undermine progress.
• Breaking down organisational silos. Teams that have historically operated independently — or worse, in opposition — must be brought into shared workflows, shared metrics, and shared accountability.
• Aligned goals and shared definitions of success. Many inter-team conflicts arise because development is measured on feature velocity while operations is measured on uptime stability. DevOps replaces those competing incentives with unified objectives such as reliable, frequent delivery.

Turning Former Adversaries into Collaborators

The classic pre-DevOps tension between “Dev” (move fast, ship features) and “Ops” (maintain stability, avoid change) is well documented. In organisations where that tension has escalated into entrenched conflict, DevOps adoption is harder but even more valuable. The cultural shift requires active leadership sponsorship, clear communication of why things are changing, and patience — culture does not change overnight.

Practical steps that help bridge this divide include:

• Embedding operations engineers in development squads (or vice versa) so knowledge flows in both directions.
• Using blameless post-mortems to build psychological safety and make failure a learning event rather than a political one.
• Establishing shared on-call rotations so developers experience the operational consequences of their code.
• Measuring and celebrating team-level outcomes rather than individual heroics.

The Cost of Standing Still

Organisations that delay DevOps adoption do not simply stay in place — they fall behind. As competitors reduce their lead times and increase deployment frequency, the gap in responsiveness and innovation rate compounds over time. What was once a six-month release cycle becomes a genuine competitive liability when a rival can iterate weekly.

The good news is that it is never too late to start. Most organisations begin with a focused pilot — a single product team, a single pipeline — and expand the model as they demonstrate results. The key is to start with both the tooling and the culture in mind from day one, rather than treating one as an afterthought of the other.

Key Takeaways

• DevOps is a mainstream business strategy, not a niche engineering practice.
• Its primary competitive advantages are speed to market, customer responsiveness, and faster innovation cycles.
• Tooling without cultural alignment delivers limited and fragile results.
• Shared goals and unified success metrics are the foundation for turning adversarial teams into collaborative ones.
• Organisations that delay adoption widen the gap between themselves and competitors who have already made the shift.