That last group is often the trickiest to bring on board. Understanding why middle managers resist, and addressing those concerns directly, is essential to a successful DevOps rollout.

“DevOps teams are self-directed, meaning they plan their own work, decide who does what, and provide day-to-day feedback to each other. These have traditionally been activities performed by a line or functional manager. When middle management attempts to still do these activities in DevOps, conflict arises… Middle managers do not ‘own’ staff any longer in a DevOps model, but without a proper definition of roles, team members will not know who to listen to.”

— Jeffery Payne, CEO, Coveros

When DevOps teams and middle management are at odds, culture, morale, and delivery results all suffer. But middle managers do not have to be DevOps Enemy No. 1. The following five strategies — drawn from practitioners who have navigated this challenge — can help you get everyone moving in the same direction.

1. Ease the Fear of Unknowns With Data

Every configuration change, deployment, and upgrade introduces unknowns. Those unknowns translate to increased risk of instability, which in turn creates pressure for a slower, more controlled pace of change. This puts a middle manager in an unenviable position: holding their team accountable to delivery goals that feel directly at odds with stability goals.

Left unresolved, this tension can erode trust. Engineers may begin to view management as disconnected from the realities of operating complex systems, and teamwork can deteriorate as a result.

The solution is observable, reliable data about system behavior. Specifically:

• Instrument every layer of your system. Telemetry data — metrics, logs, and traces — for each component helps identify high-risk areas before changes are made.
• Use error budgets. An error budget (a concept from Google’s Site Reliability Engineering practice) gives teams and managers a shared, quantifiable framework for deciding when to slow down and when to accelerate safely.
• Make data visible to managers, not just engineers. Dashboards that surface deployment frequency, change failure rate, and mean time to recovery give middle managers objective grounding for their conversations with both leadership and their teams.

Quantifiable understanding of system behavior transforms stressful conversations based on assumptions into productive discussions about an acceptable balance between stability and velocity.

2. Help Teams Find a Win — Quickly

Middle managers who resist DevOps are not necessarily bad actors. More often, they do not yet understand the benefits, they are focused on the risks, or they simply distrust change without evidence. The most effective counter to skepticism is a concrete, measurable win.

Before trying to persuade doubters organization-wide, identify one application that all key stakeholders want to see improved. Run a full DevOps cycle on that application — from code commit through to production deployment — and capture before-and-after metrics: deployment frequency, lead time for changes, defect rates, and rollback frequency are all useful KPIs.

Once you have a documented win, you have leverage. Present those results to middle managers in terms they care about: reduced incidents during their on-call rotations, fewer emergency change requests, improved application reliability scores, or better team morale.

Where possible, frame the win as a personal benefit for the manager as well. A more stable, faster-moving application reflects well on everyone accountable for it. Creating a win-win situation is how sustainable adoption takes hold.

3. Start Small and Find the Balance

Middle managers are often overwhelmed by operational demands and have little bandwidth to evaluate broad cultural proposals. Asking for wholesale adoption of DevOps practices all at once is likely to produce an instinctive “no.” A more effective approach is incremental adoption.

Introduce one practice at a time — automated testing in a CI pipeline, for example, or a lightweight post-incident review process. Prove value at each step before expanding. This reduces perceived risk and gives managers time to build confidence in the approach.

Peer influence also matters. If a middle manager sees a trusted colleague in a similar role embrace a DevOps practice and report positive results, the credibility of the change increases substantially. Identify internal champions and let them carry part of the message.

The goal is balance: aligning the team’s technical aspirations with the manager’s accountability pressures and the business’s risk tolerance. Neither side gets everything immediately, but both can move forward together.

4. Clearly Define What Middle Managers Still Own

One of the most common mistakes in DevOps transformations is that senior leadership defines new roles for DevOps teams carefully — and then forgets to define what middle management is now responsible for. This ambiguity is itself a source of resistance. If managers do not know what their job looks like in the new model, they will either disengage or actively work to reassert control in ways that create conflict.

DevOps teams take on many responsibilities that previously belonged to managers — sprint planning, task allocation, peer feedback — but they do not want to own everything. Senior leaders should be explicit about the responsibilities that remain firmly with middle management, including:

• Budgeting and resource allocation
• Performance reviews and formal evaluations
• Career development and growth planning
• Hiring, onboarding, and offboarding
• Specialist skills development across the team
• Capacity planning at the organizational level
• Cross-team coordination and escalation management

