The Quality Metrics Problem in DevOps

Software delivery has been radically reshaped by DevOps — shorter release cycles, microservices, CI/CD pipelines, cross-functional teams — yet the quality metrics most organisations rely on have barely changed. Many were designed for waterfall-era release schedules and manual testing workflows. Applying them to a continuous delivery pipeline can obscure more than they reveal.

Every other part of the delivery process has been examined and optimised for speed and reliability. Quality measurement deserves the same scrutiny. The core question is: which metrics actually tell you whether a release candidate carries an acceptable level of risk, and which ones are just historical baggage?

The Research Methodology

To answer this question, Tricentis commissioned Forrester to study which of 75 quality metrics matter most for DevOps success. The methodology proceeded in five steps:

1. Survey scope: 603 global enterprise leaders responsible for DevOps strategy were surveyed.
2. Identify high performers: From those 603 respondents, 157 met Forrester’s criteria for mature and successful DevOps adoption. These are referred to as “DevOps experts” or “DevOps leaders” throughout the research.
3. Measure usage and value: Experts reported which metrics they regularly measure and how highly they rated each one’s value.
4. Rank each metric: Each of the 75 metrics was scored on two axes — usage frequency and perceived value — to produce heat maps and quadrant charts.
5. Identify differentiators: Metrics where DevOps leaders measured significantly more than DevOps laggards were flagged as “DevOps differentiators.”

The Four Categories of Quality Metrics

The 75 metrics were grouped into four stages of the delivery pipeline:

• Build — metrics captured during code compilation, static analysis, and unit testing.
• Functional Validation (FV) — metrics that assess whether individual features behave as specified.
• Integration Testing (IT) — metrics focused on how components and APIs interact.
• End-to-End Regression Testing (E2E) — metrics that verify full system behaviour before release.

Understanding the Quadrant Framework

For each category, Forrester plotted metrics on a quadrant with usage on one axis and value on the other, producing four segments:

• Value Added: Used frequently and consistently rated as valuable. These are your core DevOps quality indicators.
• Hidden Gem: Not used frequently, but rated as highly valuable by the teams that do use them. These represent the biggest opportunity for improvement.
• Overrated: Used frequently but not rated as particularly valuable by teams that measure them. Worth reconsidering whether they earn their overhead.
• Distraction: Low usage and low value. Candidates for removal from your reporting dashboards entirely.

This quadrant model is useful beyond the specific research findings — it provides a reusable lens for auditing any set of metrics your team currently tracks.

Hidden Gems: High Value, Low Adoption

The following metrics are not commonly used — even among DevOps experts — but are ranked as extremely valuable by the teams that do measure them. These represent the strongest opportunity to improve your quality signal without dramatically increasing measurement overhead:

• New defects (Integration Testing)
• Critical defects (Functional Validation)
• Automated tests prioritised by risk (Build)
• Code coverage (Build)
• Test cases executed (Build)
• Static analysis results (Build)
• Variance from baselines of percent of test cases passed (End-to-End)
• Release readiness (End-to-End)

The strong showing of Build-stage metrics here is notable. Risk-prioritised automated tests and static analysis results both appear as hidden gems, suggesting many teams are missing early quality signals that could reduce downstream defects and rework.

Top DevOps Differentiators

These are the metrics that DevOps leaders measure significantly more than DevOps laggards. If you want to understand what separates high-performing DevOps organisations from average ones, this list is a strong starting point:

• Automated tests prioritised by risk (Build)
• Percent of automated E2E test cases (End-to-End)
• Risk coverage (Integration Testing)
• Release readiness (Functional Validation, Integration Testing, End-to-End)
• Test efficiency (Functional Validation, Integration Testing)
• Requirements covered by tests (Build, Functional Validation, Integration Testing, End-to-End)
• Test case coverage (Build, End-to-End)
• Static analysis results (Build)
• Variance from baseline of percent of test cases passed (End-to-End)
• Test effectiveness (Functional Validation, Integration Testing, End-to-End)

Several themes emerge here. Risk-based thinking — tracking risk coverage, release readiness, and risk-prioritised test automation — distinguishes mature DevOps programmes from those still measuring activity rather than outcomes. Requirements traceability across all four pipeline stages also appears repeatedly, suggesting that linking tests back to business requirements is a hallmark of high-performing teams.

Most Used Metrics by DevOps Experts

These are the metrics most frequently tracked overall by DevOps leaders, ranked by usage:

1. Test case coverage (End-to-End)
2. Pass/fail rate (Functional Validation)
3. API pass/fail rate (Integration Testing)
4. Number of tests executed (End-to-End)
5. API bug density (Integration Testing)
6. Requirements covered by tests (Functional Validation)
7. Requirements covered by tests (End-to-End)
8. Blocked test cases (Functional Validation)
9. Percent of automated E2E test cases (End-to-End)
10. Successful code builds (Build)

The presence of API-specific metrics (API pass/fail rate, API bug density) in the most-used list reflects the shift toward microservices and API-driven architectures. Teams that have adopted these patterns clearly feel the need to instrument their integration layer more carefully.

Most Valued Metrics by DevOps Experts

Usage frequency and perceived value do not always align. These are the metrics rated most highly by the DevOps experts who track them — in other words, the metrics teams consider most worth the effort:

1. Requirements covered by API tests (Integration Testing)
2. Percent of automated E2E tests (End-to-End)
3. Requirements covered by tests (End-to-End)
4. Requirements covered by tests (Functional Validation)
5. Count of critical functional defects (Functional Validation)
6. Total number of defects discovered in test (End-to-End)
7. Number of test cases executed (End-to-End)
8. Pass/fail rate (Functional Validation)
9. New API defects found (Integration Testing)
10. Automated tests prioritised by risk (Build)

Requirements traceability dominates the most-valued list, appearing in three separate entries across different pipeline stages. This strongly suggests that the ability to answer “does this release satisfy our stated requirements?” is the quality question DevOps leaders care most about — not just whether the build passed.

Practical Takeaways for DevOps Teams

The research surfaces several actionable conclusions for teams looking to improve their quality measurement practices:

• Audit your current metrics against the quadrant model. Are you spending time collecting metrics that fall into the “Overrated” or “Distraction” quadrants? Reallocating that effort toward hidden gems could improve decision quality with little additional cost.
• Adopt risk-based thinking early. Automated tests prioritised by risk and risk coverage both appear as differentiators and hidden gems. Shifting left on risk assessment — rather than treating all tests equally — is a characteristic of mature DevOps quality programmes.
• Track release readiness as a first-class metric. It appears as both a hidden gem and a differentiator across multiple pipeline stages. If you cannot answer “is this release candidate ready?” with a single data point, you likely lack this metric in a usable form.
• Instrument your API layer. API-specific metrics appear in both the most-used and most-valued lists, reflecting the increasing centrality of service integration to application quality.
• Connect tests to requirements. Requirements traceability is the single most consistent theme across both the differentiator list and the most-valued list. If your test results cannot be mapped back to business requirements, you are missing a critical quality signal.

