DevOps Maturity in 2018: Still a Work in Progress

By 2018, DevOps had moved well beyond buzzword status. Most enterprises had launched some form of DevOps initiative, and many had evolved into round-the-clock software delivery organisations. Yet results varied enormously from one company to the next. Some teams were shipping multiple times per day with high confidence; others were still struggling with siloed workflows and manual deployments.

To understand why outcomes differed so dramatically, Puppet analysed survey responses from thousands of technology professionals and published its findings in the 2018 State of DevOps Report. A central output of that analysis was a structured, six-stage maturity model — numbered Stage 0 through Stage 5 — designed to give organisations a clear map of the DevOps journey and concrete practices to focus on at each point.

Nigel Kersten, VP of Ecosystem Engineering at Puppet, summarised the challenge: “While DevOps practices have become far more well known across our industry, organisations continue to struggle to scale pockets of DevOps success more broadly across multiple teams and departments. This year’s report explores the foundational practices that need to be in place in order to scale DevOps success, and proves that success can only scale when teams are enabled to work across functional boundaries.”

The Six-Stage DevOps Maturity Model

The model is sequential but not rigid — organisations may find themselves stronger in some areas than others. The value of the framework is that it identifies which foundational capabilities must exist before later-stage practices can take hold reliably.

Stage 0: Build the Foundation

Everything begins here. Development and operations teams are starting to recognise the importance of collaboration and shared responsibility. The primary activity at this stage is rapidly putting in place the mechanisms that enable sharing: shared metrics, shared knowledge bases, common communication channels, and early cross-functional processes.

This stage is deceptively important. Skipping or rushing through it tends to produce DevOps initiatives that look good on paper but collapse under the weight of cultural friction later on. The health of a mature DevOps organisation is directly proportional to how solid this foundation is.

Key focus areas: cross-team communication, shared visibility into metrics, early process documentation, and establishing psychological safety for experimentation.

Stage 1: Normalise the Technology Stack

At Stage 1, development teams begin adopting more disciplined engineering practices. The most significant marker is the adoption of version control — a prerequisite for everything that comes later, including continuous integration and continuous delivery. Teams may also begin moving toward agile development methods, either through a coordinated organisational initiative or organically, team by team.

On the operations side, the focus is on beginning to rationalise the technology landscape: identifying redundant systems and starting to reduce the sprawl of operating systems, runtimes, and deployment mechanisms that accumulated over years of ungoverned growth.

Key focus areas: universal version control adoption, introduction of CI tooling, initial tech stack rationalisation, and early agile practices.

Stage 2: Standardise and Reduce Variability

Stage 2 extends the rationalisation effort that began in Stage 1. Both development and operations teams work in parallel to drive down variance across the entire system. This typically means converging on a single operating system or OS family, and standardising the core components of the application stack: databases, message queues, key-value stores, identity providers, and similar infrastructure primitives.

The business impact is concrete. When every team builds on the same approved patterns, new applications and services can be deployed faster because the underlying infrastructure is already well understood. Errors that stem from environment inconsistency — the classic “works on my machine” category — are significantly reduced. Critically, as shared patterns mature and improve, the quality improvement is multiplied across every service that uses them.

Key focus areas: OS standardisation, approved component libraries, elimination of one-off configurations, and shared deployment patterns.

Stage 3: Expand DevOps Practices

With a stable, well-understood technical foundation in place, organisations can now address higher-order pain points. At Stage 3, teams systematically reuse proven deployment patterns rather than building one-off pipelines for each project. Equally important: infrastructure changes are tested before being applied to production environments — a shift that significantly improves reliability and reduces the blast radius of configuration errors.

These practices build trust — both within teams and between development and operations. And trust, according to Puppet’s research, is the prerequisite for the deeper cultural changes that enable DevOps to scale. Without demonstrated reliability, there is no appetite for the autonomy that characterises high-performing DevOps organisations.

Key focus areas: reusable pipeline templates, infrastructure testing (e.g., using tools like Test Kitchen, Serverspec, or InSpec), pre-production validation gates, and cross-team pattern libraries.

Stage 4: Automate Infrastructure Delivery