When managers understand that DevOps is not eliminating their role but reshaping it — freeing them from day-to-day task management to focus on higher-value people leadership — resistance often softens significantly.

5. Commit to a Deliberate Rollout Strategy

There is no single correct way to introduce DevOps across an organization, but choosing your approach deliberately — and committing to it — reduces the surface area for resistance. Two broad strategies have been shown to work in different organizational contexts.

The Quiet Pilot Approach

Introduce DevOps tools and practices on a pilot project without framing it as a major cultural initiative. When adoption is not announced as a sweeping change that everyone must immediately embrace, middle managers have less reason to mount formal resistance. The team builds capability, the methodology matures, and the results surface organically. Other teams and managers observe the outcomes and become curious rather than defensive.

The Top-Down Greenfield Approach

When a CIO or senior executive sponsors a new DevOps team as part of a digital transformation initiative, it creates a greenfield environment. New technologies, new processes, and aligned DevOps principles can be adopted from day one without navigating the political weight of existing team structures. This approach sidesteps many of the silo conflicts that middle management can become entangled in — though it requires visible, sustained executive commitment to succeed.

Whichever path you choose, the key is consistency. Reversing course or allowing exceptions to undermine the new model signals to middle managers that resistance is a viable strategy. Commit to your rollout plan, measure outcomes rigorously, and communicate progress at every level of the organization.

The Bottom Line

Middle managers are not inherently anti-DevOps. In most cases, resistance stems from unclear role definitions, insufficient data to manage risk confidently, or a lack of visible evidence that the change is worth the disruption. Address those root causes directly — with data, with early wins, with incremental adoption, with explicit role clarity, and with a committed rollout strategy — and middle managers can become some of your most valuable DevOps advocates.

DevOps Wisdom from the DOES Stage