Where to Go Deeper

The full analysis — including heat maps and quadrant charts for all four pipeline stages, per-metric breakdowns, and the complete ranking of all 75 metrics — was published in an eBook titled “Forrester Research on DevOps Quality Metrics that Matter: 75 Common Metrics — Ranked by Industry Experts,” produced by Tricentis. The original coverage appeared on devops.com. Readers seeking the full dataset and visualisations should search for the eBook directly on the Tricentis or Forrester websites.

The Real Risk of Measuring the Wrong Things

The story of a large retailer’s decline offers a cautionary tale for engineering teams: obsessing over internal operational metrics while losing sight of what customers actually need can be fatal. Optimising server response times, reducing ticket queues, and improving internal deployment pipelines are all valuable — but only if they translate into tangible improvements for the people your software serves.

This tension between internal efficiency metrics and external customer outcomes sits at the heart of one of the most persistent challenges in DevOps: knowing what success actually looks like.

The Survey Data: DevOps Teams Are Looking Inward

According to a February 2018 survey conducted by Interop ITX and InformationWeek of approximately 150 technology professionals:

• 49% of respondents said they measure DevOps success primarily through internal factors — lower costs, fewer application defects, improved application performance, better ROI, improved efficiencies, and better cross-department collaboration. This figure was up from 35% in 2017.
• Only 29% of respondents primarily measured success using external business factors such as increased revenue, faster time-to-market, improved competitive positioning, and enhanced customer experience — down one percentage point from 2017.

The trend is moving in the wrong direction. More teams are turning inward at a time when the competitive landscape demands a sharper focus on customer-facing outcomes.

Why This Is a Problem: Expert Perspectives

Andi Mann, Chief Technology Advocate for Splunk at the time, described the survey findings as “disturbing.”

“Looking at how modern businesses are disrupting enterprises, it’s about delivering services. As a customer, I don’t care about server response time — I care about how quickly I get a movie.”

Andi Mann, Chief Technology Advocate, Splunk

The point is critical. Internal metrics such as deployment pipeline speed or mean defect rates are useful engineering signals, but they are proxies. The ultimate goal of any DevOps initiative is to deliver better, faster, more reliable value to customers. If your metrics don’t trace back to that goal, you risk optimising for the wrong outcomes entirely.

The Four Metrics That Actually Matter

Robert Reeves, co-founder and CTO of Datical (now Liquibase), pointed to the DevOps Research and Assessment (DORA) framework as the industry-standard approach for measuring DevOps performance in a way that connects engineering work to business results. The four DORA metrics are:

1. Deployment frequency — How often does your team successfully release to production? Higher frequency indicates a healthier, lower-risk delivery pipeline.
2. Lead time for changes — How long does it take for a commit to reach production? Shorter lead times mean faster delivery of value to customers.
3. Mean time to recovery (MTTR) — When a failure occurs, how quickly can your team restore service? This directly affects the customer experience during incidents.
4. Change failure rate — What percentage of changes result in a degraded service or require remediation? Lower rates signal higher-quality deployments.

These four metrics have become the de facto standard for high-performing engineering organisations because they measure outcomes rather than activity. A team can merge hundreds of pull requests a week and still score poorly on lead time or change failure rate — activity alone tells you nothing about delivery quality.

Why Teams Default to Internal Metrics: The Silo Problem

Mann identified organisational silos as the root cause of inward-facing measurement. Historically, IT operations teams were not directly tied to business outcomes — they were measured on uptime, ticket resolution, and infrastructure costs. DevOps is designed to break down those walls, but the cultural change takes time.

“A lot of organisations are still in these functional silos. They measure what they can directly affect, and unfortunately those silos can’t affect outcomes.”

Andi Mann, Splunk

A separate survey conducted by Micro Focus on enterprise DevOps adoption found that 50% of respondents identified IT silos as a major impediment to application development. When teams are siloed, they naturally optimise for the slice of the value stream they control — even if that slice doesn’t correspond to anything a customer cares about.

Leverage Your Toolchain Data

Rosalind Radcliffe, a Distinguished Engineer at IBM, noted that many of the tools already used in a DevOps transformation naturally generate the data needed to populate meaningful metrics. CI/CD pipelines, incident management platforms, deployment trackers, and observability tools all produce signals that can feed directly into DORA-style measurement.

“Many of the tools that people adopt as part of their DevOps transformation help generate data that can help drive numbers into these metrics.”

Rosalind Radcliffe, Distinguished Engineer, IBM

The implication is practical: you probably don’t need to build new measurement infrastructure from scratch. Audit the data your existing tools produce and map it to the metrics that matter. Tools like GitHub, GitLab, Jira, PagerDuty, and purpose-built DORA dashboards (such as those offered by Google Cloud’s DevOps Research capabilities) can surface these numbers with relatively little additional configuration.

Who Is Responsible for Tracking DevOps Success Metrics?

Knowing what to measure is only part of the challenge — someone needs to own the measurement and act on it. Mann’s guidance here varies by organisation size:

• In larger organisations: The head of application development, a Project Management Office (PMO), or a dedicated project manager for application development should be accountable for evaluating the DevOps team’s value stream and success metrics.
• In smaller organisations: A Scrum Master or engineering lead can take on responsibility for tracking and communicating DevOps success metrics.

Mann’s broader point is that everyone on the team should care about these outcomes — but without a clear owner, metrics tend to get reviewed infrequently and acted on even less often.

Practical Steps to Reorient Your DevOps Metrics

1. Audit your current metrics. List everything your team currently tracks. Categorise each metric as internal (efficiency, cost, defect rates) or external (customer experience, revenue impact, time-to-market).
2. Implement the four DORA metrics. If you’re not already tracking deployment frequency, lead time for changes, MTTR, and change failure rate, start now. Most CI/CD and incident management tools can supply this data.
3. Connect metrics to customer outcomes. For each DORA metric, document a direct line to a customer experience impact. For example: lower MTTR → shorter outage windows → fewer customers affected by downtime.
4. Assign ownership. Designate a specific role — PMO lead, engineering manager, or Scrum Master — to review and report on success metrics on a regular cadence.
5. Break down silos. Share DevOps metrics with product, business, and customer success teams. Making the data visible across functions helps everyone understand how engineering performance translates to business results.