Stage 4 is where many organisations set their sights when they first launch a DevOps programme — but Puppet’s model makes clear that reaching it requires the groundwork laid in earlier stages. At this point, the automation of system configuration and provisioning becomes the norm rather than the exception. Infrastructure-as-code practices are mature enough that teams can spin up consistent, compliant environments reliably and repeatedly.

Self-service provisioning begins to emerge here, enabling multiple departments to provision resources without opening tickets and waiting for manual intervention. The operational efficiency gains are significant, as is the reduction in toil for infrastructure teams.

Key focus areas: infrastructure-as-code at scale (e.g., Puppet, Ansible, Terraform), automated provisioning pipelines, configuration drift detection, and early self-service workflows.

Stage 5: Provide Self-Service Capabilities

Stage 5 represents the cumulative payoff of everything built in the preceding stages. At this level of maturity, resources are available on demand through self-service interfaces. Incident response is largely automated — alert, diagnose, and remediate workflows operate without requiring manual handoffs at every step.

Crucially, Puppet’s report emphasises that automation at this stage is purposeful. High-performing teams don’t automate for its own sake; they automate to give the entire organisation — not just IT — the ability to operate with greater speed, efficiency, and precision. The engineering investment pays dividends across every business unit that depends on software and infrastructure.

Key focus areas: internal developer platforms, self-service provisioning portals, automated incident remediation, and organisation-wide reliability engineering practices.

Why the Staged Model Matters

One of the most practical insights from Puppet’s 2018 report is that DevOps failure is rarely about the wrong tools — it is almost always about attempting later-stage practices before the earlier-stage foundations are solid. Organisations that jump straight to infrastructure automation without standardising their stack, or that roll out self-service before establishing trust between teams, tend to create fragile systems that amplify existing dysfunction rather than resolving it.

The model is also a useful diagnostic. If a team is struggling to scale DevOps beyond a few pioneering squads, mapping current practices against the five stages can quickly surface which foundational capabilities are missing — whether that is inconsistent version control adoption, untested infrastructure changes, or an absence of shared deployment patterns.

Takeaways for DevOps Teams

• Start with culture and visibility before investing heavily in tooling. Stage 0 is not optional.
• Version control is non-negotiable at Stage 1 and is the gateway to every subsequent automation practice.
• Standardisation reduces complexity in ways that compound over time — every team benefits when shared patterns improve.
• Test infrastructure changes before production as rigorously as you test application code.
• Automate with purpose — the goal is organisational efficiency, not automation for its own sake.
• Self-service is an outcome of mature automation, not a starting point.

For organisations assessing where they stand, Puppet’s staged framework provides a structured way to identify gaps, prioritise investments, and set realistic expectations about the time and effort required to reach the higher stages of DevOps maturity.

Two Trends, One Strategy

Cloud computing and DevOps did not emerge in isolation. Both matured during roughly the same period, and both were driven by the same underlying pressure: the need for organizations to deliver software faster, more reliably, and at lower cost. It is therefore worth asking whether the value of each approach can really be measured independently — or whether the two are fundamentally intertwined.

The answer, supported by multiple industry research efforts, is that cloud and DevOps amplify each other. Organizations that combine both at a mature level consistently outperform those that rely on only one.

What the Research Says

DevOps Research

The 2017 State of DevOps Report, published by DORA (DevOps Research and Assessment) and Puppet Labs, documented the measurable advantages high-performing DevOps organizations enjoy over their lower-performing peers. Key themes included the value of automation, the cross-industry applicability of DevOps practices, and the cultural changes required to sustain them.

Separately, research commissioned by CA Technologies and conducted by Coleman Parkes examined what happens when agile software development methodologies are combined with DevOps practices. According to that study, organizations that adopted both reported a 41% increase in operational efficiency and a 63% better probability of winning new business.

Cloud Research

Cisco’s Global Cloud Index has tracked the growth of cloud computing and the traffic it generates on an annual basis. RightScale’s State of the Cloud Report (at the time of the original article’s publication) found that 58% of enterprises had adopted a hybrid cloud strategy — reflecting how mainstream cloud adoption had become even by 2017.

Despite this volume of research, most studies examined cloud and DevOps separately. The combined effect of using both together was less thoroughly explored — which is what made the CA/FreeForm Dynamics study described below notable.

