Despite the clear advantages, implementing CI/CD is genuinely difficult. Teams must design pipeline workflows, choose between end-to-end integrated platforms and self-assembled toolchains, and ensure that automation touching production systems is safe and correct. The wrong approach can slow down releases instead of accelerating them, erode team confidence, and create outages that affect real users.

The consistent theme across successful CI/CD rollouts is straightforward: go slow, then grow. The following four strategies—originally outlined by Tom Petrocelli, contributing analyst at Amalgam Insights, and published on CMSWire—give DevOps teams of any size a framework for reducing risk during adoption.

1. Be Selective About the Code You Automate First

One of the most common mistakes teams make is deciding to automate everything at once. Rushing to run all code types through a new pipeline dramatically increases risk, because pipelines often need iteration and tuning before they are reliable for a given artifact type.

A more effective approach is to start with a single class of code. Good candidates for an initial pipeline include:

• Infrastructure as Code (IaC) files such as Terraform configurations or Ansible playbooks
• YAML or JSON configuration files used to define environments or container workloads
• Database migration scripts (SQL files managed through a tool like Flyway or Liquibase)

By scoping automation to one artifact type, any pipeline defects affect only a narrow slice of the overall system. The team gains real experience tuning the pipeline—handling secrets, environment variables, approvals, and rollbacks—before widening the blast radius to more critical code paths.

2. Take an Incremental Approach to Pipeline Stages

A complete CI/CD pipeline has many stages: source control triggers, build, unit testing, integration testing, security scanning, artifact publishing, environment promotion, smoke testing, and production deployment. Automating all of these at once compounds complexity and makes it harder to isolate failures.

Instead, automate one stage at a time. A sensible sequence might look like this:

1. Automate the build step—compile code and produce an artifact on every commit.
2. Add automated unit tests that run on every build.
3. Introduce automated merges to a shared integration branch once tests pass.
4. Extend the pipeline to deploy to a staging environment automatically.
5. Finally, add controlled production deployment with approval gates or feature flags.

This incremental approach lets the team verify that each stage is reliable and error-free before adding the next layer of automation. It also makes it far easier to debug problems, because each stage was introduced and validated independently.

3. Start With One Application at a Time

Even with a well-designed pipeline and selective code strategy, rolling CI/CD out across the entire application portfolio simultaneously is a high-risk move. A better approach is to pick a single application as the pilot.

Criteria for a good pilot application:

• Low business criticality — if something breaks, the impact on customers or revenue is limited.
• Reasonably modern codebase — legacy monoliths with complex build processes make a poor starting point.
• Engaged team — a development team willing to iterate quickly and provide feedback accelerates learning.

Once the pilot application is running through the full pipeline reliably, the team has a reference implementation to replicate. Subsequent onboarding of additional applications becomes faster because the patterns, toolchain configurations, and troubleshooting knowledge already exist. High-priority targets—such as customer-facing microservices or Kubernetes-hosted workloads—can then be migrated with much greater confidence.

4. Limit the Blast Radius to IT First

During the early stages of CI/CD adoption, pipeline failures are inevitable. Misconfigured deployment scripts, flawed rollback procedures, and environment drift are common early problems. To contain the impact of these issues, begin with applications that primarily affect the IT team itself rather than business users or customers.

Internal tooling, developer portals, monitoring dashboards, and internal APIs are good examples. If a deployment fails, the people affected are the engineers who can best diagnose and recover from the situation. This is fundamentally different from a failure in a customer-facing checkout service or a revenue-critical reporting application.

Combining this strategy with the others produces a natural risk hierarchy: start with part of a pipeline, for one class of code, in one IT-internal application. This minimizes the blast radius to its absolute minimum while still generating real operational experience.

Putting It Together: The Go-Slow-Then-Grow Playbook

These four strategies are not mutually exclusive—they work best in combination. A practical starting point might be:

1. Choose an internal, non-critical application as the pilot.
2. Automate only the build stage initially, using one artifact type (for example, IaC files).
3. Expand to additional pipeline stages one at a time, validating each before proceeding.
4. Once the full pipeline is stable, onboard additional applications starting with those of moderate criticality.
5. Accelerate onboarding as patterns, templates, and operational confidence mature.

The goal of going slow initially is not to stay slow. Once your pipelines are stable, your toolchain is understood, and your team has built operational muscle memory, CI/CD rollouts to higher-stakes applications—including microservices workloads on Kubernetes—can proceed significantly faster. The early investment in careful, incremental adoption pays dividends in speed and reliability at scale.

Key Takeaways

• CI/CD automation touching production systems carries real risk; treat it with the same care as any production change.
• Selecting a narrow code type, a single pipeline stage, and a non-critical pilot application drastically reduces early risk.
• Confining early failures to IT-internal systems limits business and customer impact while the team learns.
• A slow, deliberate start accelerates long-term adoption by producing reusable patterns and confident practitioners.

This article is based on analysis originally published on CMSWire by Tom Petrocelli, contributing analyst at Amalgam Insights, whose research focuses on developer tools, DevOps methodologies, and IT project efficiency.

DevOps Adoption Is Being Held Back — But by What?

Despite broad recognition that DevOps accelerates software delivery and improves collaboration, many enterprises are still struggling to implement it at scale. A survey of 170 IT professionals conducted by F5 Networks at its DevOpsDays Amsterdam gathering identified the three most significant barriers standing in the way of successful DevOps adoption.

The Three Biggest Obstacles to DevOps

1. Corporate Bureaucracy and Rigid Processes

According to the survey, 40% of respondents identified corporate bureaucracy as the number one obstacle to DevOps implementation. Specifically, participants cited:

• Difficult-to-change testing processes
• Rigid ticketing systems
• Heavy reliance on manual workflows

These organizational constraints slow down the iterative, automated delivery cycles that DevOps depends on. When change approval processes require multiple sign-offs or manual interventions, the speed gains promised by continuous integration and continuous delivery (CI/CD) pipelines are quickly eroded.

2. Legacy Code and Legacy Systems

The second most commonly cited barrier was the prevalence of legacy code and legacy infrastructure within organizations. Many enterprises run core business functions on systems that were never designed with automation, APIs, or modern deployment pipelines in mind. Refactoring or replacing these systems is often costly, time-consuming, and politically sensitive — making it difficult to apply DevOps practices uniformly across the organization.

This challenge is particularly acute in sectors such as finance, manufacturing, and healthcare, where mission-critical applications may have been running unchanged for decades.

3. Incompatible Production Environments

The third major challenge identified was environment incompatibility — situations where development, staging, and production environments differ enough to cause deployment failures or unpredictable behavior. This undermines the reliability of CI/CD pipelines and erodes confidence in automated releases, pushing teams back toward slower, manual deployment practices.

Why DevOps Still Matters

Rodrigo Albuquerque, DevOps solution developer at F5 Networks, emphasized that despite these hurdles, the business case for DevOps remains compelling:

“DevOps is clearly playing an ever bigger role. It boosts efficiency through the optimization of processes, the disappearance of silos, automation tools, standardizing of platforms and a strong culture of collaboration.”

Rodrigo Albuquerque, DevOps Solution Developer, F5 Networks

Albuquerque also expressed optimism about the path forward, noting that automation will ultimately drive broader acceptance of DevOps across organizations that are currently held back by manual processes and organizational inertia.

A Positive Trend: Cross-Team Collaboration Is Growing

F5 Networks also noted an encouraging trend emerging from the survey: increased cooperation across traditionally siloed teams. Breaking down the walls between development, operations, security, and QA is a foundational principle of DevOps culture, and the data suggests organizations are making measurable progress in this area even where tooling and process challenges remain.

Key Takeaways for DevOps Practitioners

• Audit your processes before your tools. Bureaucratic workflows are frequently the root cause of DevOps stagnation — not a lack of tooling.
• Create a legacy modernization roadmap. Legacy systems rarely need to be replaced all at once; incremental strangler-fig patterns and API wrappers can enable DevOps practices without a full rewrite.
• Standardize environments. Infrastructure-as-code tools (such as Terraform, Ansible, or Pulumi) and containerization (Docker, Kubernetes) reduce environment drift and make deployments more predictable.
• Invest in automation incrementally. Even partial automation of testing and deployment pipelines can reduce bottlenecks caused by manual approval gates.
• Measure collaboration, not just velocity. Cultural metrics — such as cross-team incident response participation and shared on-call rotations — signal genuine DevOps maturity.

The F5 Networks survey is a useful reminder that DevOps transformation is as much an organizational and cultural challenge as a technical one. Addressing bureaucracy and legacy debt alongside toolchain modernization gives enterprises the best chance of achieving the agility DevOps promises.

Why Continuous Data Testing Matters in DevOps

Data environments are rarely static. Ongoing changes to data requirements, field mappings, and target environments mean that test queries, data connections, and validation logic must be updated continuously to stay accurate. Without a structured approach, these updates become a bottleneck—slowing down releases and introducing undetected data quality risks.

Continuous testing addresses this problem by executing automated tests as part of the delivery pipeline. The goal is to provide immediate feedback on business risks associated with a release candidate before it reaches production. In the data world specifically, continuous testing means triggering automated data validation tests from pipeline events and surfacing failures early—when they are cheapest to fix.

A key constraint: continuous testing cannot be implemented without test automation. Manual query execution and spot-checking do not scale to the frequency of modern CI/CD pipelines.

QuerySurge for DevOps: An Overview

QuerySurge is a data testing solution designed to automate data validation against critical data stores, including data warehouses, ETL outputs, and big data platforms. The QuerySurge for DevOps release extends the core platform with a comprehensive REST API layer, enabling teams to drive all aspects of their data testing programmatically—without requiring manual interaction with the QuerySurge UI.

With this API-first approach, testers and pipeline engineers can dynamically generate, execute, and update tests and data store connections using standard API calls, making QuerySurge a first-class citizen in any DevOps or DataOps pipeline.

API Capabilities

QuerySurge for DevOps exposes more than 60 API calls covering nearly 100 distinct properties. The API enables the following operations:

• Create and modify source and target test queries — build or update validation queries without touching the UI.
• Create and modify data store connections — programmatically register new databases, warehouses, or file sources as connection targets.
• Create and modify tests within an execution suite — assemble and adjust test suites as part of a pipeline step.
• Create and modify staging tables — generate staging structures from various data connections to support comparison testing.
• Create custom flow controls based on run results — branch pipeline logic based on test pass/fail outcomes.
• Integration with virtually all build solutions in the market — connect to existing CI/CD toolchains through standard API calls.

Integration Targets

QuerySurge for DevOps is designed to plug into the tool categories that already exist in most enterprise DevOps stacks:

• Continuous integration and ETL orchestration solutions
• Automated build, release, and deployment pipelines
• Operations and DevOps monitoring platforms
• Test management and issue tracking systems
• Scheduling and workload automation solutions

This breadth of integration means QuerySurge can be triggered by an ETL job completion event, a deployment pipeline stage, or a scheduled workload manager—whichever model fits your architecture.

Key Use Cases

Intelligent Test Execution

When changes are made to the data environment, custom pipeline code can call the QuerySurge API to generate on-demand tests scoped specifically to the changed areas. Rather than running an entire regression suite every time, this approach minimizes test case creation and execution overhead while still validating the affected data paths.