Key Takeaway

Internal metrics are not useless — they are useful diagnostic signals. But they should never be the primary definition of DevOps success. The teams and organisations that consistently deliver value are those that keep customer outcomes at the centre of how they measure their own performance. The DORA four-metric framework offers a proven, research-backed starting point for any team ready to make that shift.

1. Ignoring Staffing and Workload Capacity

One of the earliest and most damaging mistakes is pushing a DevOps transformation on a team that is already stretched thin. Before introducing new processes, toolchains, or responsibilities, engineering leaders need an honest picture of current workloads and individual capacity.

Practical steps to avoid this mistake:

• Audit existing workloads — map what each team member is currently responsible for before layering on DevOps duties.
• Define clear KPIs — establish key performance indicators so progress is measurable and team health is visible.
• Balance responsibilities deliberately — use workload data to redistribute tasks fairly rather than defaulting to whoever volunteers or whoever is most senior.

Neglecting capacity planning leads to burnout, high attrition, and a DevOps rollout that stalls because the people driving it are exhausted or actively looking for other jobs.

2. Transitioning Without Adequate Planning

Competitive pressure can push organisations to announce a DevOps initiative before they are genuinely ready. The result is often engineers assigned to DevOps roles without the required depth of expertise, or small teams taking on complex projects to differentiate from competitors — only to deliver poor-quality outcomes.

A well-planned DevOps transition should include:

• Skills assessment — honestly evaluate the current expertise of everyone involved, not just their job titles.
• A phased roadmap — break the transition into stages with clear milestones rather than attempting a big-bang cutover.
• Training investment — identify skills gaps early and budget time and money to close them before those gaps become production problems.
• Realistic timelines — do not let competitive anxiety compress planning phases. A rushed plan tends to cost more time in rework than a careful one.

3. Prioritising Speed Over Quality

DevOps is strongly associated with delivery speed — shorter release cycles, faster feedback loops, and continuous deployment pipelines. This creates a tempting but dangerous assumption: that speed is the primary goal and quality is something to negotiate away when timelines are tight.

In reality, sustainable DevOps practices treat speed and quality as complementary, not competing. Automated testing, peer code review, and continuous integration exist precisely to maintain quality while moving fast. Skipping these in the name of speed typically produces:

• Higher defect rates that slow teams down later through incident response and hotfixes.
• Technical debt that compounds over time and eventually makes further acceleration impossible.
• Customer trust issues that are far more costly to recover from than a slightly delayed release.

The principle to internalise is that well-implemented automation — not corner-cutting — is what enables both speed and quality simultaneously.

4. Adopting New Technology Before Mastering the Current Stack

The DevOps tooling ecosystem evolves rapidly. New platforms, frameworks, and plugins appear constantly, and there is ongoing pressure to adopt whatever is trending — sometimes even tools that are still in beta — because competitors appear to be using them.

This approach introduces unnecessary risk. Before migrating to a new technology:

• Fully understand what you are replacing — know the current tool’s limitations, not just its shortcomings. Understand why you are switching.
• Evaluate maturity — a tool in beta carries integration and stability risks that may not be appropriate for production workloads.
• Stage your adoption — run new tooling in a lower environment first, measure the outcomes, and only promote to production when confidence is high.
• Avoid FOMO-driven decisions — the fact that a competitor is using a particular technology is not sufficient justification on its own.

Technology decisions should be driven by documented requirements and evaluated trade-offs, not by announcements at the most recent conference.

5. Failing to Get Buy-in From All Stakeholders

DevOps is not solely an engineering initiative. At its core, it is a cultural and organisational shift that bridges development, operations, security, product, and — in many cases — leadership. One of the most common failure modes is treating DevOps as something a single team implements in isolation, while other groups continue working in siloed ways.

For a DevOps transformation to take hold:

• Secure executive sponsorship early — without visible support from leadership, the cultural changes required will not happen.
• Involve all affected teams — development, operations, QA, security, and product teams all need to understand how their ways of working will change and why.
• Establish shared goals — teams that are measured on conflicting metrics (e.g., Dev rewarded for feature velocity, Ops rewarded for system stability) will naturally resist collaboration.
• Communicate changes proactively — developers introducing new features that affect the pipeline or infrastructure should communicate those changes to all stakeholders before deployment, not after.

Summary

DevOps adoption fails most often not because the underlying principles are flawed, but because organisations underestimate the organisational, cultural, and planning effort required. The five mistakes above — underestimating capacity, planning poorly, sacrificing quality for speed, chasing immature tooling, and neglecting stakeholder alignment — are entirely avoidable with deliberate preparation and honest self-assessment.

A phased, people-first approach will nearly always outperform a rapid, tool-first one in the long run. Take the time to plan well, invest in your team’s skills, and build the cross-functional trust that DevOps depends on.

DevOps, open source, and programmable infrastructure were dominant trends heading into 2018. To understand where IT professionals were focusing their energy, TechTarget gathered New Year’s resolutions from DevOps engineers, ops veterans, project managers, and cloud architects. The result is a practical snapshot of the skills and mindset shifts the industry was prioritizing—most of which remain highly relevant today.

Pick Up New Operating System Skills

“I grew up in Microsoft, and I’d like to ratify and expand Linux [server administration]. My goal for the next 12 months is to get a Red Hat certification.”

— Gary Bright, Infrastructure Developer at Niu Solutions (UK)

For engineers rooted in Windows environments, Linux fluency has become increasingly important as cloud-native infrastructure defaults to Linux-based systems. Red Hat certifications cover a broad range of IT functions performed with Red Hat products—from Gluster storage administration to OpenShift container deployment. Beyond its core Linux administrator and developer tracks, Red Hat also offers a dedicated DevOps certification path for practitioners looking to formalize their skills.

Do DevOps Right—Not Just by Name

“[The goal is] getting our heads around what DevOps is, and self-learning, and bringing that back into the organization. You can’t just say, ‘I’m going to do DevOps or just Agile.’ How do I pick and choose from those and push it into our processes and make sure each bit is beneficial to our org?”

Adopting the DevOps label without understanding its underlying principles is a common pitfall. True DevOps transformation requires deliberately selecting practices—continuous integration, automated testing, blameless post-mortems, shared ownership—that solve real problems within a specific organization. Blanket adoption of frameworks without adaptation rarely delivers value.

Rely on Monitoring and Management Dashboards

“We are at the point where we started utilizing management dashboards now and want to do more and more: create all the dashboards, all the alerts and all the data-driven metrics.”