Real-World Examples: Spotify and Netflix

Two of the most frequently cited DevOps success stories — Spotify and Netflix — are also standout examples of effective cloud adoption. This is not a coincidence.

Spotify’s Organizational Model

Spotify’s engineering culture became widely studied for its use of autonomous, cross-functional teams organized into Squads, grouped into Tribes, with horizontal coordination through Chapters and Guilds. This structure was designed to enable rapid, independent delivery while maintaining consistency — core DevOps goals. Spotify’s product itself is cloud-delivered, using cloud infrastructure to power its personalized music streaming at global scale.

Netflix’s Chaos Engineering

Netflix pioneered the concept of Chaos Engineering through its Chaos Monkey tool, which deliberately introduced random failures into production systems to test their resilience. This eventually evolved into the broader Simian Army — a suite of tools that inject various failure conditions, latency issues, and configuration problems to surface weaknesses before they cause user-facing outages.

This practice of continuous, automated failure testing aligns directly with DevOps principles: tight feedback loops, shared responsibility between development and operations, and a relentless focus on reliability and user experience. Netflix runs this infrastructure entirely in the cloud, making cloud elasticity central to the approach.

The Combined-Effect Study: CA and FreeForm Dynamics

To move beyond anecdote and measure the combined effect of cloud and DevOps at scale, CA Technologies commissioned FreeForm Dynamics to survey approximately 1,000 IT professionals worldwide. Respondents were asked to self-assess the maturity of their organization’s use of both cloud and DevOps, then grouped into four categories:

• Slow Movers (48%): Not advanced users of either cloud or DevOps. They may be using both, but at an early or inconsistent level.
• DevOps Devotees (15%): Advanced DevOps adopters who had not yet matured their cloud usage to the same degree.
• Cloud Champions (17%): Organizations running mature cloud operations but with less sophisticated DevOps practices.
• Delivery Disrupters (18%): Advanced users of both DevOps and cloud computing simultaneously.

Software Delivery Performance Results

The study evaluated all groups against a composite software delivery performance metric, combining five dimensions: speed, quality, predictability, user experience, and cost control.

The results were clear:

• Delivery Disrupters (cloud + DevOps together) saw an 81% improvement in overall software delivery performance.
• DevOps Devotees saw a 52% improvement.
• Cloud Champions saw a 53% improvement.

The gap between using one technology well and using both together was substantial — nearly 30 percentage points of improvement in overall software delivery performance.

Why Cloud and DevOps Reinforce Each Other

The synergy between cloud and DevOps is not accidental. Each addresses limitations that the other introduces:

• Elasticity enables continuous delivery: Cloud infrastructure can be provisioned and torn down programmatically, which makes it practical to spin up isolated environments for testing, staging, and deployment — foundational to CI/CD pipelines.
• DevOps makes cloud manageable: Without automation, monitoring, and shared operational ownership — all DevOps practices — cloud environments can quickly become sprawling and expensive. DevOps disciplines bring governance and predictability to dynamic cloud resources.
• Infrastructure as Code (IaC): Tools like Terraform, Ansible, and AWS CloudFormation allow teams to define and version infrastructure the same way they manage application code — a practice that requires both cloud APIs and DevOps workflows to be effective.
• Faster feedback loops: Cloud platforms provide on-demand compute for automated testing and monitoring. DevOps teams use this to shorten the time between a code commit and validated, production-ready software.

Key Takeaways for Engineering Teams

Whether your organization is just beginning its DevOps journey, maturing its cloud strategy, or trying to figure out how to integrate both, the evidence points in one direction: treat cloud and DevOps as a unified strategy, not separate initiatives.

• Assess maturity in both areas independently — gaps in one will limit the returns from the other.
• Prioritize automation across both cloud provisioning and software delivery pipelines.
• Use cloud-native tooling (managed Kubernetes, serverless functions, cloud build services) alongside DevOps practices rather than treating them as separate tool stacks.
• Measure performance with composite metrics that cover speed, quality, cost, and user experience — not deployment frequency alone.
• You do not need to be Netflix or Spotify to benefit. The FreeForm Dynamics research found improvements across organizations of all sizes and geographies.

