This article breaks down the most common challenges teams face when implementing DevOps models, and offers practical guidance for overcoming each one.

1. Scaling DevOps Across the Organization

DevOps is often straightforward to pilot in a single team or product line, but scaling it across a larger organization is a different challenge entirely. Processes that work well for ten engineers rarely translate automatically to hundreds.

Tip: Run a controlled pilot on a representative product team before rolling out org-wide. Use the pilot to identify gaps in tooling, training, and workflow, then document what worked and what did not before expanding. A phased, evidence-based rollout reduces risk and gives other teams a concrete playbook to follow.

2. Budgeting Realistically for DevOps Adoption

DevOps transformation carries real costs: new tooling, training, consulting, temporary productivity dips during the transition, and ongoing platform maintenance. Teams that treat DevOps as a zero-cost culture shift often run into trouble when unexpected expenses arise.

Tip: Build a dedicated DevOps budget that includes a contingency buffer. Account for tool licensing, CI/CD infrastructure, security tooling, training programs, and the engineering time required to migrate legacy pipelines. Getting finance and leadership aligned on realistic costs early prevents mid-project funding crises.

3. Keeping Management and Stakeholders Engaged

DevOps requires organizational alignment, not just technical changes. Operations teams often have lengthy change-management procedures that create bottlenecks, while development teams following Agile methodologies expect rapid iteration. Without active stakeholder involvement, these friction points grow.

Tip: Ensure management participates throughout the product lifecycle, not only at launch. Regular demos, sprint reviews, and visibility into deployment frequency and lead-time metrics help stakeholders understand progress and stay invested. When leaders are visibly supportive, cross-team cooperation follows more naturally.

4. Dealing with Legacy Infrastructure and Systems

Legacy applications and infrastructure are among the most cited blockers to DevOps adoption. Tightly coupled monoliths, unsupported operating systems, manual deployment processes, and outdated hardware all make automation and continuous delivery significantly harder.

Tip: Conduct an honest infrastructure audit before starting. Identify systems that can be containerized or wrapped with APIs, systems that need modernization, and those that may need to be replaced entirely. A strangler-fig pattern — gradually replacing legacy components rather than big-bang rewrites — often reduces risk. Prioritize the parts of the stack that create the most friction in the delivery pipeline.

5. Breaking Down Organizational Silos

Silos between development, operations, security, and QA are one of the root causes of slow delivery and poor system reliability. DevOps cannot function when teams optimize only for their own metrics and hand off work over walls.

Tip: Create cross-functional teams that share ownership of both the build and the runtime. Shared on-call rotations, combined incident retrospectives, and joint planning sessions all reinforce collective responsibility. Avoid creating a “DevOps team” that acts as a separate silo — instead, embed DevOps practices within existing product teams.

6. Managing Resistance to Change

Not everyone welcomes a DevOps transformation. Engineers accustomed to infrequent, heavyweight releases may feel threatened by continuous deployment. Testers who rely on long manual test cycles may worry about their roles. This resistance is natural but must be addressed directly.

Tip: Communicate the why before the how. Show team members concretely how DevOps practices reduce toil, eliminate late-night emergency deployments, and give individuals more control over their work. Introduce changes incrementally rather than all at once. Invest in training so that no one feels left behind, and celebrate early wins publicly to build momentum.

7. Selecting and Integrating the Right Tools

The DevOps ecosystem offers a vast range of tools covering CI/CD, infrastructure-as-code, monitoring, secrets management, container orchestration, and more. Poorly chosen or poorly integrated tools create new complexity rather than reducing it.

Tip: Choose tools that integrate cleanly with your existing stack and meet your security and compliance requirements. Avoid adopting tools simply because they are popular — evaluate them against your specific workflow needs. More importantly, remember that tools enable good practices but do not create them. A team with weak collaboration and unclear ownership will not be saved by the latest automation platform. Culture and process must come first; tooling follows.

Key Takeaways