Observability is only as useful as the dashboards and alert configurations that surface actionable signals. Moving beyond reactive incident response—where teams scramble after something breaks—toward proactive monitoring using historical metrics allows teams to spot degradation before it affects users. The goal: use data to prevent incidents, not just respond to them.

Advice for professionals looking to grow in DevOps: combine a relevant certification with at least one programming language. An example path cited was obtaining the AWS Certified Solutions Architect credential alongside scripting or automation skills to bridge the gap between application engineering and operations.

Bring Enterprises into Modern Ops

“I want to get better at providing [configuration and compliance automation] … to help that customer move one step closer to continuous integration, continuous deployment [and] continuous compliance.”

— Larry Herz, Senior Data Center Engineer at Ahead LLC

Not every enterprise can or should move everything to the cloud immediately. A pragmatic approach—evaluating workloads case by case—was already standard practice by 2017. Applications that benefit from auto-scaling or geographic distribution are natural candidates for cloud migration. Large monolithic stacks, by contrast, often require significant refactoring before a cloud move delivers real cost or performance improvements. A lift-and-shift migration without architectural changes can produce cloud bills higher than equivalent on-premises costs.

Configuration management and compliance automation (using tools such as Ansible, Chef, or Puppet) are key enablers of CI/CD pipelines in enterprise environments, ensuring that environments remain consistent and auditable without manual intervention.

Pick Up a New Programming Language

“My last personal goal was to improve my technical communication. What’s next? Learning Go. The ops and developer tooling world is moving to Go, and I don’t have a statically typed language under my belt. I write Ruby every day, and default to Python when given the choice.”

— Paige Bernier, Software Engineer on New Relic’s Demotron project

Go (Golang) was developed at Google and has become a dominant language for DevOps and infrastructure tooling. Its strengths include fast compilation, a straightforward concurrency model via goroutines, and a standard library well-suited to network services and distributed systems. Many widely used DevOps tools—including Docker, Kubernetes, Terraform, and Prometheus—are written in Go, making it a practical skill for anyone working in cloud-native environments.

For engineers primarily working in dynamically typed languages like Python or Ruby, Go introduces static typing, which can catch entire categories of bugs at compile time rather than runtime.

Editor’s note: Demotron is an internal New Relic project that builds intentionally poorly performing dummy applications and back-end services, enabling the company to demonstrate its IT performance monitoring and management tooling in realistic failure scenarios.

Put Multi-Cloud to Use

“My resolution is to have several multi-cloud production engagements where organizations can take advantage on-the-fly of cloud pricing and region availability.”

— Will Kinard, CTO of BoxBoat Technologies

By 2018, the hybrid data center model was already well established. The next logical step was workload portability across multiple cloud providers—enabling organizations to exploit pricing differences, geographic availability, and provider-specific capabilities without being locked into a single vendor.

Containers are the key enabler of this portability. However, realizing multi-cloud deployments in production requires mature container orchestration, a clear approach to networking and service discovery across providers, and federation technologies that allow a unified control plane to manage workloads across clouds. The maturity of tooling in this area has grown substantially since 2018, but the architectural decisions Kinard described remain central to any multi-cloud strategy.

Focus on What Matters—Including Your Own Health

“Personally, I really want to take good care of myself. You do ops work for 15 years and it’s 15 years of sleep deprivation. It can ruin your health. That’s why I’m so passionate now about helping people, particularly in ops, to remove some of that burden of being way overwhelmed. We don’t let our computers get to 100% capacity utilization, and we shouldn’t let ourselves either.”

— Dominica DeGrandis, author of Making Work Visible: Exposing Time Theft to Optimize Work & Flow

Burnout in operations roles is a well-documented problem. Persistent on-call rotations, alert fatigue, and organizational pressure to maintain uptime at all costs erode both individual health and team performance over time. DeGrandis’s analogy is apt: systems engineering practice explicitly avoids running servers at 100% utilization because performance degrades and failures become more likely—the same principle applies to human capacity.

Sustainable DevOps practices—including thoughtful alert thresholds, fair on-call rotations, blameless post-mortems, and explicit prioritization of work in progress—are as much about organizational health as they are about technical efficiency. DeGrandis’s book Making Work Visible offers a practical framework for identifying where time and energy are being consumed invisibly, which is a useful starting point for any team struggling with overload.

Key Takeaways

• OS breadth matters: Linux fluency and formal certifications (such as Red Hat’s) open doors in cloud and DevOps roles, even for engineers with a primarily Windows background.
• DevOps is a practice, not a label: Adopt specific techniques that solve real organizational problems rather than implementing frameworks wholesale.
• Observability drives proactive operations: Invest in dashboards and historical metrics to prevent incidents, not just respond to them.
• Cloud migration requires judgment: Lift-and-shift is not always the right move; workload characteristics should drive migration decisions.
• Go is a practical DevOps language: The ecosystem of infrastructure tooling built in Go makes it worth learning for anyone in the cloud-native space.
• Multi-cloud portability requires container discipline: Realizing multi-cloud value depends on mature orchestration and federation strategies.
• Operator health is a system concern: Sustainable on-call practices and workload management are prerequisites for long-term team performance.

DevOps Is About Solving Real Business Problems

At its core, DevOps is not a technology — it is a business strategy. Some organizations adopt DevOps to accelerate delivery. Others need to capitalize on a market opportunity before a competitor does. Still others face shrinking budgets and must find a way to do more with less. Regardless of the motivation, organizations at the DevOps Enterprise Summit in San Francisco shared a common experience: the path to DevOps is paved with cultural resistance and hard lessons.

What follows are four real-world case studies presented at the summit, each illustrating a different context for DevOps adoption and the practical outcomes — both successes and setbacks — that resulted.

U.S. Department of Defense: Doing More With 30% Less

The Department of Defense’s Joint Warfare Analysis Center (JWAC) did not choose to adopt DevOps from a position of strength. Over several years, the center lost 30 percent of its staff and budget, making it impossible to maintain its existing processes at scale.

Kurt Hockaday, a data systems technical lead for JWAC, told summit attendees that the center was left with no viable alternative.

“We simply couldn’t keep doing what we were doing.”

Kurt Hockaday, Data Systems Technical Lead, JWAC

Working with outside consultants, JWAC developed a set of guiding principles aimed at speeding up service delivery, managing services more proactively, bringing consistency to operations, and enabling self-service provisioning. Early results were encouraging: the team reduced environment build times to roughly one week and decreased dependence on manual admin access through automation.

However, the journey was not without setbacks. Self-service provisioning remained incomplete, and the team found itself re-learning and re-implementing foundational processes that had been assumed to be solid.