The cloud provides the platform. DevOps provides the practices. Together, they provide the foundation for competitive software delivery at scale.

Overview: What the 2017 State of DevOps Report Found

The 2017 State of DevOps Report, produced by Puppet in partnership with DevOps Research and Assessment (DORA) and co-sponsored by AWS, Hewlett-Packard Enterprise, Deloitte, Atlassian, Electric Cloud, Splunk, and Wavefront, surveyed approximately 3,200 professionals to understand what separates high-performing IT organizations from their lower-performing counterparts. The central finding: automation is the defining characteristic of top performers, and the gap between high and low performers is widening.

The Automation Gap Is Growing

According to the report, high-performing organizations have automated 72% of all configuration management processes. This means engineers in these organizations spend significantly less time on manual configuration, delivery, and operations work.

By contrast, low-performing organizations spend close to 46% of their time on manual configuration and related activities — time that could otherwise go toward building features, reducing technical debt, or responding to customer needs.

Nigel Kersten, chief technical strategist at Puppet, framed the problem this way in the report:

“The results of the 2017 State of DevOps Report show that high-performing IT teams are deploying more frequently and recovering faster than ever before, yet the automation gap between high and low performing teams continues to grow. The report will help organizations understand how to identify their own inhibitors and embrace change on their DevOps journey.”

Nigel Kersten, Chief Technical Strategist, Puppet

Performance Metrics: How High Performers Compare

The report quantified the performance differential between high and low performers across four key DevOps metrics:

• Deployment frequency: High performers deploy 46x more frequently than low performers.
• Lead time for changes: High performers achieve 440x faster lead time from code commit to production.
• Mean time to recover (MTTR): High performers recover from incidents 96x faster on average.
• Change failure rate: High performers experience 5x fewer change failures.

The report also found that high-performing organizations were more than twice as likely to report higher quality and quantity of products and services, better operating efficiency, and higher customer satisfaction compared to low performers.

Leadership Is a Critical Factor

The report did not focus solely on tooling and automation. Leadership quality emerged as a significant differentiator for organizations undergoing digital transformation. Among the 3,200 respondents, high-performing organizations were associated with leaders who demonstrated:

• Strong vision
• Inspirational communication
• Intellectual stimulation
• Supportive leadership styles
• Personal recognition of team members

Organizations where these leadership traits were less prevalent tended to be lower performers. This finding reinforces a broader pattern in DevOps research: cultural and organizational factors are as important as technical practices.

Sanjay Mirchandani, CEO of Puppet, summarized the business case for automation and strong leadership:

“By adopting automation and DevOps, our customers have cut software deployment times from months to days, eliminated virtually all configuration errors and most importantly, helped their businesses to become top performers.”

Sanjay Mirchandani, CEO, Puppet

Lean Product Management Accelerates Feedback Loops

For the second consecutive year, the report examined how product management practices upstream affect business outcomes downstream. The finding was consistent: lean product management practices help teams ship features that customers actually want, more frequently.

Faster delivery cycles, in turn, accelerate customer feedback — creating a virtuous loop where teams can validate assumptions, course-correct quickly, and avoid building large amounts of unwanted functionality. This is a core principle of both Lean and Agile development philosophies, and the report’s data provides empirical support for its business value.

Connecting Business Metrics to DevOps Tooling

Steve Brodie, CEO of Electric Cloud (one of the report’s sponsors), highlighted a critical but often overlooked takeaway: the importance of connecting business-level metrics with the tools and processes driving product innovation.

“Electric Cloud’s goal is to enhance visibility and collaboration across DevOps initiatives by helping to automate, orchestrate and analyze all the tools and data sources associated with software pipelines and application releases.”

Steve Brodie, CEO, Electric Cloud

Many organizations adopt DevOps tooling without establishing clear visibility into how those tools affect business outcomes. The report argues that organizations need traceability from pipeline activity all the way through to customer and revenue impact.

Velocity Remains a Core DevOps Metric

The 2017 report reaffirms what earlier editions established: velocity is not just a vanity metric — it is directly tied to business outcomes. Organizations that move faster suffer fewer failures, recover more quickly when problems occur, and are better positioned to respond to market changes. The data supports a counterintuitive conclusion: moving fast, when underpinned by automation and good engineering practice, actually reduces risk rather than increasing it.