Requirements-Driven Test Updates

When a requirements management system receives and approves a change, downstream automation can call the QuerySurge API to automatically update any affected test queries to reflect the new business rules or mapping logic. This keeps tests synchronized with requirements without manual rework.

New Environment Deployments

As new environments are provisioned in the DevOps pipeline—development, QA, staging, or production—pipeline code can use the QuerySurge API to register new data store connections for those environments and configure the appropriate test suites to execute against them automatically. This eliminates manual environment setup steps that are prone to error and delay.

Result-Driven Testing

Test execution flow can be controlled based on the outcomes of previous runs. Using the QuerySurge API, pipelines can auto-select the optimal test sets based on result criteria—for example, running a targeted deep-dive suite only when a broad smoke test detects anomalies. This prioritizes testing effort where it is most needed.

DataOps and the Broader Pipeline

Together, these capabilities support what is increasingly referred to as DataOps—applying DevOps principles of automation, continuous feedback, and pipeline integration to the data engineering lifecycle. By embedding data validation directly into the delivery pipeline rather than treating it as a separate, manual QA phase, teams can:

• Catch data quality issues at the point of origin rather than downstream.
• Increase the percentage of automated coverage across the data estate.
• Reduce the manual effort required to maintain test suites as data environments evolve.
• Provide auditable, pipeline-generated evidence of data quality for compliance purposes.

QuerySurge for DevOps positions data testing as a first-class pipeline concern rather than an afterthought—an important shift for organizations that depend on reliable data for business-critical decisions.

For more information, visit querysurge.com.

1. Misaligned Focus: Treating DevOps as a Tooling Problem

The most pervasive DevOps misconception is equating it with a set of tools. CI/CD platforms, container orchestrators, and monitoring stacks are powerful enablers, but they are not DevOps itself. Organizations that lead with tooling often automate broken processes and embed existing silos into their pipelines, making bad practices faster and harder to unwind.

Tools should follow culture and process decisions, not precede them. Before selecting a platform, teams need clarity on which workflows they are trying to improve and what outcomes they expect. The value of any tool is measured entirely by what the people using it achieve—not by the tool’s feature list or market reputation.

• What to do instead: Start by mapping your current software delivery value stream. Identify bottlenecks, handoffs, and waste. Then evaluate tools that address those specific constraints.

2. Confusing Speed with Value

A common misreading of DevOps is that its primary goal is raw delivery speed. Teams race to shrink cycle times and increase deployment frequency, sometimes shipping low-value or unstable features faster than the business can absorb them.

DevOps draws heavily from lean manufacturing principles: break work into smaller, independently releasable units so that each increment delivers real value and feedback. Smaller batch sizes naturally produce more frequent delivery, but the point is not frequency for its own sake. The point is that smaller batches are easier to test, easier to roll back, and easier to validate against business outcomes.

• What to do instead: Define value metrics alongside velocity metrics. Track things like customer satisfaction, defect escape rate, and mean time to recovery alongside deployment frequency and lead time.

3. Neglecting Continuous Improvement

DevOps is not a destination. Organizations that treat it as a one-time implementation project—standing up a pipeline and declaring victory—quickly find that the pipeline becomes a liability as requirements evolve and the surrounding ecosystem changes.

The feedback loops built into a mature DevOps delivery pipeline—from automated test results to production monitoring alerts to retrospective data—exist precisely to surface opportunities for improvement. Ignoring those signals or reviewing them only quarterly means the pipeline drifts further from optimal with each sprint.

Continuous improvement requires a cultural commitment: every stage of the pipeline, every team practice, and every process step should be subject to regular inspection and refinement. The faster improvement cycles run, the sooner teams compound the gains.

• What to do instead: Build short, regular retrospectives into every team cadence—not just quarterly reviews. Track pipeline metrics over time and set explicit improvement targets each sprint.

4. Dishonesty About Progress and Estimates

DevOps depends on fast, reliable feedback—and that requires accurate information flowing through the team. When individual contributors over-promise on timelines, mask blockers, or report tasks as complete before they are truly done, the downstream effects ripple across the entire pipeline. A single inflated estimate can misalign deployment windows, block dependent teams, and erode the trust that cross-functional collaboration depends on.

Psychological safety is a prerequisite here. Team members who fear blame will hide problems rather than surface them. Leaders who respond to bad news constructively—treating it as a signal to improve the system rather than punish the individual—create the conditions for honest reporting.

• What to do instead: Break tasks into small, estimable units. Normalize surfacing blockers early. Celebrate accurate estimation and early escalation as much as on-time delivery.

5. Assuming Change Will Come Easily

DevOps transformation is fundamentally an organizational change initiative. It asks development, operations, security, and business stakeholders to rethink long-standing boundaries, workflows, and incentive structures. Many teams underestimate this dimension and are surprised when engineers revert to familiar habits as soon as the pressure of a launch or an incident hits.

Resistance to change is not a character flaw—it is a predictable human response to uncertainty and additional cognitive load. Effective transformation programmes acknowledge this explicitly, invest in change management, provide adequate training, and build early wins that demonstrate the value of new practices to skeptical team members.

• What to do instead: Treat culture change as a first-class work item. Identify internal champions in each team, communicate the rationale for changes clearly, and make it easier to follow new processes than to fall back on old ones.

Conclusion

DevOps transformation fails not because the principles are flawed, but because organizations underestimate the cultural, process, and measurement discipline required to make them work. Misaligned tooling focus, confusing speed with value, skipping continuous improvement, tolerating inaccurate reporting, and underestimating the difficulty of change are all addressable problems—but only if they are acknowledged first.

Use this list as a diagnostic checklist. If any of these patterns are present in your current transformation, they are worth addressing before investing further in tooling or headcount. Fixing the fundamentals consistently delivers better long-term outcomes than layering more technology on top of an unstable foundation.

The Manager–Developer Perception Gap in DevOps

If your DevOps implementation feels like it is working brilliantly in the boardroom but struggling on the ground floor, you are not alone. GitLab’s 2018 Global Developer Report — based on responses from 5,296 development professionals — uncovered a striking disconnect between how managers and developers assess the success of DevOps at their organizations.

According to the survey data:

• 81% of managers said DevOps was saving the company time, while only 65% of developers agreed.
• 47% of managers believed their organization could deploy code on demand or multiple times a day, but only 35% of developers shared that view.

Ashish Kuthiala, then Director of Product Marketing at GitLab, summed up the finding plainly: “Managers are focused on saving time and things getting better, but developers see the day-to-day challenges and that they’re still in silos and that needs to change. In a lot of companies, code is still being passed from one team to another.”

This gap is not simply a morale problem — it has real consequences for prioritization, tooling investment, and how quickly organizations can identify and fix broken processes.

The Three Toughest DevOps Implementation Challenges

The report identified three perennial pain points that continue to slow DevOps adoption:

1. Choosing the right technology — cited by 39% of respondents as the single biggest hurdle.
2. Integration concerns — getting disparate tools and systems to work together reliably.
3. Poor internal processes — long-standing organizational habits that resist change.

The tooling problem deserves particular attention. Kuthiala noted that the sheer number of available tools has become its own obstacle: “Developers are spending a lot of time focused on getting the tools they have to actually work. It’s kind of a badge of honor for them, but it takes away from valuable time spent coding.”

When asked to name their most critical tools, developers ranked these three at the top:

• A version control system (e.g., Git)
• An integrated development environment (IDE)
• A chat or collaboration tool

DevOps vs. Agile vs. Chaos: How Teams Describe Their Own Processes

When respondents were asked to label their own development methodology, the results were illuminating:

• 69% described their process as Agile
• 23% said DevOps
• 16% used Waterfall
• A notable portion chose “other” — and many of those respondents described their reality as “chaos”

The fact that Agile far outpaces DevOps as a self-descriptor suggests many teams are still treating DevOps as a distinct, separate practice rather than a natural evolution of Agile principles. For teams still in the “chaos” category, this data provides a useful mirror.

Where Development Bottlenecks Actually Occur

Consistent with findings from other DevOps industry surveys, testing emerged as the dominant bottleneck in the development pipeline. The full ranking from the GitLab report:

The prominence of testing at the top of this list is worth unpacking. Manual testing cycles, insufficient test coverage, and slow CI pipelines all compound to create delays that developers feel acutely — but that can be invisible to management dashboards focused on release cadence alone.

What High-Performing DevOps Teams Do Differently

Despite the challenges, the survey’s most actionable finding may be what separates high-performing DevOps teams from the rest. According to Kuthiala, the differentiator is not necessarily advanced tooling or large budgets — it is discipline around small, incremental changes.

“High-performing teams pay a lot of attention to one single small change and making sure that it works. That gets their confidence up, and that’s not something you see with lower-performing teams.”

— Ashish Kuthiala, GitLab

This aligns with the broader DevOps principle of reducing batch size and increasing deployment frequency — shipping smaller changes more often rather than large, risky releases. Success in small increments builds team confidence, which compounds into stronger Agile execution over time.

Practical Advice: Start Small, Iterate Fast

For organizations still hesitant to commit to a full DevOps transformation, Kuthiala’s guidance from the report remains relevant:

“It’s a journey and you’re not going to know if it works or not until you get started. Get it started, get going, learn from it, fail fast and keep improving. You don’t have to take organizations and break them up into DevOps teams. Just pilot out projects and see if DevOps works for you.”

— Ashish Kuthiala, GitLab

This is sound, practical advice. A pilot project approach allows teams to:

• Demonstrate measurable value to management without organizational disruption
• Identify tool and process gaps in a low-risk environment
• Build internal advocates who can champion broader adoption
• Establish baseline metrics before scaling practices across teams

Closing the Perception Gap: What Managers and Developers Both Need to Do

The manager–developer perception gap is ultimately a communication and measurement problem. Managers are often measuring outcomes (releases shipped, time saved at a high level) while developers are experiencing process friction day to day. Closing this gap requires:

• Shared metrics — agree on what “good” looks like using objective pipeline data: lead time, deployment frequency, mean time to recovery (MTTR), and change failure rate.
• Developer visibility — give developers a direct line to surface process pain points to leadership, not just through annual surveys.
• Realistic deployment benchmarks — if managers believe code is deploying on demand when developers know it isn’t, that discrepancy needs to be investigated, not papered over.
• Iterative culture — reward teams for learning from failures, not just for hitting release dates.

The data from GitLab’s 2018 report may be several years old, but the underlying dynamic — optimistic leadership, friction-weary developers, and tool overload — remains one of the most commonly reported challenges in DevOps transformations today.

TechRepublic’s Dan Patterson spoke with New Relic’s chief product officer Jim Gochee to explain how companies can improve the way they implement DevOps into their company culture. Below is a transcript of their interview.

Patterson: DevOps, a process that amalgamates software development and operations, is one of the most effective methods of iterative product development. But implementing DevOps, while it can aid your company’s digital transformation efforts, usually requires entire team buy-in. For TechRepublic and ZDNet, I’m Dan Patterson. We’re speaking today with New Relic chief product officer, Jim Gochee. Jim, what are a few best practices for CEOs looking to adopt DevOps as part of their digital transformation initiatives?