Hockaday’s lesson for other government adopters was direct:

“Battleships can’t turn on a dime, and neither can fairly mature government organizations. Introducing large-scale change into the DoD is never an easy endeavor.”

Kurt Hockaday, JWAC

The JWAC story is a useful reminder that DevOps adoption in regulated, resource-constrained, or hierarchical environments requires patience and realistic timelines. Progress is still progress, even when it is incremental.

Nationwide Mutual Insurance: Fixing Test Bed Bloat to Unlock Speed

Nationwide Mutual Insurance set out with an explicit goal: become a world-class software development organization. As the company began embedding DevOps practices, one of the first obstacles it uncovered was the state of its testing environments.

“When you’ve been testing for so long, it’s natural that you form a bloat around your test beds. Often they were broken and no one was paying attention.”

Cindy Payne, Director of IT Application Development, Nationwide

After applying DevOps principles to streamline and stabilize those test beds, one development team reported that the time to receive test results dropped to just two hours — a dramatic reduction from previous baselines.

The business impact of that improvement became tangible almost immediately. When Hurricane Harvey triggered a surge in food-related insurance claims from the Houston area, Nationwide’s developers were able to re-engineer the relevant claims workflow by 40 percent in just eight hours.

“A year ago, this kind of change would have taken about 90 days.”

Jim Grafmeyer, Digital Solutions Architect, Nationwide

This example illustrates one of the clearest value propositions for DevOps in traditionally slow-moving industries: when a business event demands rapid response, teams with mature DevOps practices can act in hours rather than months.

AdvancedMD: Every Common Mistake in One Journey

John Esser, senior director of IT and data center operations for medical SaaS provider AdvancedMD, offered one of the summit’s most candid accounts. His story is effectively a catalogue of anti-patterns — and why avoiding them matters.

Mistake 1: Creating a Centralized DevOps Team

Esser’s first instinct was to stand up a dedicated, centralized DevOps team. He was quick to acknowledge the outcome:

“Worst decision I’ve made. It was a bottleneck, it was a chokepoint, it was a constrained resource, and it was a silo.”

John Esser, Senior Director of IT, AdvancedMD

The fix was to embed DevOps practices directly into individual development teams — the model most practitioners now recommend. But that created its own friction.

Mistake 2: Underestimating Cultural Resistance

Once DevOps responsibilities were distributed across teams, many team members pushed back, treating DevOps as someone else’s concern — something needed only in a specific corner of the organization, not in their work.

Mistake 3: Ignoring Technical Debt in the Architecture

The company’s monolithic data model was incompatible with the autonomy and loose coupling that DevOps practices depend on. Breaking up a single, shared data store is painful work, but it was necessary before meaningful progress could be made.

Mistake 4: Letting Past Success Justify the Status Quo

A prevailing attitude within AdvancedMD held that because the company had succeeded without DevOps, it did not need DevOps. Esser’s response:

“Where we are and where we need to go is something different. We needed to create a different kind of success for the future.”

John Esser, AdvancedMD

Mistake 5: Equating DevOps With Automated Deployment

Perhaps the most pervasive misconception Esser encountered was that DevOps simply meant automated deployments. While automation is a component of DevOps, conflating the two causes organizations to stop short of the cultural, organizational, and process changes that make DevOps genuinely transformative.

“That’s something you want to do, but it’s definitely not DevOps.”

John Esser, AdvancedMD

Amazon Prime Now: Adapting a System Built for Days to Deliver in an Hour

Tison Mathew — now CTO for Alignment Healthcare, but previously working on Amazon’s Prime Now service — described one of the more technically demanding DevOps contexts at the summit. Prime Now promises customers free delivery within one hour. The challenge: the underlying infrastructure had been designed for two-to-five-day delivery windows.

To bridge that gap, Mathew’s team applied DevOps practices within the framework of what Amazon calls its Virtuous Cycle: a feedback loop in which infrastructure investment drives efficiency, speed, and reliability, which in turn fuels customer demand and further growth.

The work required continuous iteration on ordering and fulfillment systems under demanding operational constraints — the kind of rapid, incremental delivery that DevOps is specifically designed to support.

Mathew drew a direct line from that experience to his current mission in healthcare:

“I want to do the same thing for healthcare. That’s my passion now.”

Tison Mathew, CTO, Alignment Healthcare

Key Takeaways Across All Four Stories

Despite coming from radically different industries and contexts, the organizations at the DevOps Enterprise Summit shared several consistent lessons:

• Culture is the hardest problem. Technical tooling is the easier part. Getting people to change how they work, collaborate, and think about ownership is where most DevOps efforts stall.
• Centralized DevOps teams create bottlenecks. DevOps practices are most effective when embedded within cross-functional delivery teams, not isolated in a dedicated silo.
• Legacy architecture will slow you down. Monolithic systems and shared data stores are structural impediments to the autonomy and speed that DevOps requires. Addressing technical debt is part of the transformation.
• Progress is non-linear. Setbacks — such as JWAC’s incomplete self-service provisioning — are normal. The measure of success is whether the organization keeps learning and iterating.
• DevOps is not automated deployment. Automation is a tool. DevOps is a discipline that spans culture, process, measurement, and collaboration across the entire software delivery lifecycle.
• The business case becomes clear under pressure. Nationwide’s ability to respond to Hurricane Harvey in eight hours instead of ninety days is the kind of outcome that makes DevOps investment self-evident to business stakeholders.

The Broader Lesson: DevOps Works Across Industries

The DevOps Enterprise Summit brought together leaders from defense, insurance, healthcare, and e-commerce — and the consistent message was that DevOps principles apply regardless of industry vertical. The specifics of implementation differ, the pace of change varies, and the obstacles are shaped by organizational context. But the underlying principles — fast feedback, automation, continuous improvement, shared ownership, and a focus on delivering value — translate everywhere.

Whether your organization is a government agency navigating budget cuts or a SaaS company wrestling with a monolithic architecture, the question is not whether DevOps applies. The question is how to begin — and how to sustain the momentum when the inevitable resistance arrives.

At the upcoming 2017 DevOps Enterprise Summit in San Francisco, questions about how DevOps at scale is really faring in large organizations are going to be raised and debated on the podiums and in the halls. To get that conversation started a bit earlier, we asked three DOES speakers about what to expect at the conference and the state of DevOps in 2017.

Robert Stroud, principal analyst serving infrastructure and operations professionals at Forrester, will be speaking on “DevOps In The Enterprise: The Analyst ‘Outside-In’ Perspective” and “DevOps: From Analyst Inquiry to Organizational Action.” Rob England, best known as The IT Skeptic and a management consultant with Two Hills, will speak on the subject of “Surviving DevOps.” And Torsten Volk, managing research director for hybrid cloud, the software-defined data center, machine learning and cognitive computing at Enterprise Management Associates, will also speak about “DevOps in the Enterprise” alongside Stroud.