• Scale gradually: Pilot before rolling out broadly, and use evidence from the pilot to guide expansion.
• Budget honestly: Include tooling, training, infrastructure, and a contingency buffer.
• Engage stakeholders: Leadership buy-in and active participation are non-negotiable.
• Modernize incrementally: Legacy systems are a constraint to plan around, not ignore.
• Break silos structurally: Shared ownership and cross-functional teams are more effective than process mandates alone.
• Address change resistance directly: Communicate benefits clearly, train proactively, and move at a pace people can absorb.
• Right-size your toolchain: Integration, security, and team fit matter more than feature lists.

DevOps implementation is as much a human and organizational challenge as a technical one. Teams that address people, process, and technology together — rather than focusing on tooling alone — are far more likely to achieve sustainable, scalable DevOps adoption.

If businesses aren’t aggressive enough in their DevOps approach, they could be wasting their time and energy, according to a new survey from New Relic. According to the survey, companies that were all-in on DevOps saw better results, while those that adopted the approach with less gusto tended to run into some problems.

“It seems that partial DevOps adoption might be not just ineffective, but actually counterproductive,” the survey stated. Those with higher adoption rates saw a higher level of satisfaction with DevOps as well, the report said.

The real danger zone, according to the survey, was ending up with a moderate level of adoption. High DevOps adopters saw significant returns, the report said, but moderate adopters ended up worse off than those with “limited adoption.” So, businesses should be sure that they either stay in the “testing the waters” phase or dive fully into DevOps—don’t get stuck in the middle.

So, what are some of the key metrics that DevOps aims to improve? For starters, it’s team communication. In terms of improvements in that area, 57% of high DevOps users saw an improvement, compared to 21% of moderate DevOps users, and 23% of low DevOps users.

Of both high and moderate DevOps users, 30% saw an improvement in the length of their development cycle. This was more than double the 14% of low DevOps users who reported the same improvement.

Bug resolution was improved by 44% of high DevOps users, while only 18% of moderate DevOps users and 20% of low DevOps users claimed the same thing. Application uptime was also boosted among 44% of high DevOps users, while only 17% of moderate DevOps users and 22% of low DevOps users saw an improvement in that area.

Proper tools are key, but there is something that is even more valuable to a DevOps deployment: Engineers must be able to see the impact that DevOps is having in order to be fully on board with the process.

“If engineers can’t connect their DevOps efforts to measurable improvements in outcomes that matter for their job and their career, your DevOps initiative may stall, wasting your investment and even leaving you worse off than when you started,” the survey stated.

The 3 big takeaways for TechRepublic readers

1. A new survey from New Relic claims that would-be DevOps practitioners must go all-in, or risk an “ineffective” or “counterproductive” deployment.
2. If a business can’t become a high DevOps user, they should avoid moderate use of the practices, which can be more detrimental than limited use.
3. Engineers must be able to see the real results of DevOps for a deployment to be successful.

At a 2017 Dell EMC World conference breakout session, Emily Kaiser and Brian Roche from Dell EMC’s DevOps Dojo outlined seven critical lessons businesses encounter when putting DevOps into practice. Their insights remain highly relevant for any organization navigating a DevOps transformation today.

1. Define What DevOps Actually Means for Your Organization

Before a team can practice DevOps effectively, they need a shared, concrete definition of what it means in their context. Roche stressed the importance of clear communication and getting every stakeholder on the same wavelength so the team can unify around a common mission.

A common trap is measuring vanity metrics — lines of code written, number of commits — rather than outcomes that matter. DevOps practitioners should instead measure the real effect their work has on users and on team capability. Core operating principles include eliminating waste and investing in automation to support the cultural shift.

“At its heart, DevOps is a cultural movement. Businesses employ automation to support that movement.”

Brian Roche, Dell EMC DevOps Dojo

2. Know Why You Are Adopting DevOps

Organizations must be able to articulate a clear, honest answer to the question: why DevOps? Kaiser was direct: “DevOps is anything but comfortable.” The cultural transformation it demands is significant, and without a compelling reason, momentum will stall when friction arises.

Implementing DevOps means making everyone responsible for quality — not just QA engineers or release managers. Teams must develop shared context and genuine empathy for colleagues across development, operations, security, and the business. Critically, DevOps cannot succeed without buy-in at every level of leadership. Teams must learn to tailor the case for DevOps to different audiences: technical leaders, product managers, finance stakeholders, and executives all need a version of the argument that resonates with their priorities.