Gochee: Yeah, Dan, it’s great talking to you by the way. We see a lot of digital transformation projects and we get asked quite a bit how we do DevOps. I know that there’s a real hunger out there for best practices in this area. Right off the bat when I talk to an executive the first question I like to ask is, “Who’s taking the pager call?” I think this really more so than anything else tells me what stage of the journey they’re at, because in traditional operations you would have an operations team that was separate from the development team, and they were the ones that would take the pager if the site had an issue.

That doesn’t really scale that wall between operations and dev. So when you really look to do kind of peer DevOps, you want a development team also responsible for operating the service, and they should be the ones taking call. There’s many downstream positive things that happen when a development team is responsible for taking call, like they care more about the customer experience, they’re going to fix those issues that keep dragging things down, and they’re going to eventually start to move at a higher velocity. This is our thing, when teams move at a high velocity, they’re likely to introduce defects and bugs. And so the team that introduces those defects needs to be the team woken up at 2:00 a.m. in the morning to fix those defects. It’s really the only viable thing. So that’s why I start, “Who’s taking the pager call? Who feels that operational responsibility? Is it the ops team or is it the dev team?”

Patterson: What are some of the best ways of communicating the goals of DevOps from the C-level down to various decision makers within the organization, as well as communicating some of the end goals. I understand that Agile development is a part of DevOps, which has some of that communication built into the development process of software, but how do C-level executives communicate the goals across the team and remain consistent?

Gochee: There’s a couple things here. First, what we’ve seen is executives who need to make a cultural change, who need to change a culture usually have more success if they bring in a change agent into the organization who’s an executive under them, who’s done this before, and who can really go through a change management process of converting an older culture. One that’s not agile, one that doesn’t use DevOps, to a much more modern culture. That’s just in terms of how to get the organization ready to do this.

Once you have an organization that’s ready to do this, what we do is we have a master prioritization list across all of our teams. Our teams are Agile and we have about 47 separate teams at New Relic. But what we need to do is coordinate their activities, and make sure it’s aligned to what the business needs. We have a master prioritization list that the teams look at, and that way if we have a crosscutting project where every team has to do some work, we know we can get that work scheduled very quickly at the next iteration. The next brand for teams through this like being very explicit about the global priorities for the whole organization. If teams don’t have anything to work on in the global priority, then they’re free to go back to their own local priorities, making their own part of the product or system better against their own backlog.

Patterson: In your experience what are some of the problems, flaws,or road bumps in not just DevOps, but that companies could experience while implementing DevOps?

Gochee: There are many hurdles to overcome in a transformation. The biggest is culture, honestly. If you don’t have a culture of teams that want to move quickly, take responsibility for the pager, that right away is usually a bump along the way. And it can be a big one. More so than any one, I talk to our customers who are undergoing a transformation and they ask me on the cultural element “How do you do this? How do you get a culture where people want to try something new, and they want to do something differently?” So again, I think that’s where the change agent comes in.

Also, do teams want to instrument things and do they want to look at data, because if you’re making rapid iterations and changes to your software, and if you don’t have any instrumentation, then you’re flying blind. This is where New Relic comes in as an instrumentation company. We see those two things connected: The more you change things, the higher the likelihood something will break at some point.

With data, you can detect when that happens and you can roll a change back. But sometimes we see companies try to move fast without any instrumentation, and then they just get themselves into trouble and then you get the naysayers who may think, “Well, this is what you get for trying to move too fast. We told you it couldn’t be done.” So having that data to support teams is a critical part of being able to do DevOps and Agile, and move quickly.

Patterson: What resources are available to me? Where can I go to learn more and get started with DevOps and digital transformation?

Gochee: One of the books that I read recently that I would definitely recommend is the Google SRE book. It’s been out for a couple of years, and it really is probably only applicable as they lay it out to a company the size of Google, and so you have to sort of read it and read between the lines of how would it apply to me. But this whole site reliability engineer role, which Google kind of coined and I see a lot of companies using it, is very clearly spelled out in the book and is definitely a great read to sort of level set in terms of how modern operations DevOps can be done. I love that.

In terms of digital transformation I think there’s so many case studies being done right now. We put out white papers about the companies that we work with, and how they’re transforming. There’s a lot out there. I feel more sort of anything just looking on Google to see what’s being published, attending conferences, attending meetups, and networking with your peers who are also undergoing. Everybody’s undergoing some form of digital transformation right now, and so as an executive find your peers and have open dialogue with them. They’re probably struggling with some of the same things that you are as well, because I think there are very few companies that are sort of doing it really well at this point because it’s such a new and fast-moving thing.

The Collaboration Problem Inside Australian IT Departments

Australian businesses operating in an increasingly competitive technology landscape face a critical internal challenge: the people inside their own IT departments are not collaborating effectively enough. That is the central finding of a report published in 2017 by global recruitment firm Robert Half, based on independent research conducted with Australian chief information officers (CIOs).

CIOs surveyed rated the level of collaboration between IT professionals within their own departments at an average of 7 out of 10 — a figure Robert Half describes as indicative of a meaningful gap that many organisations still need to close. In a landscape where speed to market and cross-functional delivery are competitive differentiators, a 7-out-of-10 collaboration score leaves significant room for improvement.

“With IT being a very large functional area with many specialisations, the key to successfully leverage technology across the business depends highly on the level of effective collaboration that exists within the IT department.”

— Robert Half Australia report

DevOps as the Answer to Siloed IT Teams

Robert Half’s report positions DevOps adoption as the primary mechanism through which businesses can close that collaboration gap. DevOps — shorthand for Development and Operations — is a philosophy and set of practices designed to break down the traditionally siloed boundaries between software development, quality assurance, and IT operations teams.

Andrew Morris, Director of Robert Half Australia at the time of publication, described the rationale clearly:

“DevOps was created to promote a culture of collaboration by breaking down barriers within traditionally siloed IT departments and introducing an infrastructure that allows for integration between product management, software development, and operations — recognising the big IT picture and maximising its potential for the wider business.”

— Andrew Morris, Director, Robert Half Australia

The report notes that Australian companies are under increasing pressure to build, test, and release new or updated solutions faster than ever before. DevOps practices — including continuous integration, continuous delivery (CI/CD), infrastructure as code, and automated testing — are central to meeting that demand.

Adoption Gap: Nearly One in Three CIOs Without DevOps

Despite the growing awareness of DevOps benefits, the research found that 31% of Australian CIOs had not yet implemented a DevOps approach within their IT departments. This stands in contrast to the 63% of CIOs who had already implemented DevOps and were actively building on that foundation to drive further innovation.

This gap has direct business consequences. Organisations without DevOps practices risk slower release cycles, more brittle handoffs between teams, and reduced ability to respond to market changes — all of which compound over time as competitors with mature DevOps pipelines accelerate.

Top DevOps Implementation Challenges

The survey identified several specific barriers that Australian CIOs said were preventing or slowing DevOps adoption. These are worth examining in detail, as they reflect challenges that remain relevant for many organisations today:

• Sourcing the right skills (41%): The single biggest obstacle. Finding engineers with hands-on DevOps experience — spanning automation tooling, cloud platforms, scripting, and CI/CD pipelines — remains difficult in a competitive talent market.
• Lack of a defined DevOps strategy (38%): Organisations attempting to adopt DevOps without a clear roadmap often struggle to align tooling choices, team structures, and delivery goals.
• Lack of central governance (36%): Without agreed standards for pipelines, security controls, and deployment processes, DevOps practices can become inconsistent across teams and projects.
• Changing company culture and traditional hierarchies (36%): DevOps requires a shift from command-and-control management models to shared ownership and psychological safety. This is frequently cited as the hardest change to make.
• Enhancing collaboration within the IT team (27%): Even teams that adopt DevOps tooling often find that cultural and process changes — daily standups, blameless post-mortems, shared on-call responsibilities — take longer to embed.

The Skills Shortage at the Core

A thread running through all of these challenges is the shortage of experienced DevOps talent. Morris described this as a systemic issue:

“With digital evolution outpacing the supply of new IT skills, most of the challenges experienced by companies in relation to DevOps directly relate to a lack of talent in the area, and overcoming these challenges will be pivotal to leverage its success.”

— Andrew Morris, Director, Robert Half Australia

The report’s practical recommendation for employers is multi-pronged: attract DevOps talent by offering competitive salaries, retain existing staff through clear career development pathways, and supplement permanent headcount with experienced contract or temporary professionals during high-demand periods or transformation projects.

What This Means for DevOps Engineering Teams Today

Although this report was published in 2017, its core observations have aged well. The challenges of talent scarcity, unclear DevOps strategy, and cultural resistance to change continue to dominate industry surveys globally. Several practical takeaways remain relevant:

• Measure collaboration explicitly. If your organisation has not assessed how effectively development, operations, and security teams collaborate, run a structured internal review or use DevOps Research and Assessment (DORA) metrics as a baseline.
• Strategy before tooling. Implementing Jenkins, GitLab CI, or Kubernetes without a defined delivery strategy and clear ownership model will not resolve collaboration problems on its own.
• Invest in internal upskilling. Given persistent market shortages, training existing engineers in DevOps practices — automation, cloud-native architecture, observability — is often more reliable than competing purely on external hiring.
• Governance is not optional. Especially in regulated industries, establishing guardrails for pipeline security, secrets management, and deployment approvals early prevents costly technical debt later.
• Culture change requires leadership commitment. DevOps transformation stalls without visible sponsorship from CIO and CTO level. Technical practice changes alone are insufficient.

The Robert Half research is a useful snapshot of where Australian IT leadership stood on DevOps adoption in 2017. The gap between early adopters and laggards it identified has narrowed in many sectors, but the underlying challenges of skills, strategy, governance, and culture remain live issues for engineering organisations of all sizes.

Original source: itwire.com, September 2017. Research commissioned by Robert Half Technology Australia.

DevOps Awareness Does Not Equal DevOps Adoption

DevOps has become a widely recognized term in the software development and IT operations space, yet widespread recognition has not translated into widespread adoption. The Logz.io DevOps Pulse 2017 survey — released to coincide with SysAdmin Day — polled 700 companies to understand the state of DevOps adoption, implementation challenges, culture, and infrastructure trends.

One of the most striking findings: roughly 50 percent of respondents were either still in the process of implementing DevOps or had only completed implementation within the past year. For a practice that has been discussed and promoted since at least 2009, this figure underscores how significant the gap between awareness and practical adoption still was in 2017.

Top Challenges: Culture, Communication, and Silos

The survey identified three leading cultural challenges that organizations face when trying to establish DevOps practices:

• Shifting company incentives to change behaviors — Getting teams to align around shared goals rather than departmental metrics.
• Maintaining open communication and transparency — Breaking down the information barriers that naturally form between teams.
• Building flexible processes — Moving away from rigid, siloed workflows toward iterative, collaborative ones.

“These three actions — among others — are often tied to the fact that it is very hard to escape the typical silos that develop within companies and teams. Everyone and every team has a different way of working and a different set of priorities to address, and goals to meet.”

— Logz.io DevOps Pulse 2017 Survey

Organizational silos remain one of the most persistent obstacles to DevOps success. When development, operations, security, and QA teams operate with separate toolchains, incentives, and reporting structures, the collaborative culture that DevOps depends on becomes very difficult to establish.

