Anyone leading a DevOps transformation should expect resistance. Culture change is hard, and different groups resist for different reasons: introverts may avoid highly collaborative workflows, risk-averse engineers may worry about accelerated release cycles, and middle managers — especially those accustomed to command-and-control structures — may feel that DevOps directly threatens their authority and job security.
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.