Ashish Kuthiala, senior director for DevOps and agile offerings at HPE, reinforced the practical implications:

“At the heart of successful businesses are high-performing teams that evolve and incorporate modern, high-performing applications and processes to drive consistent growth.”

Ashish Kuthiala, Senior Director, DevOps and Agile, HPE

Key Takeaways for DevOps Practitioners

• Automate configuration management aggressively. High performers have automated 72% of these processes. If your team is still manually configuring environments or deployments, this is likely your biggest productivity drag.
• Measure what matters. Track deployment frequency, lead time, MTTR, and change failure rate. These four metrics (now formalized in the DORA framework) are reliable indicators of overall DevOps health.
• Invest in leadership development alongside tooling. Tools alone do not create high-performing teams. Leadership quality, communication style, and recognition practices matter.
• Adopt lean product management. Short feedback loops between engineering and customers improve product quality and reduce wasted development effort.
• Connect pipeline data to business outcomes. Visibility across the entire software delivery chain — from commit to customer — is essential for making informed investment decisions.

The 2017 State of DevOps Report was produced by Puppet in partnership with DORA. The statistics cited in this article are drawn from reporting on that report. Readers seeking the full methodology and data should consult Puppet’s official publications.

1. Automation Remains the Single Biggest Differentiator

Automation has always been a cornerstone of DevOps practice, but the 2017 report reinforced its status as a key differentiator between high and low performing organizations. High performers automate significantly more of their software delivery pipeline — configuration management, testing, deployments, and change approvals — than their lower-performing counterparts who still rely heavily on manual processes.

The report highlights two primary outcomes of widespread automation:

1. Accelerated feedback loops — Faster, automated testing and integration cycles surface defects earlier, improving both product quality and release cadence.
2. More engineering time for valuable work — When teams stop manually provisioning servers or shepherding change-approval tickets, they redirect that energy toward product development.

There is a third, often overlooked, benefit worth calling out explicitly: automation is auditing. Automated pipelines are inherently consistent, repeatable, and loggable. Every build, test cycle, deployment, and release generates structured logs automatically. Over time, this log trail becomes your audit record, your security event log, and your compliance evidence — produced as a natural by-product of doing the work, not as a separate overhead task.

2. Connect Your Automation Dots — End to End

Many enterprises have already made progress on automation, but typically in isolated pockets: one team automates deployments, another automates testing, a third automates infrastructure provisioning. These silos of automation deliver local value but limit organisation-wide benefit.

The 2017 report underscores the importance of moving from disconnected automation islands to an integrated, end-to-end delivery pipeline. Connecting your toolchain — from development and testing through operations, security, and business metrics — is how DevOps scales beyond individual teams.

This does not mean forcing every team onto a single tool. Teams can and should retain the freedom to choose the best tool for their specific job. What matters is the ability to orchestrate and integrate those tools so they feed into a shared pipeline. That shared pipeline provides visibility, governance, and traceability across the entire value stream — something no collection of isolated tools can achieve on its own.

3. Are You Just Releasing Bad Code Faster?

One of the most striking findings in the 2017 report is the diverging performance profile between high and low performers when it comes to throughput versus stability.

The headline numbers for high performers are significant:

• 46× more frequent deployments than low performers
• 440× faster lead time from commit to deploy (roughly one hour versus one week to one month)
• 96× faster mean time to recovery (MTTR) from downtime
• 5× lower change failure rate

What is particularly telling is how the gap has shifted since 2016. Low performers did improve their deployment frequency — moving from roughly once per month to once every six months in 2016, up to once per week to once per month in 2017. That is genuine progress on throughput. However, the stability gap simultaneously widened. In 2016, high performers recovered from outages 24× faster than low performers. By 2017, that gap had grown to 96×. The change failure rate gap also grew, from 3× to 5×.

The pattern is clear: low performers invested in shipping faster but did not invest proportionally in testing, quality gates, and reliability practices. The result is faster delivery of lower-quality software. Speed without quality is not a DevOps win. Shifting testing, monitoring, and security checks left — earlier in the pipeline — is essential to ensure that deploying more frequently also means deploying more reliably.