The Biggest Barriers Are Practical: Time and Expertise

While cultural issues are significant, the survey found that the top two reported problems with DevOps implementation were more practical in nature:

1. Lack of time — Teams are already stretched thin managing existing systems, leaving little bandwidth to invest in transformation initiatives.
2. Lack of expertise — DevOps requires a broad skill set spanning automation, CI/CD pipelines, cloud infrastructure, monitoring, and cultural change management. Finding or developing that expertise is a real constraint for many organizations.

These barriers are interconnected: organizations without DevOps expertise take longer to implement practices correctly, which further compounds the time problem. This creates a cycle that is hard to break without dedicated investment and executive buy-in.

Burnout Is a Growing Concern

The pressure of DevOps transformation is having a measurable impact on individual practitioners. According to the survey:

• About 40 percent of respondents said they feel moderately under pressure at work on a day-to-day basis.
• Fewer than 10 percent reported feeling extremely pressured daily.
• However, 70 percent said they could see themselves burning out at some point.

This gap between current stress levels and anticipated burnout is notable. It suggests that while many practitioners are managing today, they do not see the current pace as sustainable — a warning sign for organizations that depend on retaining skilled engineers.

Cloud Infrastructure: The Rise of the Big Three

The survey also tracked infrastructure trends, specifically the growing dominance of the three major public cloud platforms: AWS, Microsoft Azure, and Google Cloud Platform.

Comparing year-over-year data from the DevOps Pulse reports:

• In 2016, 28 percent of respondents used a cloud platform outside of the Big Three.
• In 2017, that figure dropped to just 13 percent.

AWS continued to lead the pack in overall adoption. The consolidation around a small number of hyperscale providers reflects both the maturity of these platforms and the increasing availability of managed services that reduce the operational overhead of self-hosting or using smaller cloud vendors.

Cloud Cost Management Is a Priority

While the initial driver for cloud adoption was often cost reduction, the survey found that cloud spending remains a significant concern as infrastructure scales with the business. Respondents mentioned a variety of cost management approaches, including platform-native tools, third-party cost management platforms, and custom-built solutions.

Approximately 70 percent of respondents said their primary goal with cloud cost management was to optimize their environment — not simply to cut spending, but to ensure they were using cloud resources efficiently and appropriately.

Key Takeaways for DevOps Teams

• Adoption lag is real. Even in 2017, half of surveyed organizations were still in early-stage DevOps implementation. Transformation takes years, not months.
• Culture is hard, but practicalities are harder. Time and expertise constraints block progress even when cultural intent is present.
• Burnout risk is high. Sustainable DevOps transformation requires realistic workloads and organizational support for practitioners.
• Cloud consolidation is accelerating. AWS, Azure, and GCP are capturing an increasing share of enterprise infrastructure workloads.
• Cost visibility matters. As cloud spending grows with the business, investment in cost management tooling pays dividends in efficiency and predictability.

Source: SD Times reporting on the Logz.io DevOps Pulse 2017 Survey. Original article published July 29, 2017.

Read enough DevOps content and a pattern emerges: bold IT leaders, dramatic transformations, and teams that went from waterfall chaos to continuous delivery in what feels like a long weekend. The trades, blogs, and conference keynotes are stuffed with these stories.

What you almost never read about is the failures — the half-finished pipelines, the burned-out ops engineers, the reorgs that changed nothing except the org chart. That silence is a problem, because survivorship bias teaches us almost nothing useful. The hard lessons live in the struggles, not the highlight reels.

Here are some of the dirty secrets that DevOps practitioners know but rarely say out loud.

Most Companies That Say They Are “Doing DevOps” Are Not

Because DevOps success stories — real or embellished — filtered up to the C-suite, “we should be doing DevOps” became a standard executive directive. The practical result in many organisations was straightforward: rename the Infrastructure or Operations team “DevOps”, cut headcount to signal efficiency, and declare victory.

What actually changed in most of those cases? The nameplate on the door. Development and operations remained separate organisational units. Work still got thrown over the wall. A smaller, exhausted ops team was left holding the same legacy systems and the same dysfunctional processes, now with a trendier job title and fewer colleagues.

The only metric that visibly improves in this scenario is short-term personnel cost. It looks good long enough for someone to claim success before burnout and attrition spike and staffing costs climb back up — or higher. Real DevOps transformation requires changing how work flows through the organisation, not just what the team is called.

Fixing this requires influencing upward and sideways simultaneously. In organisations where leadership is not genuinely invested in the cultural and process changes, it can be more productive to move on than to fight indefinitely. This is an uncomfortable truth, but it is a real one.

Implementing DevOps Is Genuinely Hard

At its core, DevOps is about people and process — getting different groups to collaborate effectively, eliminate unnecessary friction, and deliver value faster. The tooling (CI/CD pipelines, infrastructure-as-code, observability platforms) is actually the easy part. You can buy or build tools. Changing how humans interact with each other and with their work is orders of magnitude more difficult.

Development and operations teams have historically operated with different incentives and different definitions of success. Developers are often rewarded for shipping features; operations teams are rewarded for stability. Those incentives actively work against each other. Bridging that gap requires someone with rare skills in facilitation, empathy, and organisational influence — someone who can align groups with competing interests around a shared goal without generating lasting resentment.

Those people exist, but they are scarce. Most teams have at best one or two people with a talent for cross-functional alignment, and larger organisations often have structural barriers — reporting lines, budget silos, physical distance — that make collaboration the exception rather than the norm.

Then there is the process layer. Effective DevOps requires consistent, documented, and adhered-to processes: deployment pipelines with defined stages, incident response runbooks, on-call rotations, change management protocols. Most engineers tolerate process at best and resent it at worst. Getting a team to embrace process — not just tolerate it — requires demonstrating concrete personal and team-level value, which takes time and trust.

You Are Never Finished

There is no finish line. You cannot “achieve DevOps” the way you can ship a feature or pass a certification exam. DevOps is an ongoing practice — closer in nature to a fitness routine or a safety culture than to a project with a completion date.

What practitioners mean when they talk about DevOps success is that they have established a functional, continuously improving work system — a pipeline of value that is regularly measured and refined. That system requires active stewardship. Without someone championing the culture, enforcing the practices, and pushing for incremental improvement, the processes gradually erode. Entropy is relentless.

This has a practical implication for hiring and organisational design: if there is no internal champion with the mandate and the time to sustain DevOps practices, those practices will not survive turnover, leadership changes, or the next major incident. The champion role is not an optional luxury.

Why Top-Down Buy-In Is So Hard to Get — and Keep

Genuine DevOps adoption typically requires reorganising teams, revising incentive structures, and sustaining an ongoing case for investment across multiple business units. That is a hard sell internally, and it does not get easier once a transformation is underway.

Leadership buy-in at the start of an initiative often evaporates when progress feels slow or when a major incident diverts attention. Keeping executives meaningfully engaged — not just nominally supportive — requires a sustained internal communications effort. Framing DevOps in terms of business outcomes (lead time, deployment frequency, mean time to recovery, change failure rate) rather than technical implementation details tends to be more effective than the alternative, but it still requires consistent effort.

Claims of transforming IT in three months should be treated with scepticism. Either the scope was narrower than presented, the definition of “transformed” was generous, or someone is telling a story that fits the conference format better than it reflects reality.

What the DevOps Conversation Is Missing

A lot of DevOps content — articles, talks, vendor white papers — operates at a high level of abstraction. It tells you what to do (break down silos, automate everything, measure outcomes) without spending enough time on how to actually do those things in a specific organisational context, especially when the human and political obstacles are as significant as the technical ones.

Practitioners and evangelists can do better by being more specific about failure modes, more honest about how long real change takes, and more concrete about the interpersonal and political work involved. Selling DevOps with a consultant’s polish while glossing over the messy middle does a disservice to everyone trying to do it for real.

None of this is an argument against DevOps. The practices are genuinely valuable and the outcomes — faster delivery, better reliability, healthier engineering cultures — are worth the effort. But realistic expectations, honest conversations about what the work actually involves, and sustained organisational commitment are prerequisites, not optional extras.

Originally surfaced from dev.to (2017). The structural observations about organisational change remain applicable; specific tool recommendations and metrics frameworks have evolved significantly since publication.

Software delivery involves more than a single team or workflow. You have to integrate your teams and workflows — and keep them in sync with one another — if you want to embrace effective DevOps fully and succeed in building a reliable, repeatable delivery process.

Identifying Your DevOps Pipelines

The path to effective DevOps starts by identifying the various pipelines you have to work with. The exact type, number, and nature of your pipelines will vary from organization to organization, but a typical software delivery process might include the following:

• Architecture pipeline: Designs new features and defines system structure.
• Coding pipeline: Handles the implementation of new features.
• Quality assurance pipeline: Tests new features for technical stability and correctness.
• User experience pipeline: Evaluates changes for usability and user impact.
• Staging and build pipeline: Compiles, configures, and packages new code.
• Deployment pipeline: Pushes validated builds into production.

While some of these pipelines occur earlier in the software delivery lifecycle than others, they cannot always be neatly arranged in strict chronological order. Design may precede coding, but different kinds of testing often occur simultaneously. Staging and building may overlap with testing phases. There is rarely a straight line running from the first pipeline to the last.

For that reason, rather than thinking of your continuous delivery tool chain as a series of pipes connected end-to-end, think of it as one large pipe into which multiple smaller pipes feed — each contributing at different times and in different volumes.

Microservices and Continuous Delivery Tool Chains

In a microservices and container-based environment, the pipeline picture becomes even more complex. You may have multiple pipelines of the same type spread across your different microservices. For example, there might be several coding pipelines, each one associated with a particular microservice or bounded domain.

At the same time, other pipelines in a microservices environment might span all services. Usability testing is a good example: even if your application is decomposed into many microservices, end-to-end usability testing typically relies on a single pipeline that evaluates the complete user experience. Testing a single microservice in isolation does not make sense for usability purposes, since users interact with the full application — not individual services.

Understanding which pipelines are service-specific and which are cross-cutting is essential for designing a tool chain that scales with your architecture.

Integrating the Continuous Delivery Tool Chain

To build the most effective continuous delivery tool chain, you must ensure that all of your smaller pipelines feed into the overall delivery chain in the right order and at the right time. Your various DevOps pipelines are interdependent: if work from one pipeline flows downstream before another pipeline is ready for it — or if it arrives too late — your workflows will fall out of sync and delivery quality will suffer.

The following steps can help you integrate your pipelines in an optimized way:

1. Identify Independent Pipelines

Ask yourself which workflows can begin without depending on the completion of any other workflow. Software architecting, for example, is often the first step in the delivery process and can start independently. Identifying these free-standing pipelines lets you kick them off immediately without waiting for upstream work.

2. Identify Dependent Pipelines and Order Them

Determine which pipelines depend on others and the sequence in which they must be arranged. Architecture needs to be largely complete before coding begins. Coding needs to reach a stable state before quality assurance and usability testing can start. Map out these dependencies explicitly and arrange your delivery chain accordingly.

3. Identify Pipelines That Should Run in Parallel