What’s going well with DevOps right now?

Rob England: DevOps adoption is growing at an extraordinary pace right now, at least in my part of the world (New Zealand). And what they’re doing with containers is indistinguishable from magic.

Torsten Volk: The first thing companies are doing right is that they are aware there is an issue of antagonism between dev and ops, and they’re working on figuring it out. If they don’t, they can’t have faster development and high-quality releases. And the number two thing they’re doing right is looking at containers being the vehicle to transport a turnkey runtime. They are basically giving their developers the tools to very quickly and comprehensively deliver what they’ve written.

What are issues we may not hear about, or enough about, at DOES? Will DevOps at scale be on the agenda?

Robert Stroud: We hear about how DevOps is wonderful, but I don’t think we hear the horror stories. DevOps is about caring and sharing and a blameless culture, and that’s an interesting concept, but we should be made aware of things that don’t work. We may not hear about traditional IT or how to evolve to get DevOps at scale, and we need to hear about that. I don’t see a lot of content (in the conference schedule) on DevOps at scale across a true enterprise organization, and that is the stuff we need to hear.

England: Some of the biggest challenges right now are that DevOps is seen as the magic bullet. DevOps is especially being seen by management as something that will change people, but they don’t need to changethemselves or change any of the other functions in the organization, such as governance, HR, finance and so on. Also, we are on the Gartner hype cycle. As we peak, we will begin to hear the DevOps-doesn’t-work stories and see the backlash.

Ideally, what should happen next to propel DevOps at scale adoption forward?

England: We are in the middle of the IT Renaissance. There has never been a bigger change in the way we think about how we do IT. Let’s get our head around this shift first before we start thinking about something else. Our addiction to novelty is harmful to our industry.

Volk: We need intent-based DevOps. At the end of the day, what I mean by that is that if a developer has a certain task, he or she should receive a developer workspace that is tailored to exactly that task. We need to be pushing the tailoring of workspace to the developer so they don’t have those hoops to jump over.
Stroud: IT as we know it is fundamentally at a crossroads. DevOps made devs heroes, and as we transition to BizDevOps, businesses are going to be the heroes. We’re going to move R&D back into the business, and developers are now going to be part of the business team.

The Old World: Siloed Dev and Ops Teams

For much of the history of enterprise software, development teams and operations teams lived almost entirely separate lives. Developers wrote code and threw it over the proverbial wall; operations teams caught it, complained about it, and somehow kept it running. Cross-team communication was the exception, not the rule.

That model collapsed under pressure. As business expectations shifted toward faster release cycles, tighter feedback loops, and always-on services, the old hand-off model became a liability. Something had to change.

What DevOps Actually Means

DevOps is, as HashiCorp co-founder Mitchell Hashimoto has noted, somewhat in the eye of the beholder. At its core, it is a collection of cultural practices, organisational patterns, and engineering strategies aimed at increasing the velocity of software delivery without sacrificing reliability or quality.

Common pillars of a DevOps approach include:

• Collaboration: Development and operations share responsibility for the full software lifecycle, from design through production.
• Automation: Repetitive manual tasks — builds, tests, deployments, configuration management — are automated so humans focus on higher-value work.
• Continuous feedback: Monitoring, alerting, and observability tools return production signals to the team quickly so problems are caught and fixed fast.
• Incremental delivery: Small, frequent changes are safer and easier to debug than large, infrequent releases.

The History and Evolution of DevOps Thinking

Nell Shamrell-Harrington, then a senior software development engineer at Chef, opened the GeekWire panel by walking through how DevOps thinking evolved. The movement grew out of frustrations with waterfall development and the recognition that Agile, while improving development cadence, still left a gap between code completion and production deployment. Practitioners began borrowing from lean manufacturing and systems thinking to close that gap.

Key milestones in that evolution include the popularisation of infrastructure-as-code (treating server configuration the same way you treat application code), the rise of configuration management tools, and the eventual normalisation of continuous integration and continuous delivery pipelines.

Continuous Integration and Continuous Delivery: The Assembly Line Model

Avi Cavale, then CEO of Shippable, built on that foundation by focusing on how CI/CD makes DevOps tangible in day-to-day engineering work.

Continuous Integration (CI) means every code change is automatically built and tested against the existing codebase. Developers merge frequently — sometimes many times per day — so integration bugs surface immediately rather than accumulating for weeks.

Continuous Delivery (CD) extends CI by ensuring that every change that passes tests is in a deployable state. Continuous Deployment goes one step further: qualifying changes are automatically pushed to production without manual intervention.

Cavale’s assembly-line analogy is useful: just as a car factory works on sub-assemblies in parallel before joining them into a finished vehicle, a CI/CD pipeline lets teams work on independent features simultaneously, integrating and validating them automatically on the way to release.

Practical steps to establish a CI/CD pipeline:

1. Commit all code — including infrastructure and configuration — to version control.
2. Define an automated build that runs on every push or pull request.
3. Write a meaningful test suite (unit, integration, smoke tests) that runs as part of the build.
4. Fail the build loudly and early when tests do not pass.
5. Automate deployment to a staging environment for every green build.
6. Gate production promotion with automated checks and, where required, a human approval step.

DevOps and the Networking Layer

Nathan Pierce of F5 Networks addressed a dimension of DevOps that application developers often overlook: the physical and logical networking layer. Load balancers, firewalls, DNS, and application delivery controllers all sit between code and users. When these components are managed manually and independently of the application release process, they become a bottleneck and a source of configuration drift.

Applying DevOps principles to networking — sometimes called NetOps or network automation — means treating network configuration as code, versioning it, and including network changes in the same pipeline used for application changes. This reduces the risk of a deployment being held up because a firewall rule or load-balancer policy hasn’t been updated to match the new application version.

Security Cannot Be an Afterthought: DevSecOps

The fastest CI/CD pipeline in the world is a liability if it ships vulnerable software at high velocity. Mitchell Hashimoto addressed this directly, arguing that security hygiene must be embedded into DevOps practices rather than bolted on at the end of the cycle.

The pressure to ship fast — whether driven by business deadlines or executive impatience — creates conditions where security checks get skipped or deferred. The antidote is automation: when security scanning, secrets management, and compliance checks are integrated into the pipeline, they cannot easily be bypassed under schedule pressure.

Approaches to embedding security into DevOps (often called DevSecOps):