3. Build a Culture of User Obsession

In a mature DevOps practice, the end user is never an afterthought — they are the central reference point for every decision. Project scope, sprint priorities, and release criteria should all be evaluated through the lens of user value.

Kaiser and Roche recommended test-driven development (TDD) as a practical framework for embedding this mindset into daily engineering work. The TDD cycle — write a failing test, implement the minimum code to pass it, then refactor — keeps the team anchored to defined, verifiable behaviour rather than assumed requirements.

4. Recognize That Your Team Is the Glue

Technology alone does not make DevOps work. The people and relationships within the team are what hold a DevOps implementation together. Team leaders must actively invest in three areas:

• Empathy: Understanding where teammates are coming from — their constraints, pressures, and perspectives — reduces friction and blame during incidents.
• Feedback: Regular, structured feedback loops surface problems early and create opportunities to recognise success.
• Trust: Attending to how team members feel builds the psychological safety needed for honest communication and dependable collaboration.

The Dell EMC Dojo team used retrospectives as a formal mechanism for this. After each project, team members would come together to reflect on what they learned, what obstacles they faced, and what they would do differently — reinforcing empathy and continuous improvement as team habits rather than aspirational values.

5. Expect to Fail — and Build Systems That Make Failure Safe

Roche and Kaiser were candid: failure happens often. The goal is not to eliminate failure but to make recovering from it fast and learning from it systematic. Continuous delivery pipelines are the operational mechanism that makes this possible — by shortening the feedback loop between a change and its consequences, teams can detect and fix problems in minutes or hours rather than days.

A practical approach when starting out:

1. Identify the specific problem you are trying to solve.
2. Build a minimum viable product (MVP) for your DevOps practice — don’t try to implement everything at once.
3. Iterate: make incremental changes, learn from each cycle, and adapt.

6. Scale DevOps Deliberately, Starting with APIs and Mindset

As DevOps practices mature, scaling them across larger teams and more complex systems requires two parallel investments: technical architecture and cultural change.

On the technical side, Roche identified APIs as the foundational building blocks for scaling DevOps. Well-designed APIs enable services to be deployed, monitored, and updated independently — a prerequisite for the autonomous, fast-moving teams that DevOps enables.

On the cultural side, operators need to adopt a development mindset. This means:

• Treating infrastructure as code — version-controlled, peer-reviewed, and tested like application code.
• Automating repetitive operational tasks.
• Investing in health monitoring and observability so the team can detect and diagnose problems quickly.
• Developing empathy for developers, just as developers must develop empathy for operations.

Roche’s underlying point was that development and operations teams ultimately want the same outcome: reliable software running in production. Recognising that shared goal makes collaboration feel natural rather than forced.

7. Learn by Doing

No amount of training, certification, or documentation prepares a team for DevOps as effectively as actually practising it. Kaiser argued that hands-on experience deepens conceptual understanding and sharpens problem-solving skills in ways that passive learning cannot.

Agile and lean methodologies provide a structure for this approach. Short iterations, regular retrospectives, and a bias toward shipping working software over writing comprehensive plans all reinforce the habit of learning from real experience and adjusting course continuously.

Key Takeaways

The seven lessons from Kaiser and Roche share a common thread: DevOps is fundamentally a human and cultural endeavour that technology enables, not replaces. Organisations that treat DevOps as a tooling upgrade tend to stall. Those that address the cultural and collaborative dimensions — shared purpose, empathy, psychological safety, and continuous learning — are better positioned to realise its benefits at scale.

• Define DevOps clearly and consistently across your organisation.
• Build a compelling, audience-specific case for why DevOps matters.
• Keep users at the centre of every engineering decision.
• Invest in team relationships as seriously as you invest in tooling.
• Design systems and processes that make failure safe and recovery fast.
• Use APIs and infrastructure-as-code as the foundation for scale.
• Prioritise hands-on, iterative learning over theoretical preparation.

Source: Original reporting based on a breakout session by Emily Kaiser and Brian Roche, Dell EMC DevOps Dojo, at Dell EMC World 2017, as covered by TechRepublic.