Some processes — such as different categories of testing — can and should run concurrently. If parallel-capable pipelines are forced to run sequentially, you waste time and slow the overall delivery cadence. Identify where parallelism is safe and design your tool chain to exploit it.

4. Adjust Volume and Scale

Some pipelines involve larger teams and greater throughput than others. To keep the delivery chain operating smoothly, the capacity of each pipeline must be balanced with the demands placed on it by upstream pipelines. For example, if your coding pipeline produces a high volume of new code quickly, the downstream testing pipelines must be scaled to handle that volume — otherwise a bottleneck forms and slows delivery.

5. Keep Pipelines Flexible

Agility is a core part of the DevOps mindset. When designing your pipeline structure, build in flexibility. Maintain the ability to reassign team members between pipelines when scale needs to shift. Be prepared to add or remove pipelines as organizational priorities evolve. A rigid tool chain that cannot adapt will become an obstacle rather than an accelerator.

Conclusion

Building an effective continuous delivery tool chain requires thinking beyond the concept of a single pipeline. In any realistic environment — and especially in a microservices architecture — you must account for all of the individual, disparate workflows that collectively make up your software delivery process. Each of those workflows represents a distinct pipeline, and the health of your overall delivery chain depends on how well those pipelines are identified, ordered, parallelized, balanced, and kept flexible.

Start by mapping your existing pipelines honestly. Then work to understand their interdependencies, their throughput, and where they can run concurrently. That analysis is the foundation of a continuous delivery tool chain that can scale with your organization.

Originally sourced from theserverside.com.

1. Improve Company Culture First

In traditionally structured organisations, departments operate in silos — each team focuses on its own deliverables with little meaningful interaction with other groups. Development teams write code, operations teams keep systems running, and the two rarely collaborate until something breaks.

DevOps explicitly dismantles these silos. The goal is shared ownership of the entire software delivery lifecycle, from design and development through deployment and incident response. For this to work, organisations need to invest in cultural change alongside any tooling decisions.

Practical steps include:

• Cross-functional team structures: Organise around products or services, not functions, so developers and operations engineers share the same team and objectives.
• Blameless post-mortems: Treat failures as learning opportunities rather than occasions for blame, which encourages transparency and psychological safety.
• Soft skills development: Encourage empathy and active listening at every level. Technical skills alone do not produce effective collaboration.
• Management buy-in: Culture change is difficult without visible support from leadership. Managers must model the collaborative behaviour they expect from their teams.

2. Establish Clear Communication Channels

DevOps environments move quickly. Continuous integration and continuous delivery (CI/CD) pipelines can produce multiple deployments per day, and without clear communication, tasks pile up, context is lost, and mistakes compound.

Good communication in a DevOps context goes beyond team meetings. It includes:

• Shared dashboards and visibility tools: Give every team member real-time visibility into build status, deployment pipelines, and system health. When everyone can see what is happening, fewer decisions are made in isolation.
• Internal communications plans: Define how and where information is shared — whether that is a chat platform, a wiki, or a daily stand-up — and make those norms explicit so new team members can onboard quickly.
• On-call and incident communication protocols: Document escalation paths, runbooks, and alerting thresholds so that when an incident occurs, teams react efficiently rather than improvising under pressure.
• Async documentation: In distributed or hybrid teams, well-maintained documentation reduces dependency on synchronous communication and keeps everyone aligned.

Visibility is particularly important in environments where software is being planned, tested, and released continuously. When team members can observe changes as they flow through the pipeline, they can adapt quickly and catch issues early.

3. Invest in Monitoring and Continuous Feedback

One of the defining characteristics of DevOps is its emphasis on continuous improvement. Rather than a linear, waterfall approach where feedback arrives only at the end of a release cycle, DevOps creates tight feedback loops at every stage of development and operation.

Monitoring and feedback serve complementary roles:

• Operations monitoring: Track application performance, error rates, latency, and infrastructure health in real time. Alerting on meaningful signals — rather than noisy, low-signal alerts — allows operations teams to detect and resolve issues before they affect end users.
• Developer feedback: Automated testing, code review pipelines, and static analysis give developers rapid feedback on the quality of their changes before those changes reach production.
• User feedback: Metrics such as error rates, session drop-offs, and support ticket volumes provide a signal from real users that complements internal technical monitoring.
• Retrospectives and post-mortems: Structured reviews of both failures and successes help teams learn systematically rather than repeating the same mistakes.

The objective is to close the loop between what is built, how it performs, and what gets built next. Organisations that treat feedback as a first-class engineering concern tend to improve their delivery quality and speed over time.

4. Scale Gradually — Start Small Before Going Organisation-Wide

One of the most common mistakes in DevOps adoption is trying to transform the entire organisation at once. Moving too fast, before trust and new working habits are established, can create bottlenecks, resistance, and failed rollouts that set back the broader initiative.

A more effective approach is to start with a single team or product and use that experience to build a proven, repeatable model before scaling.

• Pilot with a willing team: Choose a team that is enthusiastic about change and has a manageable scope of work. Use their experience to identify what works and what needs adjustment before rolling out to other teams.
• Measure baseline metrics: Before the pilot begins, capture metrics like deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate. These give you an objective way to evaluate progress.
• Allow time for adjustment: Employees moving from a siloed culture to a collaborative DevOps model need time to build new habits and confidence. Rushing this process undermines trust and reduces the quality of the transformation.
• Document and share learnings: As the pilot team learns what works, document their processes, tooling choices, and cultural norms so those insights can be shared across the organisation as DevOps adoption expands.

Putting It All Together

Successful DevOps implementation is not a single project with a defined end date — it is an ongoing practice that evolves as teams, products, and organisations grow. Culture, communication, monitoring, and a disciplined approach to scaling are not one-time checkboxes; they are habits that compound in value over time.

Organisations that invest in these fundamentals — rather than focusing exclusively on tools and automation — are better positioned to deliver software reliably, respond to customer needs quickly, and build engineering teams that are genuinely effective under pressure.

Why DevOps Adoption Stalls

Many organizations recognize the value of DevOps in principle but struggle to translate that recognition into lasting change. Some teams never get started because they lack a clear definition of what DevOps actually requires — from their tools, their processes, and their people. Others launch a DevOps initiative only to watch it slow down under the weight of organizational friction, unclear goals, and cultural resistance.

According to Jan Schilt of GamingWorks, most of these struggles can be traced back to four concrete obstacles. Understanding what they are — and having a practical strategy to address each one — is the first step toward a successful DevOps journey.

The Phoenix Project: A Foundation for the Conversation

Before diving into the obstacles, it helps to understand the mental model that Schilt and many DevOps practitioners use as a reference point: Gene Kim’s novel The Phoenix Project.

The book follows Bill, an IT manager tasked with rescuing a critically over-budget and delayed IT initiative. Bill’s breakthrough comes when he applies manufacturing flow principles to IT work. His approach unfolds in three stages:

1. Flow: Visualize all work in progress. Make the pipeline visible so the team can see where work is moving and where it is stuck.
2. Feedback loops: Bring teams together across silos. Encourage quality to be addressed at its source rather than passed downstream. Each step in the flow should deliver value and return feedback to the previous step.
3. Continuous learning and experimentation: Build a culture where teams constantly improve based on what they observe, rather than following fixed procedures in a changing environment.

These three principles — flow, feedback, and continuous learning — map directly onto the obstacles that real organizations face when adopting DevOps.

The 4 Main Obstacles to DevOps Adoption

1. Genuine Cross-Functional Teamwork

DevOps requires assembling a team from multiple disciplines — development, operations, QA, security, and often the business side — all working together toward a single value stream. This is harder than it sounds.

Most organizations have deep-rooted functional silos. People are hired, evaluated, and rewarded within their discipline. Asking them to share ownership of a delivery pipeline with colleagues from other departments demands new skills: communication styles, shared vocabulary, mutual accountability, and a willingness to own problems outside one’s traditional remit.

Without genuine teamwork, DevOps squads become multi-department committees rather than integrated delivery units — and the friction between silos continues to slow delivery.

2. Building Real Flow in the Delivery Process

Understanding that work should flow is not the same as actually creating flow. Teams must map their value stream, identify bottlenecks, limit work in progress (WIP), and back all of this with strong visualization — typically a Kanban board or an equivalent tool that the whole team actively uses and trusts.

Without visible, managed flow, teams default to reactive, interrupt-driven work. Priorities shift constantly, context switching erodes productivity, and nobody has a clear view of what is blocking value from reaching the customer.

Practical flow work includes: holding daily standups focused on blockers, running regular retrospectives, and enforcing WIP limits even when stakeholders push back.

3. Embracing Continuous Experimentation and Learning

DevOps is not a destination with a fixed set of procedures to follow. It is an ongoing improvement journey in which teams continuously test hypotheses, measure outcomes, and adapt. This is profoundly uncomfortable for people and organizations that rely on documented processes and defined work instructions for predictability and audit compliance.

Teams that cannot tolerate uncertainty will resist the feedback-driven iteration that DevOps depends on. They will wait for perfect requirements, avoid deploying until every edge case is handled, and treat every failed experiment as an indictment rather than a data point.

Building psychological safety — the understanding that well-designed experiments that fail are valuable — is essential infrastructure for DevOps, just as much as a CI/CD pipeline is.

4. Applying Agile, Lean, and ITSM Principles in Practice

Most DevOps practitioners are familiar with Agile, Lean, and IT Service Management (ITSM) concepts in the abstract. The gap between knowing and doing is wide. Teams may understand Kanban theory but struggle to enforce WIP limits under pressure. They may know what a retrospective is supposed to achieve but run them as status meetings instead.

Translating management principles into consistent daily practice requires deliberate repetition, coaching, and experimentation in real conditions — not just classroom knowledge.

How to Overcome These Obstacles

Invest in Foundational DevOps Training

Start by ensuring the team shares a common language and baseline understanding. Foundational programs such as DevOps Foundation or DevOps Fundamentals courses establish that common ground. For teams ready to go deeper, more advanced programs cover how DevOps principles interact with organizational structure, service management, and measurement strategy. Pair any training with hands-on exercises — theory retained without practice decays quickly.

Choose a Low-Risk Value Stream to Start

Resist the urge to transform every team and every pipeline at once. Instead, identify a single value stream — a specific process, service, or customer-facing product — that carries lower risk and has a team of willing early adopters. A contained experiment with a motivated team produces tangible results and generates internal advocates who can coach other teams later.

Build Time for Learning into the Plan

No team gets DevOps right immediately. Schedules that leave no room for errors, retrospectives, or course corrections guarantee frustration. Plan deliberately for learning cycles. After each sprint or deployment window, run a retrospective: what worked, what did not, what will the team try differently next time?

Use Simulations to Accelerate Practical Understanding

One reason organizations like GamingWorks have developed DevOps simulations — such as one built around The Phoenix Project — is that real-world learning is slow and costly. A simulation compresses the DevOps learning curve into a controlled environment where teams can experience a realistic workload, build and manage a Kanban board, practice standups and retrospectives, apply automated testing scenarios, and feel the consequences of high WIP and poor flow — all without risking a production system.

Participants come away with experiential knowledge of what DevOps actually feels like in practice, not just what it looks like in a slide deck. That experiential grounding helps teams connect the principles to their own organizational context before they begin their live implementation.