• Static analysis (SAST): Run code-level security scans automatically on every build.
• Dependency scanning: Check third-party libraries for known vulnerabilities as part of the build process.
• Secrets management: Never hard-code credentials. Use a dedicated secrets store (such as HashiCorp Vault) and inject secrets at runtime.
• Infrastructure hardening: Encode security baselines as policy-as-code and validate them in the pipeline before any infrastructure is provisioned.
• Dynamic analysis (DAST): Run automated penetration tests against staging environments before promoting to production.

Key Takeaways for Engineering Teams

Across all four speakers, a consistent theme emerged: DevOps is not a product you buy or a title you give someone. It is a sustained organisational and engineering discipline. Getting it right requires:

• Breaking down the cultural wall between development and operations before worrying about tooling.
• Starting with version control and automated testing — these are non-negotiable foundations.
• Treating infrastructure, configuration, and network policy as code, not as manual processes.
• Integrating security scanning into the pipeline from day one, not as a release gate added later.
• Measuring outcomes (deployment frequency, lead time, mean time to recovery) to prove the approach is working and to identify where to improve.

DevOps done right does not mean moving faster at the expense of stability. It means building systems and practices that let you move faster because reliability is built in.

Why Certain DevOps Skills Command Premium Salaries

DevOps professionals who earn the highest salaries tend to combine deep technical expertise with strong cross-functional collaboration abilities. They understand enterprise automation inside-out, can navigate every stage of the software development lifecycle, and treat organizational change as an opportunity rather than a threat. Where most employees see disruption, a skilled DevOps engineer sees a process gap to close and a solution to propose.

Looking at the salary data, a clear pattern emerges: the highest-paying DevOps skills cluster around automation and configuration management. This makes intuitive sense. Tools like Ansible and Puppet allow engineering teams to provision, configure, and deploy infrastructure reliably at scale — whether a company runs ten servers or ten thousand. Professionals who master these platforms become force multipliers for their organizations, and the market compensates them accordingly.

Top-Paying DevOps Skills: A Breakdown

1. Ansible — $121,382

Year-over-year change: N/A

Ansible topped the salary rankings at the time of this data. An open-source automation engine written in Python, Ansible handles configuration management, application deployment, orchestration, and other IT tasks using a simple, human-readable YAML syntax called Playbooks. Unlike some competing tools, it is agentless — it communicates with managed nodes over SSH, reducing the operational overhead of keeping agent software up to date. Ansible is integrated into the Fedora Linux distribution and is available through several Red Hat product offerings. Its low barrier to entry combined with its power at scale makes Ansible expertise highly sought after.

2. KornShell — $118,273

Year-over-year change: +1.4%

KornShell (ksh) is a Unix shell with roots stretching back more than thirty years. It was developed at Bell Labs and incorporates features from both the Bourne shell (its primary source base) and the C shell, including job control, command history, and dynamic extensibility of built-in commands. The high salary associated with KornShell expertise reflects its presence in legacy enterprise and mainframe environments. Organizations running long-lived critical systems often cannot easily migrate away from ksh scripts, so specialists who understand its nuances remain valuable and relatively scarce.

3. Jenkins — $113,354

Year-over-year change: +0.5%

Jenkins is one of the most widely used open-source automation servers in the DevOps ecosystem. It is the backbone of continuous integration and continuous delivery (CI/CD) pipelines for countless organizations. Jenkins supports integration with a broad range of version control systems including Git and Mercurial, and can trigger builds from shell scripts, Apache Ant, Apache Maven, and many other tools. Its extensive plugin library — numbering in the hundreds — means it can be adapted to almost any workflow, which explains both its popularity and the sustained demand for engineers who can architect and maintain Jenkins pipelines.

4. Puppet — $112,883

Year-over-year change: -3.7%

Puppet uses a declarative, Ruby-based domain-specific language (DSL) to describe the desired state of infrastructure. Once a desired state is defined, Puppet enforces it continuously — automatically correcting configuration drift without requiring manual intervention. This makes it particularly appealing to system administrators, cloud architects, and teams responsible for large-scale virtualized environments. Puppet’s agent-based architecture means it can manage thousands of nodes consistently, and its integration with reporting and auditing tools adds governance value in regulated industries.

5. Chef — $112,523

Year-over-year change: -3.8%

Chef takes an infrastructure-as-code approach, using Ruby-based “recipes” and “cookbooks” to define server configuration and application deployment processes. Its tight integration with cloud platforms such as AWS EC2 and Microsoft Azure makes it a natural fit for hybrid and multi-cloud environments. Chef scales effectively from small startups to large enterprises, and its test-driven approach to infrastructure — supported by tools like Test Kitchen and ChefSpec — resonates with engineering cultures that prioritize code quality.

6. Vagrant — $111,422

Year-over-year change: +3.3%

Vagrant is a tool for building and managing portable, reproducible virtual development environments. Written in Ruby, it works with hypervisors such as VirtualBox, VMware, and cloud providers to spin up pre-configured development environments from a single Vagrantfile. By codifying the development environment alongside application code, Vagrant eliminates the classic “works on my machine” problem. Developers and system administrators appreciate the time savings from automated provisioning, and the tool’s 3.3% year-over-year salary growth at the time of this data suggests its adoption was still accelerating.

Key Takeaways for DevOps Career Development

• Automation skills are the highest earners. Configuration management and CI/CD tooling dominate the top of the salary list. Investing time in tools like Ansible, Puppet, Chef, or Jenkins has a measurable compensation payoff.
• Legacy expertise retains value. KornShell’s place near the top of the list is a reminder that organizations running long-lived systems pay well for specialists who can maintain them safely.
• Soft skills matter. Technical tool proficiency alone does not explain premium salaries. The ability to collaborate across teams, communicate change effectively, and guide organizations through transitions is equally important.
• The market evolves quickly. The negative year-over-year changes for Puppet and Chef hint at competitive pressure from newer tools. DevOps professionals should monitor the ecosystem continuously rather than relying on any single skill.
• These figures are historical. Salary data from 2017 reflects a specific moment in a fast-moving market. Use this data for directional insight, and consult current sources such as Stack Overflow’s annual Developer Survey, Levels.fyi, or LinkedIn Salary for up-to-date benchmarks.

The broader lesson is consistent: DevOps professionals who combine hands-on expertise in automation tooling with the organizational and communication skills to drive change at scale are the ones who command — and deserve — the highest compensation.

DevOps Has Moved Past the Hype Cycle