The Continuous Discussions (#c9d9) video podcast, produced by Electric Cloud, spent several years hosting hundreds of practitioners and thought leaders from the DevOps community. Among its most notable guests were speakers who had also taken the stage at DevOps Enterprise Summit (DOES) — the annual conference focused on DevOps adoption in large, complex organizations.

IT leaders from organizations including Hearst Business Media, Nationwide Insurance, IBM, Capital One, Target, and Pivotal shared candid accounts of their DevOps transformation journeys: the patterns that worked, the pitfalls they hit, and the cultural shifts that made the biggest difference. What follows is a curated collection of key insights from ten of those conversations.

10 Key Insights from DOES Practitioners

1. Mark Imbriaco: The Benefits of a Mature DevOps Transformation

One of the clearest indicators that a DevOps transformation has reached maturity is a shift in how teams relate to incidents and outages. Rather than scrambling to assign blame, mature organizations treat failures as learning opportunities embedded in a blameless culture. Mark Imbriaco, who has led infrastructure and reliability efforts at large-scale organizations, emphasized that the payoff of sustained DevOps investment shows most clearly when teams can recover faster, communicate more openly, and improve continuously without fear.

2. Topo Pal: Teams Should Own Their Pipeline

A shared, centrally managed pipeline can quickly become a bottleneck and a source of misaligned incentives. Topo Pal’s recommendation is straightforward: the team that ships software should also own and maintain the delivery pipeline that gets it there. This end-to-end ownership creates accountability, reduces handoff delays, and gives engineers direct visibility into where friction exists in the path to production. When pipeline problems surface, the team that feels the pain is also the team best positioned to fix it.

3. Nicole Forsgren: Metrics Are More Than Numbers

Measurement is central to DevOps, but the way organizations collect and interpret metrics matters as much as the metrics themselves. Nicole Forsgren — researcher, author, and co-creator of the DORA metrics framework — has consistently argued that metrics must be tied to outcomes, not just activity. Tracking deployment frequency or mean time to restore is only useful if those numbers inform decisions and drive genuine improvement. Metrics divorced from context can just as easily encourage gaming the system as they can encourage real progress.

4. Carmen DeArdo: Driving Business Value, Not Just Technical Change

DevOps transformations that stay confined to engineering teams rarely achieve lasting organizational change. Carmen DeArdo, who led DevOps efforts at Nationwide Insurance, stressed the importance of connecting technical improvements to the business outcomes that executives and stakeholders care about. Framing DevOps work in terms of faster time to market, reduced risk, or improved customer experience makes it easier to secure executive sponsorship and sustain investment over the long haul. Without that business case, DevOps can stall as a purely technical initiative.

5. Ashish Kuthiala: Collaboration and Empathy as Core DevOps Values

Tooling and automation get significant attention in DevOps conversations, but the cultural dimension is just as critical — and much harder to change. Ashish Kuthiala highlighted collaboration and empathy as foundational attitudes that make cross-functional teams actually work. When developers understand the operational constraints that ops engineers face, and when ops engineers appreciate the delivery pressure developers operate under, the resulting conversations produce better systems and faster feedback loops. Empathy is not soft; it is a prerequisite for effective shared ownership.

6. Paula Thrasher: Specialists Still Have a Place in DevOps Teams

The push toward generalist “you build it, you run it” teams can create a false impression that deep specialization is no longer valued. Paula Thrasher pushed back on that narrative. Specialists — security engineers, database administrators, accessibility experts — bring concentrated expertise that generalists simply cannot replicate. The key is integrating specialists into cross-functional workflows rather than isolating them in separate silos. Done well, the presence of specialists raises the overall capability of the team without creating new bottlenecks.

7. Pauly Comtois: Harnessing Engineer Passion

Engineers tend to care deeply about their craft. Pauly Comtois recognized this passion as one of the most underutilized assets in a DevOps transformation. When organizations channel that energy — by giving engineers meaningful problems to solve, encouraging experimentation, and removing bureaucratic friction — they accelerate change far more effectively than any top-down mandate. The implication for leaders: create the conditions where passion can be productive, rather than managing it out of the system.

8. Ann Marie Fred: Give Developers Greater Responsibility

One recurring pattern in DevOps transformations that stall is over-reliance on gatekeeping processes that limit what developers can do without external approval. Ann Marie Fred, drawing on her experience at IBM, advised organizations to extend greater trust and responsibility to developers — including responsibility for production readiness, monitoring, and on-call participation. Greater responsibility creates greater accountability and, importantly, greater motivation to build quality in from the start rather than pushing quality checks downstream.

9. Steve Mayner: The Power of Transformational Leadership

Technology alone does not drive a DevOps transformation — leadership does. Steve Mayner pointed to transformational leadership as the critical enabler that determines whether DevOps initiatives gain traction or fade after the initial pilot. Transformational leaders communicate a compelling vision, model the cultural behaviors they want to see, and actively work to remove organizational impediments rather than simply delegating change to engineering teams. Without visible executive commitment, DevOps efforts tend to remain localized and fragile.

10. Jayne Groll: Overcoming Language Barriers Between Teams

One of the most underappreciated friction points in enterprise DevOps adoption is the language gap between technical teams and business stakeholders. Jayne Groll — co-founder of the DevOps Institute — observed that development, operations, security, and business teams often describe the same problems and goals using entirely different vocabulary. Building a shared language, or at minimum developing the habit of translating across disciplines, is a practical first step toward alignment. Without it, even well-intentioned cross-functional efforts can collapse into misunderstanding.

Common Themes Across DOES Practitioners

Reading across these ten insights, several patterns emerge that are broadly applicable to any organization pursuing a DevOps transformation:

• Culture before tooling. Empathy, collaboration, blameless culture, and shared ownership consistently appear as prerequisites for sustained improvement — not afterthoughts.
• Ownership drives quality. Whether it is pipeline ownership (Topo Pal) or broader developer responsibility (Ann Marie Fred), teams that own outcomes are more motivated to improve them.
• Metrics must connect to outcomes. Measurement without meaningful interpretation can mislead as easily as inform.
• Leadership is non-negotiable. Multiple speakers pointed to visible, committed leadership as the factor that separates DevOps transformations that scale from those that stall.
• Communication is a technical skill. The ability to bridge language gaps between teams — and between engineering and the business — is as strategically important as any deployment automation.

All speaker quotes and insights in this article were originally shared on the Electric Cloud Continuous Discussions (#c9d9) podcast. The original compilation was published at electric-cloud.com.

Why Metrics Matter in DevOps

One of the most repeated lessons from seasoned DevOps practitioners is simple: you cannot improve what you do not measure. Metrics are not a reporting exercise for management — they are the feedback loop that tells your team whether the changes you are making are actually delivering value, reducing risk, or just creating noise.

Software delivery can be chaotic and unpredictable, but it does not have to stay that way. The right metrics give teams the visibility they need to move from reactive firefighting to deliberate, continuous improvement.

Measure Outcomes, Not Just Activity

A common trap in DevOps measurement is optimising for activity metrics — number of commits, number of deployments, lines of code — rather than outcome metrics that reflect real business and engineering health. Useful outcome-oriented metrics typically fall into a few categories:

• Deployment frequency: How often are you successfully releasing to production? Higher frequency is generally a sign of smaller, safer changes and a mature pipeline.
• Lead time for changes: How long does it take from a committed code change to that change running in production? Shorter lead times indicate a streamlined, automated delivery process.
• Change failure rate: What percentage of deployments cause a production incident or require a rollback? This surfaces the quality signal hidden inside your release cadence.
• Mean time to restore (MTTR): When something does go wrong, how quickly can you recover? Fast recovery is often more valuable than zero failures.

These four metrics — popularised by the DORA research programme — are widely referenced as a starting framework for DevOps measurement because they balance speed and stability rather than treating them as a trade-off.

Start Simple: Pick a Few Metrics and Track Them Consistently

The value of a metric comes from tracking it over time, not from a single snapshot. Teams often make the mistake of collecting dozens of metrics at the outset, then losing the thread when the data becomes difficult to interpret or act on.

A practical approach:

1. Choose two or three metrics directly tied to your current pain points.
2. Establish a baseline — even a rough one is better than none.
3. Set a realistic target and a time horizon.
4. Review the metrics in your regular retrospectives, not just in quarterly reports.
5. Add more metrics only when you have built the habit of acting on the ones you already track.

Avoid Vanity Metrics

Vanity metrics look impressive in a dashboard but do not inform decisions. Examples include total number of automated tests (without considering coverage or reliability), raw uptime percentages that mask chronic low-severity incidents, or story points completed per sprint divorced from actual user value delivered.

Ask this question of every metric on your dashboard: “If this number changed significantly next week, what would we actually do differently?” If the honest answer is “nothing,” the metric is likely a vanity metric.

Make Metrics Visible to the Whole Team

Metrics hidden in a spreadsheet that only a manager reviews are nearly useless for driving cultural change. Effective DevOps teams surface metrics where the work happens — on shared dashboards, in Slack channels, in CI/CD pipeline notifications, and in sprint reviews.

Visibility creates shared accountability. When a developer can see that the deployment failure rate jumped after their change, or that lead time improved after a pipeline optimisation they championed, measurement becomes motivating rather than punitive.

Metrics Are a Conversation Starter, Not a Final Verdict

Numbers surface signals; they do not explain causes. A spike in change failure rate might indicate poor testing, it might indicate a riskier type of change, or it might mean your detection tooling has improved and you are now catching failures you previously missed entirely.

Use metrics to trigger investigation and conversation, not to assign blame. The goal is a team that is continuously learning from what the data reveals — and then acting on it.

Key Takeaways

• Measure outcomes (speed, stability, quality) rather than raw activity.
• Start with a small set of consistent metrics and build from there.
• Eliminate vanity metrics that do not drive decisions.
• Make metrics visible and shared across engineering and operations.
• Treat metric changes as prompts for investigation, not for judgment.

Good measurement is not a one-time project — it is an ongoing practice that evolves as your teams, tools, and delivery process mature. The organisations that get the most from DevOps are the ones that treat metrics as a living part of their engineering culture, not a compliance checkbox.

This article is part of a series on DevOps tips and inspiration, drawing on community knowledge shared by practitioners across the industry.

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.

DevOps adoption remains uneven across the industry. As Jeff Sussna, founder and principal of Ingineering.IT, has observed: “There are some companies that are all in and making really comprehensive progress. In general though, I would say a majority of companies I see are sort of grappling with it bit by bit, trying to understand what it is and how to do it.”

What is clear is that managers play a central role in making DevOps work. “You are coaching, mentoring, guiding, incenting people—and being willing to experiment,” Sussna said. Below are five practical tips to help you become an effective DevOps manager.

1. Start Where You Are

You do not need a new job title or a reorganized reporting structure to begin leading with a DevOps mindset. According to Jennifer Davis, co-author of Effective DevOps and formerly a senior software engineer at Chef Software, enterprises should avoid creating a siloed “DevOps team.” Instead, every manager should embrace DevOps principles within their existing role.

The practical starting point: examine your team’s current workflows, identify bottlenecks that better collaboration could solve, and then talk to your team and to potential partners on adjacent teams. “Empower the team to be part of the change transformation,” Davis said.

Sussna reinforces this point: “It’s important to emphasize that at its heart, DevOps is not about org chart changes—it doesn’t mean everyone’s title changes or you report to one manager. It means that the nature of your relationships with all of the other managers and parts of the organization changes.”

2. Change Your Attitude Toward Failure

A common early mistake is expecting immediate, measurable results from a DevOps initiative. When a two-week experiment does not deliver obvious wins, some managers conclude the approach failed and abandon it. Sussna argues this is the wrong frame entirely: “You now have information, so it shouldn’t be treated as a failed project.”

DevOps transformation is not like deploying a new software tool. It operates on a deeper, human level—changing how people think, work, and relate to colleagues across the organization. “As a manager, you have to think about your team, or organization, as a service provider—not just a doer of things,” Sussna said. Treat early setbacks as learning opportunities and iterate from there.

3. Hone Your Collaboration Skills

DevOps is fundamentally about cross-functional collaboration. Bridget Kromhout, principal technologist at Cloud Foundry and a lead organizer of the DevOpsDays conference, notes that effective DevOps managers must be able to lead and align development, infrastructure, operations, security, testing, and product teams toward shared goals.

“Being a great manager means respecting the perspective of other teams while channeling your direct reports’ efforts towards the agreed-upon goals of the wider organization,” Kromhout said. Specific practices that support this include:

• Active listening during cross-team discussions
• Blameless postmortems that focus on systemic improvement rather than individual fault
• Building affinity—deliberate relationship-building across teams and communities

Davis emphasizes that the connections you build across an organization reduce communication barriers, shorten delivery cycles, and establish trust. “The connections that we build allow us to shorten the time that it takes for us to get work done, reduce communication barriers, and build trust based on regard,” she said.

4. Become a Mentor

Strong DevOps managers actively mentor junior staff and create space for senior team members to do the same. This matters more than it might seem: when only one or two people hold critical knowledge, those individuals become single points of failure for the entire service or product.

“Often, senior folks are discouraged from mentoring, and implicitly encouraged to become the single point of failure on the team, as they can get the work done quicker than the new folks,” Davis said. Over time, this pattern creates fragile systems and team burnout. A healthier model distributes knowledge broadly, giving everyone the ability to contribute and respond to incidents.

As a manager, actively protect time for mentorship—treat it as an investment in system reliability and team resilience, not a distraction from “real” work.

5. Prioritize Continuous Learning

Investing in the knowledge and skills of your team pays dividends across the board. Davis notes that the opportunity to learn is one of the key drivers of employee satisfaction—and satisfied employees build better, more reliable products.

Kromhout describes the ideal DevOps manager as someone who “encourages a human-centered approach that values the experiences of the team, while continuing to challenge them to learn and develop.” In practice, this means:

• Allocating dedicated time for training, reading, and experimentation
• Supporting attendance at industry events like DevOpsDays or internal knowledge-sharing sessions
• Celebrating curiosity and rewarding learning, not just delivery
• Rotating team members through different responsibilities to broaden skills

Key Takeaways

Becoming an effective DevOps manager is less about mastering new tools and more about evolving your leadership philosophy. The shift involves moving from a command-and-control posture to one centered on coaching, collaboration, and continuous improvement. To summarize:

1. Start where you are — no reorganization required; adapt your current role.
2. Reframe failure — treat experiments as data, not verdicts.
3. Lead through collaboration — build cross-team relationships and run blameless postmortems.
4. Mentor actively — distribute knowledge to eliminate single points of failure.
5. Champion learning — invest in your team’s growth as a core management responsibility.

Original source: TechRepublic. Quotes attributed to Jeff Sussna (Ingineering.IT), Jennifer Davis (co-author, Effective DevOps), and Bridget Kromhout (Cloud Foundry / DevOpsDays).

If you work in tech, you almost certainly have an opinion on DevOps. Critics argue it creates organisational friction and blurs accountability. Advocates — and there are many — say it is indispensable for shipping software reliably at scale. The truth is that both camps can be right, depending on how the practice is implemented. DevOps done badly is expensive noise. DevOps done well is a sustainable competitive advantage. The difference usually comes down to a handful of deliberate choices about what your DevOps team is actually responsible for.

The following three principles are drawn from operational experience at a high-growth technology company. They are intended for engineering leaders, platform engineers, and anyone responsible for shaping a DevOps function.

1. Task DevOps With Differentiating Your Technology Foundation

Commodity cloud services — AWS, Google Cloud Platform, Microsoft Azure — are genuinely excellent. They are also available to every one of your competitors on identical terms. Selecting a major cloud provider gets you to parity, not ahead. Real competitive advantage comes from what you build on top of, or alongside, the commodity layer.

A well-directed DevOps team can exploit lower-level differentiation that off-the-shelf cloud configurations do not expose. Examples include:

• Hardware-level tuning: Selecting workload-specific processors, or leveraging NVMe or high-throughput flash storage for latency-sensitive applications, can yield significant performance gains compared with default cloud instance types. The exact multiple depends heavily on the workload, but the principle — that specialised hardware outperforms generalised configurations for specific tasks — is well established.
• Hybrid deployment strategies: Intelligently mixing bare-metal co-location, private data centres, and public cloud regions allows you to optimise cost and latency simultaneously. This kind of blended architecture requires deliberate engineering; it does not emerge from simply clicking through a cloud console.
• Custom tooling for your specific domain: Generic infrastructure-as-code templates work for generic problems. If your product has unusual traffic patterns, data access patterns, or compliance requirements, bespoke automation built by your DevOps team will outperform off-the-shelf solutions.

The practical implication: when you scope your DevOps team’s roadmap, include explicit work items around infrastructure differentiation. If every sprint is pure maintenance, you are running fast to stand still.

2. Build Tools That Let Engineering Scale Without Adding Headcount

One of the clearest measures of a healthy DevOps function is whether it reduces the per-engineer operational burden over time. If onboarding a new engineer requires a week of manual environment setup, or if deploying to production requires a specialist in the room, your DevOps team has not yet solved the scaling problem.

The mechanism that makes scaling possible is systematic automation. Every infrastructure decision should be deliberate, documented, and encoded as repeatable automation rather than tribal knowledge. Concretely, this means:

• Automated server provisioning: New capacity should be spun up via code, not manual clicks. Tools such as Terraform, Ansible, or Pulumi make this reproducible across environments.
• Automated deployment pipelines: Code should flow from development through staging to production via a CI/CD pipeline (Jenkins, GitHub Actions, GitLab CI, and similar tools are common choices) with automated tests acting as gatekeepers at each stage.
• Automated anomaly detection and alerting: Observability stacks — combining metrics (Prometheus, Grafana), logs (the ELK stack or similar), and traces (Jaeger, OpenTelemetry) — should surface problems before users report them.
• Environment consistency: Configuration management tools (Chef, Puppet, Ansible) and container orchestration (Kubernetes) ensure that the environment a developer tests against matches what runs in production, eliminating entire categories of “works on my machine” bugs.

The test of success: can a developer who joined last month ship a feature to production without filing a ticket with the DevOps team? If the answer is yes, the platform is working. If the answer is no, the DevOps team is a bottleneck rather than an enabler.

3. Never Let DevOps Become an IT Help Desk

This is the most common failure mode for DevOps teams, and it is worth stating plainly: the moment your DevOps engineers are spending the majority of their time on laptop configuration, VPN access requests, or user onboarding, the team has become an IT support function. That is not a criticism of IT support — it is a legitimate and important discipline — but it is a completely different job with a completely different value model.

DevOps exists to drive infrastructure innovation and engineering velocity. IT support exists to keep individual users productive. Conflating the two harms both outcomes: users get slower support from engineers who resent the interruption, and infrastructure work stalls because the engineers are distracted.

How to detect the IT trap: Review your DevOps team’s ticket queue or task tracker. Ask these questions:

• What percentage of tickets come from individual users requesting help with their devices or access permissions?
• What percentage represent architectural improvements, performance work, or tooling that benefits all engineers?
• Is the ratio shifting over time — more user requests, fewer infrastructure projects?

A practical heuristic: if more than roughly 10% of DevOps capacity is absorbed by individual user requests, you have a structural problem worth addressing. The fix usually involves one of three approaches: hiring dedicated IT support staff, implementing self-service tooling (identity management platforms, automated access provisioning), or explicitly re-scoping the DevOps team’s mandate in writing so that boundaries are clear.

Putting It Together

None of these principles require a large team or a large budget. They require clarity of purpose. A DevOps team that knows it is responsible for differentiating the infrastructure, enabling engineers to scale independently, and staying out of the IT support business will naturally make better decisions about how to spend its time.

Conversely, a DevOps team without that clarity will drift toward whatever is loudest and most urgent — which is almost always user-facing problems rather than strategic infrastructure work. The loudest problems are rarely the most important ones.

If you are building or restructuring a DevOps function, start by writing down what the team is not responsible for. That boundary-setting exercise often reveals misalignments faster than any amount of process documentation. Once the scope is clear, the three principles above give you a practical framework for evaluating whether the team is delivering real business value — or just keeping the servers on.