Let Early Adopters Coach the Next Wave

Once the first value stream is working well, the team that went through it becomes your most credible internal resource. Engineers and operators who have solved real DevOps problems in your specific environment are far more persuasive coaches than external consultants. Structure a deliberate knowledge transfer program so that early adopters help onboard subsequent teams, reinforcing their own learning in the process.

Summary

DevOps adoption is not primarily a technology problem. It is a people, process, and culture problem. Addressing it requires honest diagnosis of which obstacles are most acute in your organization, a focused starting point, and the discipline to build learning into the process from day one.

1. Building a “DevOps Department”

One of the most counterproductive moves an organisation can make is creating a dedicated DevOps team that sits apart from both development and operations. DevOps is not a job title or an organisational unit—it is a cultural and operational model designed to break down silos between existing teams. Segregating DevOps practitioners into their own department recreates the exact silo problem DevOps is meant to solve. Instead, embed DevOps principles and practices across your existing development and operations groups.

2. Failing to Streamline Software and Systems

DevOps methodologies depend on systems that are well-understood and manageable. Bloated, overly complex applications with sprawling dependencies make continuous delivery pipelines fragile and slow. If your applications load slowly, crash frequently, or behave inconsistently across environments, no amount of DevOps tooling will compensate for that underlying instability. Before investing heavily in CI/CD pipelines or automated testing frameworks, audit and simplify your systems architecture first.

3. Treating Automation as the Whole Solution

Automation is a critical enabler of DevOps—but it is a means, not an end. Teams sometimes invest heavily in build automation, infrastructure-as-code, and deployment pipelines while leaving communication gaps between development and operations completely unaddressed. Automation without cultural alignment and process change produces faster delivery of poorly coordinated work. Tackle the human and process side of DevOps alongside the tooling.

4. Mishandling Deployment and Market Delivery

Shipping working software is only part of the equation. How that software reaches production—and how value is delivered to customers—matters just as much. A well-known cautionary tale is the Knight Capital Group incident, in which a flawed automated deployment led to the firm losing approximately $440 million in roughly 30 minutes in 2012. Robust deployment validation, feature flags, canary releases, and rollback procedures are not optional extras; they are essential risk controls for any serious delivery pipeline.

5. Neglecting the Feedback Loop

Continuous feedback is one of DevOps’s foundational principles. If monitoring data, incident reports, and user metrics are locked inside individual teams or dashboards that only certain roles can access, the feedback loop is broken. Every stakeholder—from developers to operations engineers to product owners—should have visibility into system health and deployment outcomes. Make metrics actionable and accessible so teams can respond quickly and learn continuously.

6. Allowing Ambiguous Leadership

DevOps transformations require clear direction. Teams need to understand their responsibilities, priorities, and how their work connects to broader organisational goals. Without decisive, communicative leadership, engineers are left guessing—leading to duplicated effort, contradictory decisions, and project drift. Leaders do not need rigid, unchanging plans; they do need to provide clear, adaptable direction and remove blockers so their teams can execute effectively.

7. Ignoring Compliance and Auditing Requirements

What works technically in one organisation may not satisfy the regulatory or compliance requirements of another. Industries such as finance, healthcare, and government face strict auditing obligations that must be designed into the delivery pipeline from the start—not bolted on afterwards. Involve compliance and audit stakeholders early in your DevOps planning. Identify regulatory constraints, required controls, and audit trail requirements before you build your pipelines, not after.

8. Setting Unsustainable Schedules

DevOps initiatives frequently coincide with aggressive delivery timelines, which can lead to engineers being chronically overloaded. Sustained overwork degrades code quality, increases incident rates, and drives attrition—none of which help your DevOps goals. Before committing to a delivery roadmap, honestly assess your team’s capacity. If workload genuinely exceeds available bandwidth, consider bringing in additional resource rather than burning out the people you depend on.

9. Creating Unrealistic Expectations

DevOps is a significant cultural and operational shift. Organisations that expect to transform overnight are setting themselves up for disappointment. In practice, a mature DevOps culture takes months or years to develop, and progress is rarely linear. Set incremental, measurable milestones—improved deployment frequency, reduced mean time to recovery, faster feedback cycles—and celebrate progress at each stage. Smaller, achievable goals maintain momentum and demonstrate value to stakeholders without overpromising.

Key Takeaways

• DevOps is a cultural model, not an organisational unit—avoid siloing it into a separate department.
• Simplify your systems before adding DevOps tooling on top of complexity.
• Automation amplifies your processes; fix broken processes before automating them.
• Build robust deployment safeguards to prevent costly production incidents.
• Make feedback loops visible and accessible to all stakeholders.
• Provide clear, adaptive leadership so teams can execute with confidence.
• Engage compliance teams from day one, especially in regulated industries.
• Protect team capacity—burnout is the enemy of sustained delivery performance.
• Set realistic, incremental milestones and measure progress against them.

Avoiding these mistakes won’t guarantee a flawless DevOps adoption, but it will significantly improve your odds of building a sustainable, high-performing engineering culture. The organisations that do DevOps well treat it as an ongoing journey of continuous improvement rather than a one-time implementation project.

The following seven dos and don’ts distil common lessons from enterprise DevOps transitions. They address people, process, and tooling — the three dimensions that must move together for DevOps to take root at scale.

1. DO Secure Executive Buy-In Early

A DevOps initiative that lives only inside the IT department will stall when it meets budget cycles, competing priorities, or organizational resistance. Business leaders need to understand why the transition matters — specifically how faster, more reliable software delivery ties directly to revenue, customer satisfaction, and competitive position.

Practical steps to secure executive sponsorship:

• Translate DevOps outcomes into business language: deployment frequency, mean time to recovery, and change failure rate are meaningful proxies for business risk and speed.
• Identify a senior sponsor who will champion the initiative in leadership forums.
• Set clear, measurable goals before the first conversation so executives have something concrete to evaluate.

2. DO Involve Everyone in the Transformation

DevOps is fundamentally a cultural shift. Organizations that focus exclusively on tooling — and ignore people and process — consistently underperform those that treat all three dimensions together.

Key principles for broad organizational involvement:

• Start small. Pilot DevOps practices with one or two willing teams before rolling out enterprise-wide. Small wins build momentum and surface problems at manageable scale.
• Create shared goals. Development, operations, QA, security, and business stakeholders should be working toward the same delivery objectives, not optimizing in isolation.
• Treat DevOps as a journey. Map the stages of maturity your organization expects to pass through — from ad-hoc automation to continuous delivery — so teams have realistic expectations and a visible roadmap.

3. DON’T Create a Separate “DevOps Team” Silo

One of the most common structural mistakes is standing up a dedicated DevOps team alongside existing Development and Operations groups. The intention is to accelerate adoption, but the result is usually a new silo that can be circumvented — or worse, exploited as a fast lane that bypasses the governance and quality practices in the other teams.

A more effective approach is to embed operations expertise directly into development squads or scrum teams. This creates shared ownership of reliability and deployment quality from the start. The transition is often resisted because engineers feel they are already stretched, but teams that make it work consistently report faster progress toward a functioning DevOps organization.

4. DON’T Assume DevOps Doesn’t Work in Complex Environments

A persistent misconception is that DevOps is only practical for small companies or greenfield applications. In reality, large enterprises with tightly coupled, interdependent systems arguably need DevOps principles more than startups, precisely because poor communication between teams causes the most damage at that scale.

The real risk in complex environments is not that DevOps fails — it is that organizations set unrealistic goals for how quickly they can achieve full automation and continuous delivery across hundreds of services. Set incremental targets, instrument progress, and adjust as you learn.

5. DO Empower Teams Across the Entire Delivery Path

Automation that stops at the Development or Integration environment delivers only a fraction of the potential value. The biggest gains come from extending automation through QA, Staging, Pre-Production, and Production — but doing so requires careful thought about risk, access controls, and compliance requirements.

A practical starting point:

• Select one software project and map every step in its release process, from design through production deployment.
• Identify all the people involved, all the handoffs, and all the manual approvals.
• Use this value-stream map to prioritize where automation delivers the most benefit and where human oversight remains necessary.

If teams feel restricted to automating only their slice of the pipeline, the initiative will stall in a permanent half-automated state that frustrates everyone without delivering the promised speed improvements.

6. DON’T Copy Another Organization’s DevOps Toolchain Wholesale

There is no universal DevOps toolset. The combination of tools, workflows, and practices that works for one organization may be poorly suited to another with different technology stacks, compliance requirements, team structures, or deployment cadences.

This does not mean rebuilding everything from scratch. Instead:

• Audit the tools and platforms you already operate. Many existing investments — CI systems, PaaS platforms, container runtimes — can be extended or reconfigured to support DevOps workflows rather than replaced.
• Identify genuine gaps and evaluate purpose-built tools for those specific needs.
• Expect to customize. Enterprise DevOps toolchains almost always require integration work and configuration that off-the-shelf setups do not provide.

7. DO Treat Security as a First-Class Concern — Not an Afterthought

Security is frequently the last item added to a DevOps implementation plan and the first thing blamed when something goes wrong in production. This reactive posture is expensive. Remediating a vulnerability discovered after deployment costs significantly more — in engineering time, reputation, and potential regulatory consequences — than catching it earlier in the pipeline.

Integrating security into the DevOps process (sometimes called DevSecOps) means:

• Including security requirements in sprint planning alongside functional requirements.
• Adding automated security scanning (static analysis, dependency checks, container image scanning) to the CI/CD pipeline so vulnerabilities are caught on every code change.
• Involving security engineers in architecture reviews and incident retrospectives, not just penetration tests before release.

Putting It All Together

Enterprise DevOps succeeds when organizations treat it as a long-term transformation of culture, process, and tooling — not a one-time project with a go-live date. The seven principles above share a common thread: DevOps at scale requires deliberate, incremental progress across all three dimensions, with realistic goals, broad ownership, and a relentless focus on the full delivery path from code commit to production.

The competitive reward for getting it right — faster time to market, higher deployment frequency, and lower change failure rates — justifies the investment. Organizations that approach the journey methodically are far more likely to reach that destination than those looking for a quick tooling fix.

Stop Over-Planning and Start Doing

One of the most common reasons DevOps transformations stall is analysis paralysis — teams spend months building roadmaps, gaining buy-in, and defining processes before a single thing changes. According to practitioners who have actually done it, that is the wrong approach.

Steven Armstrong, principal DevOps automation engineer at Paddy Power Betfair, speaking at Computing’s DevOps Summit, was direct when asked how he launched his organisation’s DevOps initiative: “We were just able to do it.”

Armstrong’s advice: identify a genuine pain point — a single point of failure, a fragile deployment pipeline, a manual process that blocks releases — and start there. “Pick something like that, the low-hanging fruit, and go for it. Pick something and just start on it; don’t spend a hideous amount of time in planning,” he said.

What “Low-Hanging Fruit” Actually Means in Practice

The low-hanging fruit principle is about identifying work that is:

• High-pain: Something that visibly slows the team down or causes repeated incidents.
• Self-contained: A change that can be made without requiring a full organisational restructure first.
• Demonstrable: Something that, once improved, produces a measurable outcome stakeholders can see.