4. De-coupling Is the Architecture Strategy That Enables Continuous Delivery

The 2017 data confirms that Continuous Delivery (CD) significantly reduces deployment pain and correlates strongly with higher IT performance. More importantly, the report identifies the architectural preconditions that make CD possible at scale.

The strongest predictors of Continuous Delivery success are:

• Lean, autonomous, empowered teams that can make decisions without extensive cross-team coordination
• Loosely coupled services that can be developed, tested, and deployed independently of one another

This applies both at the organisational level (team topology) and the technical level (system architecture). When services and teams are tightly coupled, every change requires synchronisation across multiple groups, creating bottlenecks that undermine deployment frequency and increase risk.

Many enterprises are actively decomposing monolithic applications into microservices or service-oriented architectures, adopting containers, and restructuring teams to match. However, these are not overnight transformations. Most large organisations operate in a hybrid state simultaneously — supporting legacy monoliths alongside modern microservices, virtual machines alongside containers, traditional release processes alongside CD pipelines. The practical challenge is ensuring your tooling and platform strategy can accommodate this hybrid reality rather than forcing a premature or disruptive all-or-nothing migration.

5. Transformational Leadership Has a Measurable Impact on DevOps Performance

DevOps transformations succeed or fail based in large part on the quality of leadership supporting them. The 2017 report draws on the Rafferty and Griffin Transformational Leadership model to define five leadership characteristics that correlate most strongly with high IT performance:

1. Vision — A clear, credible picture of where the organisation is heading
2. Inspirational communication — Motivating teams through consistent, compelling messaging
3. Intellectual stimulation — Encouraging curiosity, experimentation, and learning
4. Supportive leadership — Removing blockers and advocating for team needs
5. Personal recognition — Acknowledging individual and team contributions meaningfully

The report finds that high, medium, and low performing organisations show statistically significant differences across these five dimensions. In other words, leadership quality is not just a cultural nicety — it is a measurable variable in IT performance outcomes.

For practitioners, this data provides two concrete actions:

1. Assess your leadership against these five dimensions to identify specific gaps that may be limiting your DevOps progress.
2. Invest intentionally in leadership development — coaching, mentoring, and organisational design choices — focused on these demonstrable, measurable characteristics rather than on abstract culture statements.

The Overarching Message

The 2017 State of DevOps Report is consistent with prior years in confirming that high performers do not achieve their results by accident. They automate broadly and deliberately, connect their toolchains into coherent pipelines, invest equally in stability and throughput, architect for independence, and cultivate leadership that actively enables their teams. Low performers who focus exclusively on shipping faster — without building quality, reliability, and architectural flexibility into their foundation — are not closing the gap. They are widening it.

Original analysis sourced from news.sys-con.com commentary on the 2017 Puppet / DORA State of DevOps Report.

The ‘findings’ this year suggest that, as we have hinted more than once recently, the crucial bridge to the new efficiencies in software application development shops come from automation.

Puppet says that the highest performing organisations have automated as much as 72 percent of all configuration management processes.

Leadership as a DevOps Performance Driver

The 2017 State of DevOps Report, compiled annually by software automation vendor Puppet and DevOps Research and Assessment (DORA), draws on responses from more than 3,200 DevOps practitioners worldwide. Among its most significant findings: the behaviour and communication style of senior leaders is a powerful predictor of whether an organisation will become a high-performing DevOps team.

The report identifies five characteristics that high-performing DevOps leaders tend to share. Effective leaders are described as:

• Inspirational — they motivate teams around a shared purpose.
• Communicative — they keep engineers informed and aligned.
• Visionary — they articulate a clear direction for technology transformation.
• Supportive — they remove obstacles and provide cover for teams taking calculated risks.
• Recognition-focused — they actively acknowledge and reward good work.

The report found a direct correlation between these leadership traits and team performance: “Low-performing teams reported the lowest levels of these traits, and teams that reported the least transformative leaders were half as likely to be high-performers.”

Why Senior Sponsorship Is Non-Negotiable