By the mid-2010s, DevOps had firmly established itself as a mainstream enterprise discipline rather than an emerging trend. Survey data from that period illustrated rapid adoption: the 2016 RightScale State of the Cloud survey reported that 74% of 1,060 IT professionals had adopted DevOps in their organizations, up from 66% in 2015. A separate Vanson Bourne report commissioned by Appvance found that 73% of 200 IT decision-makers had adopted some DevOps processes.

The compensation story was equally striking. Puppet’s 2016 DevOps Salary Report found that 58% of practitioners earned more than $100,000 annually—up from 47% the prior year—while 43% of managers exceeded $150,000, compared with just 26% in 2015.

This growth created intense demand for DevOps engineers and raised an important strategic question: how should an organization actually staff a DevOps transformation?

The Core Insight: It’s Not Build vs. Buy—It’s Build and Buy

A common instinct among CIOs is to treat DevOps adoption as a recruiting problem: find experienced DevOps engineers, hire them, and the transformation follows. IT staffing experts and analysts push back on this framing. You can’t build a DevOps environment simply by purchasing talent. Equally, you can’t retitle existing staff as “DevOps engineers” and expect the culture and practices to appear on their own.

James Stanger, senior director of products at CompTIA, framed it directly: “People who just want that trained DevOps person are kind of barking up the wrong tree. What they need are people who are in operations or development who have a willingness to learn about each other.”

The practical answer is a deliberate combination: hire externally for specific hard-to-build technical skills, then use those new hires to accelerate the upskilling of existing staff who bring irreplaceable organizational knowledge.

What DevOps Actually Requires

DevOps is a methodology—roughly a decade old at the time of the original reporting—in which software development and operations teams collaborate closely throughout the entire software lifecycle: building, testing, and releasing software frequently and in small increments. The goals are faster delivery, higher quality, and better security. DevOps depends on both cultural change and specific enabling technologies.

An organization adopting DevOps therefore needs two distinct types of capability:

• Collaborative mindset and cross-functional fluency: Developers who understand operations constraints, and operations engineers who understand the development lifecycle.
• Specific technical skills: Proficiency with the tools and platforms that make continuous delivery and infrastructure automation possible.

Where to Buy: Technical Skills That Are Hard to Build Quickly

Connor Leech, a senior technical recruiter at tech-staffing agency Mondo, identified the technical areas where external hiring typically makes the most sense. Organizations moving to DevOps commonly need people who can:

• Automate infrastructure provisioning and application deployment pipelines
• Design systems that automatically scale in response to demand fluctuations
• Work fluently with major cloud providers such as AWS

The specific tools and technologies that map to these needs include:

• Configuration management and automation: Puppet, Chef
• Application performance monitoring: New Relic
• Scripting and general-purpose programming languages: Python, Ruby, PHP
• Containerization: Docker (container runtime for packaging and deploying applications consistently across environments)

The reason external hiring makes sense here is pragmatic. These tools are complex, and hiring managers consistently want candidates who have used them in large production environments—not just experimented with them in sandboxes. Training existing staff to production-level proficiency in multiple platforms simultaneously is slow and risky when a transformation is underway.

“It’s definitely possible to retrain existing engineers in these areas, but because the tools are kind of complex, [CIOs] want people who have used them rather than have to teach people on them. It’s a common theme with hiring managers: They want someone who has not only played around with these, but have used them in a large production environment.”

— Connor Leech, Senior Technical Recruiter, Mondo

Using Contract Engineers as a Force Multiplier

One effective model is bringing in experienced DevOps engineers on short-term contracts—typically three to six months. These contractors come in, establish automation pipelines, define standards, and actively upskill the existing team. They are expensive, but they function as a force multiplier: when they leave, the permanent team is meaningfully more capable than it was before.

“What’s really common is bringing in DevOps engineers as contractors. You bring in people on contract for six months, and they come in, help automate and ramp everyone up and then go and do another contract. They’re generally pretty expensive, but they’re incredibly valuable. They can turn a company’s existing engineers into DevOps engineers.”

— Connor Leech, Mondo

Where to Build: Mindset and Organizational Knowledge

Technical skills are necessary but not sufficient. DevOps depends on a fundamentally collaborative way of working—the deliberate dismantling of the wall between development and operations. This requires a different kind of capability that is much harder to hire for and much easier to cultivate in existing staff.

Stanger identified the key characteristics of good internal DevOps candidates:

• Curiosity about the other side of the dev/ops divide, even if their primary expertise leans one way
• Familiarity with project management disciplines to keep iterative delivery cycles on track
• Comfort working within agile and Scrum frameworks, which are common structures in DevOps environments
• Willingness to share responsibilities that were previously siloed

Critically, Stanger argued that many existing IT professionals already possess the raw material for this. Developers have often had some exposure to operations concerns, and operations engineers frequently have development experience. The gap is not as wide as it might appear—what’s often missing is not knowledge but permission and encouragement to apply it.

“Many of the people who have been working in programming for years, if they have the right mentality, are already DevOps people. Anyone could easily be turned into that DevOps person. Most people have the seeds of DevOps in them, but the seeds haven’t been nurtured.”

— James Stanger, CompTIA

Why Existing Staff Are Not Optional

Jay Lyman, a principal analyst covering DevOps at 451 Research, reinforced this dual approach from an analyst’s perspective. Organizations need an infusion of new skills from external hires, but they also depend on the organizational context and institutional knowledge that existing staff carry. No external hire will understand the business’s specific systems, constraints, and history as well as a long-tenured internal engineer.

There is also a practical alignment benefit. IT professionals who understand that DevOps skills increase their market value are generally motivated to participate in training and upskilling programs. This makes change management easier—staff become advocates for the transformation rather than passive recipients of it.

The Leadership Imperative: Understand and Sell DevOps

Staffing strategy is only one part of the equation. CIOs and engineering leaders must themselves develop a genuine understanding of DevOps—not just at the conceptual level, but operationally. They need to be able to articulate what DevOps delivers for the business (speed, quality, reduced risk) and why it requires changes to how teams are structured and how work is measured.

Not all staff will embrace the transition. Some IT professionals are more comfortable in traditional, more sequential delivery models. This is not necessarily a problem—some projects and contexts do suit more structured, phased approaches. But organizations moving fully toward continuous delivery may eventually face a mismatch between those delivery expectations and staff who resist the required way of working. In those cases, external hiring may eventually be necessary not just to add skills but to replace resistance.

Summary: A Practical Staffing Framework

The organizations that successfully form a DevOps environment are those that resist the false choice between hiring and training. They hire deliberately and specifically for the hardest-to-build technical skills, use those new hires to accelerate team capability, and invest simultaneously in developing the collaborative mindset and cross-functional fluency that no job posting can deliver.