Armstrong’s team targeted single points of failure in a legacy database architecture under their old system. Fixing a concrete reliability problem gave the team a visible win and built momentum for broader change — without requiring months of upfront justification.

This approach also reduces political risk. A small, targeted improvement is easier to fund, easier to execute, and easier to learn from than a sweeping transformation programme.

Shift Left: Embed QA in the Development Team

Beyond choosing where to start, Armstrong highlighted a structural change that had a significant impact at Paddy Power Betfair: embedding Quality Assurance (QA) engineers directly inside development teams, rather than maintaining a separate QA department that reacts to completed code.

This practice — commonly called shifting left — means quality is considered at the earliest stages of the development cycle, not bolted on at the end.

“You don’t want a situation where you have QA reacting to development changes. Then testing runs will fail because the devs introduced a new GUI or something. So we moved teams together and then when the devs were developing code, QA were embedded there to help at the point when they were defining the user story. So you’re writing the test criteria along with the requirements and design. That’s really important, because you can’t have siloed departments that are purely reactive any more.”

Steven Armstrong, Principal DevOps Automation Engineer, Paddy Power Betfair

In practical terms, this means QA engineers participate in story refinement sessions, contribute to acceptance criteria before a line of code is written, and write automated tests in parallel with development — not after a feature is declared “done” by the developer.

Separate QA Teams Are an Obstacle to DevOps Culture

Gordon Gracie, development team lead at insurer LV=, went further, arguing that the very existence of a separate QA function is structurally incompatible with a DevOps model.

“The biggest injustice you can have today is the idea of QA people in a separate role. Software engineers want to write great code. If the engineer is obsessed with quality, they’re also obsessed with testing that quality. Some people are experts in testing, but the idea of separate teams doing that work needs to be broken down. If you have that set up, you’re creating a culture that stops your engineers moving to a DevOps model.”

Gordon Gracie, Development Team Lead, LV=

Gracie’s point is not that testing expertise is irrelevant — it clearly is not. The concern is that when testing is institutionally separated from development, it creates a handoff boundary. That boundary introduces delays, miscommunication, and a diffusion of ownership over quality. Engineers pass code over a wall; testers find problems; code comes back. This cycle is fundamentally at odds with the fast-feedback loops that DevOps depends on.

Key Takeaways for Teams Starting a DevOps Initiative

1. Start with a real problem, not a framework. Find something that is causing pain right now — a flaky deployment, a manual handoff, a reliability bottleneck — and fix it. Don’t wait until you have a complete DevOps strategy.
2. Keep the first project small and visible. Early wins build trust and funding for larger changes. A contained improvement with a clear before-and-after metric is more valuable than a sprawling transformation with unclear outcomes.
3. Embed QA in the team from day one. Test criteria should be written alongside requirements, not after the code is complete. This is the practical meaning of shifting left.
4. Break down silos structurally, not just culturally. Telling separate teams to “collaborate more” rarely works. Physically or organisationally merging QA into delivery teams changes the incentives and the feedback loops.
5. Treat quality as an engineering responsibility. Testing expertise is valuable, but responsibility for quality should be shared across the whole team, not delegated to a separate function.

The Broader Lesson

DevOps transformations fail most often not because the technology is wrong, but because organisations wait for conditions to be perfect before they begin. They wait for full executive buy-in, a complete toolchain decision, or an agreed operating model. Meanwhile, the problems that DevOps is supposed to solve continue to compound.

The practitioners at Computing’s DevOps Summit offered a simpler operating principle: find the thing that hurts most, fix that thing, learn from it, and repeat. That is, in essence, what DevOps looks like in practice — not a destination arrived at through planning, but a habit built through iteration.

DevOps Adoption Is Growing—But So Are the Obstacles

As more organizations turn to DevOps to improve software delivery speed and team productivity, a consistent set of implementation challenges keeps surfacing. A survey of more than 2,000 IT industry executives conducted by Quali found that infrastructure bottlenecks, cultural friction, and tool sprawl are among the most cited barriers.

The survey highlighted a striking infrastructure gap: 54% of respondents reported no access to self-service infrastructure, relying instead on ticket-based provisioning systems that slow delivery and increase time to market. Only 23% said infrastructure could be provisioned in under 24 hours, while 33% said it takes up to a month—and 26% reported it takes even longer than that.

Torsten Volk, managing research director of hybrid cloud and infrastructure management at Enterprise Management Associates (EMA), summed up the root problem: “Despite the immense popularity of DevOps today, research data shows a general lack of central governance and automation when it comes to creating new application environments. This leads to pockets of developers using their favorite, often not well-integrated, DevOps tools.”

The survey also found that DevOps teams are using a mix of open source and commercial tools. The most widely adopted at the time of the survey included Jenkins (21% of respondents), Docker (16%), Puppet (14%), and Chef (13%).

Forrester analyst Diego Lo Giudice captured a broader truth about DevOps maturity: “Mastering DevOps isn’t only about innovating on the ‘cool’ technologies faster; it’s also about building the capabilities to perform modern application development across the board. The underlying cultural shifts, process improvements, and automation of DevOps build the foundation for development teams to mature to the next generation of modern software development.”

The Top 10 Barriers to DevOps Implementation

Based on the survey findings and guidance from Quali, here are the ten most common challenges IT executives identified—along with recommended approaches for overcoming each one.

1. Culture

Cultural resistance is consistently ranked as the top barrier to DevOps adoption. Siloed development and operations teams that are accustomed to separate workflows, separate goals, and separate accountability structures do not naturally converge without deliberate effort.

Solution: Build a collaborative culture with shared goals and shared ownership of outcomes. Identify internal DevOps champions—employees who understand the value of cross-functional collaboration and can model the right behaviors for their peers. Structural changes like shared on-call rotations, joint retrospectives, and unified KPIs help reinforce culture change over time.

2. Test Automation

Many teams invest heavily in CI/CD pipeline tooling while neglecting automated testing. The result is faster deployments that still break in production—undermining the very reliability DevOps is supposed to deliver.

Solution: Treat continuous testing as a first-class citizen in your DevOps pipeline, not an afterthought. Automated unit, integration, and end-to-end tests should run on every commit. Security testing (SAST, DAST, dependency scanning) must also be embedded into the pipeline from the start rather than bolted on later.

3. Legacy Systems

Older applications and infrastructure were not designed with automation or continuous delivery in mind. Integrating them into a modern DevOps workflow is one of the most technically demanding challenges teams face.

Solution: Include legacy infrastructure and applications explicitly in your DevOps planning—do not assume the model only applies to greenfield projects. Identify which legacy components can be wrapped with APIs, containerized, or gradually refactored. Accept that legacy coexistence is a long-term project and plan accordingly.

4. Application Complexity

Modern applications often span on-premises infrastructure, public cloud, private cloud, and containerized environments. This heterogeneity makes it difficult to standardize deployment pipelines and maintain consistent environments across the software lifecycle.

Solution: Address architectural decisions early. Evaluate whether your application architecture is compatible with your target deployment model—whether that is Kubernetes on cloud, VMs on-premises, or a hybrid combination. Retrofitting architecture decisions is far more expensive than making them upfront.

5. No DevOps Plan

Some organizations declare a DevOps initiative without defining what success looks like, who owns it, or how progress will be measured. Without a clear roadmap, DevOps efforts stall or fragment across teams.

Solution: Create a structured plan that includes milestones, designated project owners, and well-defined deliverables. Define measurable outcomes—such as deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate—so progress can be tracked and communicated.

6. Managing Environments

Maintaining consistent, reproducible environments across development, testing, staging, and production is a persistent pain point. Environment drift—where configurations diverge over time—causes bugs that are difficult to trace and reproduce.

Solution: Standardize and automate environment provisioning using infrastructure-as-code tools and, where appropriate, cloud sandboxing platforms. Environments should be treated as ephemeral and reproducible, not as long-lived snowflakes that accumulate manual changes.

7. Skills Gap

DevOps requires a broad and evolving skill set—spanning scripting, cloud platforms, containerization, monitoring, and security—that many existing team members were not hired to possess.

Solution: Invest in structured training programs and give engineers protected time to develop new skills. Standardize processes and establish common operational procedures so that institutional knowledge is codified rather than locked in individuals. Pair experienced DevOps practitioners with team members who are earlier in their learning curve.

8. Budget

DevOps tooling costs are frequently underestimated. Teams often plan around open source tools assuming the cost is zero, then discover that integration, operational overhead, licensing for enterprise features, and training add up significantly.

Solution: Build a realistic total cost of ownership (TCO) model that accounts not just for licensing but for integration complexity, staffing, training, and ongoing maintenance. Open source is not free—it shifts costs from licensing to operations. Include these factors when presenting budgets to leadership.

9. Tool Sprawl

The DevOps tooling ecosystem is vast. Teams often adopt tools organically—different teams choosing different tools for similar jobs—resulting in fragmented, poorly integrated toolchains that are difficult to maintain and that create inconsistency across pipelines.

Solution: Establish a governed toolchain strategy at the organizational level. Evaluate tools against clear criteria—integration capability, community support, security posture, and operational overhead—before adopting them. Consolidating tools may have an upfront cost but reduces complexity and maintenance burden over time.

10. Lack of Executive Support

DevOps transformations require sustained investment in people, tooling, and process change. Without executive sponsorship, these initiatives are vulnerable to being deprioritized when budgets tighten or competing projects arise.

Solution: Translate DevOps outcomes into business language that resonates with executive stakeholders—faster time to market, reduced incident frequency, lower cost of defects, and improved developer retention. Frame DevOps investment as a strategic capability rather than a technical preference. Early wins and measurable metrics are the most effective tools for building and maintaining executive buy-in.

Key Takeaways

• Infrastructure bottlenecks—particularly the lack of self-service provisioning—remain a major drag on DevOps velocity.
• Cultural and organizational challenges are as significant as technical ones; tool adoption alone does not create a DevOps culture.
• Test automation and security must be integrated into the pipeline from the start, not added after the fact.
• Legacy system integration requires explicit planning and should not be treated as out of scope.
• Tool sprawl and underestimated costs are common pitfalls; a governed toolchain strategy mitigates both.
• Executive support is a prerequisite for sustained DevOps transformation—and it must be earned through demonstrated, measurable outcomes.

DevOps implementation is a journey that spans technology, process, and culture. Understanding these barriers in advance—and planning deliberately to address them—significantly improves the likelihood of a successful, lasting transformation.

Why the Database Is Still DevOps’s Weak Link

Application code, infrastructure configuration, and deployment pipelines have all benefited enormously from DevOps practices: version control, automated testing, continuous integration, and continuous delivery are now table stakes for most engineering teams. Yet the database frequently lags behind. Schema changes, migration scripts, and data integrity concerns are harder to automate safely than stateless application code, which means the database can become a bottleneck that undermines the speed gains DevOps delivers everywhere else.

Understanding why this happens—and what to do about it—is essential for any organization that wants a genuinely end-to-end DevOps practice.

How Things Used to Work (and Why It Broke Down)

Before DevOps, development and operations teams worked in silos. Release cycles were long, handoffs were manual, and the database was one of the last things touched before go-live. DBAs were responsible for implementing, testing, and recording every schema change—often in a single, high-pressure window at the end of a release cycle.