One recurring theme in DevOps adoption is the grassroots transformation narrative—engineers quietly improving pipelines and practices without top-down mandates. The 2017 report acknowledges this happens, but argues it is the exception rather than the rule.

According to the report: “Leaders have the authority and budget to make the large-scale changes often needed; to provide visible support when a transformation is under way; and to change the incentives of entire groups of engineers, whether they are in development, quality assurance, operations or information security.”

The practical implication is significant. A senior leader can restructure team incentives, fund tooling investments, and publicly endorse cultural changes in ways that individual contributors simply cannot. Without that sponsorship, DevOps initiatives frequently stall at the team or department level and fail to scale.

Gene Kim, co-author of The DevOps Handbook and DORA general partner, summarised the finding at the DevOps Enterprise Summit in London in June 2017: “Leadership matters and it matters even more than we initially thought. It turns out that leadership significantly amplifies the ability for organisations to become high-performers.”

The Widening Gap Between High and Low Performers

The 2017 report also examined how high- and low-performing teams compare on two core software delivery metrics: throughput (deployment frequency and lead time for changes) and stability (change failure rate and mean time to restore service).

On throughput, the gap between the two groups had narrowed compared to the 2016 edition—low-performing teams were deploying more frequently. However, this improvement came at a cost: their stability metrics had deteriorated. High-performing teams, by contrast, continued to improve on both dimensions simultaneously.

DORA co-founder Nicole Forsgren explained the dynamic: “With the low-performers, this is the first time we are seeing evidence of these trade-offs, where they are trying to get this throughput, but at the expense of stability. And it’s not working very well at all.”

The key insight the report draws from this data is that the speed-versus-stability trade-off is not inherent to software delivery—it is a symptom of immature DevOps practice. Well-implemented DevOps eliminates the trade-off entirely: “If you are doing DevOps well, you are able to get this throughput and stability together. Trade-offs are not necessary. You can have it all.”

DevOps Benefits Extend Beyond Financial Performance

Now in its sixth annual edition at the time of publication, the State of DevOps Report continued to expand its definition of organisational success beyond traditional financial metrics. The 2017 data found that high-performing organisations were twice as likely to meet or exceed goals across a broader range of business outcomes, including:

• Operational efficiency
• Customer satisfaction
• Corporate social responsibility objectives
• Product and service quality and quantity targets

Critically, this held true for both for-profit and not-for-profit organisations. The report concluded: “This suggests that DevOps enables mission achievement for any type of organisation, independent of industry or sector.”

Technology Stack Is Not the Deciding Factor

A common assumption in DevOps discussions is that modern cloud-native tooling is a prerequisite for transformation. The 2017 report pushed back on that notion. DORA CTO Jez Humble, also a co-author of the DevOps Handbook, pointed to his own experience working with legacy systems inside the US federal government as evidence that DevOps practices can succeed in heavily regulated, technically complex environments.

Humble also issued a pointed warning in the other direction: “Just because you’re working in a new environment with shiny technology, you can still end up with a horrible, big-bang, orchestrated deployment that happens to be on Kubernetes.”

The implication is clear: tooling choices matter far less than cultural and organisational practices. Adopting containers, microservices, or any other modern technology does not automatically confer DevOps maturity. Leadership, communication, and disciplined engineering practices remain the primary levers.

Key Takeaways for DevOps Leaders

• Invest in leadership development. Technical training alone is insufficient. Leaders who demonstrate transformational behaviours—communication, vision, recognition—directly improve team performance outcomes.
• Don’t accept the speed-stability trade-off. If your team is shipping faster but breaking more, your DevOps implementation needs attention. High performers achieve both simultaneously.
• Measure beyond deployment metrics. Customer satisfaction, operational efficiency, and mission outcomes are all valid and measurable indicators of DevOps maturity.
• Environment is not an excuse. Legacy systems, regulated industries, and complex architectures are not barriers to DevOps success—they require the same cultural and leadership fundamentals as any other context.
• Modern tooling is not a substitute for practice. Running workloads on Kubernetes does not make deployments safer or faster on its own. Discipline and culture drive outcomes.

The 2017 State of DevOps Report was produced by Puppet and DORA. Original reporting on the DevOps Enterprise Summit London 2017 presentation was published by Computer Weekly.