When DevOps accelerated application delivery, the release cadence increased dramatically—but the database workflow did not keep pace. DBAs suddenly faced a much higher volume of changes arriving far more frequently. Because the database sits at the end of the delivery pipeline, any slowdown there blocked the entire release train. DBAs were unfairly blamed for delays that were really a symptom of the database being excluded from DevOps practices in the first place.

What “DevOps for the Database” Actually Means

Incorporating the database into DevOps means applying the same disciplines used for application code to database changes:

• Database source control: All schema definitions, migration scripts, seed data, and stored procedures live in version control alongside application code. Every change is traceable, reviewable, and reversible.
• Automated build and migration: Tools execute database migrations as part of the CI/CD pipeline, the same way a build tool compiles and tests application code. No manual SQL scripts run directly against production without going through this pipeline.
• Automated verification: Integration tests validate that schema changes do not break application behaviour before code reaches a higher environment. This can include schema comparison checks, data integrity assertions, and performance regression tests.
• Environment parity: Development, staging, and production databases are kept in sync through the same migration process, reducing “works on my machine” failures caused by schema drift.

When these practices are in place, the DBA’s role shifts from being a manual gatekeeper to being an architect and guardian of database quality, with automation handling the repetitive execution work.

The Evolving Role of the DBA

DBAs occupy a unique position in a DevOps organisation. They understand both the internal mechanics of the database engine and the business implications of the data it holds. This makes them natural intermediaries between development teams (who need fast iteration) and operations teams (who need stability and compliance).

In a mature DevOps setup, the DBA typically:

• Defines and enforces database standards that development teams follow when writing migrations.
• Reviews pull requests that touch schema changes, just as a senior developer reviews application code.
• Designs and maintains the automated pipeline that validates and deploys those changes.
• Monitors database performance in production and feeds findings back into development practices.
• Manages compliance requirements (data retention, encryption at rest, access controls) that the operations team executes day-to-day.

Rather than being a bottleneck, the DBA becomes a force multiplier—enabling development teams to move quickly without sacrificing data safety.

Getting the Culture Right

Technology is only part of the answer. Organizational culture determines whether database DevOps succeeds or stalls.

Break Down Silos

DBAs, developers, and operations engineers must share responsibility for the health of the data tier. This means embedding database expertise in cross-functional product teams rather than keeping DBAs in a separate, centralized group that fields tickets from everyone else.

Leadership Alignment

Engineering leadership—whether that is a CTO, VP of Engineering, or CIO—needs to understand that database changes are code changes. Treating them differently (for example, requiring separate change-advisory-board approval for every migration while application code ships continuously) creates exactly the bottleneck DevOps is meant to eliminate. Leaders should invest in tooling and training that bring database changes into the standard pipeline.

Shared Ownership of Incidents

When a bad migration causes an outage, the post-mortem should involve the full team—not single out the DBA. Blameless retrospectives encourage teams to improve the pipeline rather than assign individual fault.

Embracing Database Automation Safely

A common objection to database automation is risk: databases hold live, stateful data, and a bad migration can cause data loss or corruption that is much harder to roll back than a bad application deployment. This concern is legitimate but manageable.

Safe database automation typically relies on several practices working together:

• Versioned, incremental migrations: Each migration script represents a single, small, forward-only change. Tools such as Flyway and Liquibase (widely used at the time of this article’s original publication and still actively maintained) track which migrations have been applied to each environment.
• Backward-compatible changes: Schema changes are designed so that both the old and new versions of application code can run against the database simultaneously. This enables blue/green and rolling deployments without downtime.
• Automated rollback procedures: Where possible, complementary rollback scripts are written and tested alongside the migration itself.
• Pre-production testing: Migrations are executed against a copy of production data (appropriately anonymized) in a staging environment before they are applied to production.
• Automated backups before migration: The pipeline triggers a verified backup immediately before applying changes to production, providing a recovery point if something goes wrong.

When these safeguards are in place, database automation reduces risk compared to manual processes—manual execution is where human error most often occurs.

Signs Your Organization Is Getting It Right

Use the following checklist as a quick diagnostic:

• Database schema and migration scripts are stored in the same version control repository as application code—or a closely integrated one.
• Every environment (development, CI, staging, production) is brought to its current state by running the same migration pipeline, not by manual scripts or restores.
• DBAs participate in sprint planning and pull-request reviews, not just in end-of-sprint release gates.
• A failed migration in CI blocks the build, the same way a failing unit test does.
• Database deployments can be triggered by the same CI/CD tooling used for application deployments, with appropriate approvals built into the pipeline.
• Performance baselines are tracked and regression alerts are automated.
• Compliance controls (access logging, encryption, retention policies) are enforced programmatically, not by manual checklists.

Conclusion

A slow or poorly managed database is a ceiling on the speed and reliability of your entire software delivery process. Bringing the database fully into DevOps—through version control, automated pipelines, cultural integration of the DBA role, and safe automation practices—removes that ceiling and turns the data tier into an asset rather than a liability.

The core principle is straightforward: treat database changes as first-class code changes, with all the same tooling, review, testing, and automation that entails. Organizations that do this consistently will find that their DBAs spend less time firefighting and more time on the higher-value work of schema design, query optimization, and data architecture—work that directly supports business outcomes.

The Container Assumption in DevOps

One of the primary goals of a DevOps approach to software delivery is eliminating bottlenecks in your production deployment pipeline. For server-side software, those bottlenecks typically involve several interrelated layers:

• The application environment, including operating system parameters and configuration
• Third-party components such as application servers, web servers, and databases
• Your own application software that runs on top of all of the above

DevOps addresses these bottlenecks by breaking down barriers between development and IT operations teams, fostering a collaborative environment where both groups share responsibility for keeping production and development environments in sync. Containers—Docker being the most prominent example—have proven to be an excellent tool for achieving this alignment. They work so well in this context that containers and DevOps have become almost synonymous in many organizations, to the point where some teams treat containers as a prerequisite for DevOps adoption.

That dependency, however, is not required. You can implement a mature, effective DevOps practice without containers. Here is how.

Why Containers Are Useful—But Not Mandatory

Before arguing against the dependency, it is worth understanding why containers appeal to DevOps practitioners in the first place. Containers are lightweight OS-level abstractions that isolate running processes, restrict resource usage, and package software dependencies together in a portable unit. Unlike full virtual machines, containers operate closer to the application layer rather than the hardware layer, which makes them significantly more efficient to spin up and tear down.

Containers shine in specific DevOps scenarios:

• Microservices architectures, where individual services need to be deployed, scaled, and destroyed independently and frequently
• Agile dev/test cycles, where short-lived, reproducible environments reduce inconsistency between developer laptops and CI pipelines
• Cloud-native deployments, where ephemeral infrastructure benefits from the fast startup times containers offer

When developers build and test inside a container, the entire runtime environment can be packaged and shipped to production servers with high confidence that behavior will be consistent. That efficiency directly supports DevOps goals. Even so, containers are a tool that serves DevOps principles—they are not the principles themselves.

Legitimate Reasons to Avoid Containers

There are real-world situations where a containerized deployment approach is impractical or inappropriate:

• Skill gaps: Container expertise requires meaningful investment in training and tooling. Teams without that foundation may introduce new risks rather than reduce them.
• Performance-sensitive systems: Real-time systems or applications with strict latency requirements may be negatively affected by container overhead or networking abstractions.
• Unsupported environments: Embedded systems, specialized legacy operating systems, or proprietary hardware may not support container runtimes at all.
• Regulatory or compliance constraints: Some environments impose restrictions on how software is packaged or isolated that conflict with standard container tooling.
• Existing infrastructure investment: Organizations with mature, stable bare-metal or VM-based infrastructure may gain little from containerizing proven deployments.

In any of these cases, pursuing containers for their own sake risks adding complexity without proportional benefit. The good news is that the core of DevOps does not depend on them.

Three Enablers of DevOps Without Containers

Whether you are working with a mainframe, a monolithic application, a legacy enterprise system, or a cloud-native microservice, the following three practices form the foundation of any DevOps implementation:

1. Automation

Identify every manual step in your build, test, and deployment pipeline and work systematically to automate it. Manual steps are the primary source of inconsistency and error in deployment processes. Tools exist across every technology tier—from configuration management tools like Ansible, Chef, and Puppet for infrastructure provisioning, to shell scripts and CI servers for build orchestration. The goal is not to automate everything at once but to reduce human intervention at each stage progressively.

2. Continuous Integration

Integrate software modules, components, and services together continuously throughout the development cycle—not just before a major release. A CI server (Jenkins, GitLab CI, GitHub Actions, and similar tools) can trigger automated builds and unit tests on every code commit. This surfaces integration problems early, when they are cheap to fix, rather than allowing them to accumulate into a painful, high-risk integration event at the end of a release cycle.

3. Continuous Testing

Testing must be a continuous activity, not a phase that happens after development is complete. With continuous integration in place, every build should be verified against a growing suite of automated tests—unit, integration, and where feasible, end-to-end. The aim is for the system to be theoretically releasable at any point. This creates a fast feedback loop that tells developers—immediately—whether a change breaks something downstream.

The Three Organizational Practices That Drive Results

Specific tools help, but the biggest gains from DevOps come from sustained organizational behavior changes. Three practices matter most:

1. Constant build-and-test cycles: Software is never developed in isolation for extended periods. Small increments are built, tested, and validated continuously.
2. Frequent deployments to production-like environments: Deploying often to staging or pre-production environments that mirror production closely means deployment itself becomes routine rather than a high-risk event.
3. Immediate feedback loops back to developers: When something breaks in integration, test, or deployment, developers hear about it right away. Delayed feedback allows problems to compound and context to be lost.

Together, these practices ensure that development and operations teams continuously verify that what is being built will actually deploy and operate as expected in production. Because integration, testing, and deployment activities happen in parallel from the start—rather than in sequential phases—there are no late-stage surprises and no blame-shifting between teams when things go wrong at release time.

People and Communication Are the Real Foundation

Tools, including containers, are enablers. The actual foundation of a successful DevOps implementation is people, communication, and metrics. A team with strong collaborative habits, shared ownership of deployment quality, and clear visibility into system health will outperform a team that has adopted every fashionable tool but operates in organizational silos.

When crunch time arrives—and it always does—the teams that have practiced continuous integration, continuous testing, and frequent deployments throughout the development cycle will not be scrambling to understand what their deployment process does. They will already know, because they will have effectively been deploying all along.

This is why DevOps is described as a practice rather than a process, toolset, or job title. Containers can be an excellent addition to a DevOps practice, particularly for managing application environments at scale. But they are not the starting point. Focus on the practice first—automation, continuous integration, continuous testing, and collaborative culture—then adopt containers where they genuinely solve a problem you have.

Key Takeaways

• Containers support DevOps goals efficiently but are not a prerequisite for DevOps adoption.
• Legitimate technical, organizational, and regulatory constraints may make containers impractical in your environment.
• Automation, continuous integration, and continuous testing are the non-negotiable pillars of any DevOps implementation, with or without containers.
• Organizational behavior—frequent deployments, fast feedback, and cross-team collaboration—delivers more DevOps value than any single tool.
• Adopt containers where they solve a real problem; do not adopt them simply because the industry has conflated them with DevOps itself.