Anyone leading a move to DevOps should expect to ruffle a few feathers along the way. As with any process or culture change, addressing the people issues head-on is critical to success. For instance, introverts may initially avoid new, highly collaborative ways of working. Risk-averse engineers may worry about the accelerated speed of DevOps.
Leaders can be proactive in communicating benefits and easing fears with these DevOps doubters. But middle managers, especially those in more traditional command-and-control environments, can be a special case. They may actively push against DevOps – as if their jobs depend on it. In fact, they might feel that way.
“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,” says Jeffery Payne, CEO of Coveros. “When middle management attempts to still do these activities in DevOps, conflict arises between what the team wants to do and what ‘management’ wants them to do and causes confusion. 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.”
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]
When DevOps teams and middle management are at odds, culture, morale, and ultimately, results can all suffer. But middle managers don’t have to be DevOps Enemy No. 1. We asked leaders to share how they’ve handled this tricky situation in their organizations – and tips for getting everyone on the same page.
1. Ease the fear of DevOps unknowns with data
“Every configuration change, deployment, and upgrade introduces unknowns,” says Ben Cronin, co-founder and VP of product, LightStep. “Those unknowns translate to increased risk of instability, which of course translates to a desire for a slower, more controlled rate of change. A DevOps manager is then in the very unenviable position of needing to hold their teams accountable to goals that are in conflict.”
“Anyone who’s been a manager knows how unpleasant that feels. When it gets out of hand and it feels like the impossible is being asked for, engineers can begin to ostracize the manager or the leadership chain as being disconnected from the reality of their work and the technology that holds the business together. Teamwork starts to fall apart.”
The fix here isn’t new, says Cronin. He recommends the following:
- Give the team, managers, and leadership reliable data about the system behavior.
- Have telemetry data for each part of the system to identify high-risk areas and the tools to understand the side effects, dependencies, and interactions between the many parts of the system.
“Quantifiable understanding of system behavior is the best way to turn a stressful conversation about assumption-laden unknowns (where DevOps engineers will rightly do their job and say, ‘We need to slow down!’) to a discussion of an acceptable balance of stability and velocity,” says Cronin. “With an error budget and relevant data, teams can make choices they are confident with and stay aligned to the goals of the broader organization.”
2. Help teams find a win – quickly
Robert Reeves, CTO, Datical, urges DevOps proponents to evangelize early and often internally to avoid the big red “No” from middle management.
“The middle manager isn’t a bad person. They just don’t understand the benefits. Instead, they are focusing on the risks, or they just aren’t fans of change,” says Reeves. “DevOps teams must have a win for at least one application, from check-in to production, before attempting to win over doubters. There has to be one application that all stakeholders would like to see using DevOps. Focus on that one application and leverage before-and-after metrics and KPIs to prove success.”When all else fails, appeal to the personal, suggests Reeves. “Show the middle manager how adopting DevOps can help them personally, either through getting them a ‘win’ or increasing the quality of their application and life. Creating a win-win situation is how you succeed in both business and IT.”
3. Start small and find the balance
If middle managers are pushing back, try taking small steps, says Chris Short, principal technical marketing manager, cloud platforms, Red Hat, and publisher of the DevOps’ish newsletter.
“Middle managers are usually so stuck trying to manage their calendars they can’t always see the forest through the trees when it comes to change. They’ll likely accept something, but only if it has proven results and buy-in from at least one co-worker of yours,” says Short. “The biggest thing is balance. You have to balance your wants and desires with your manager’s and that of the business as well. Friends help here, and so does time management. Start small; you don’t eat an entire meal in one bite.”
4. Middle managers still play a role
“Smart senior leaders define roles for everyone when moving to agile or DevOps,” says Payne. “Usually the teams understand what is expected of them, but senior leadership forgets to define the role of middle management.”
Without properly defined roles and expectations, issues can arise. Some of middle management’s duties are taken over by DevOps teams, but there are many responsibilities DevOps teams don’t want to own, Payne points out.
Senior leaders should emphasize the important roles that middle managers still play in a DevOps culture, including budgeting, performance reviews, career development, specific functional skills development of staff, hiring/firing, and capacity planning, says Payne.
[ What tools help support scrum, kanban, and other agile methods? Read also: Top 7 open source project management tools for agile teams. ]
5. Commit to a rollout strategy
Maybe you’re reading this article because you're being proactive - reading about potential pushback you might encounter and how to deal with it. It’s smart to weigh your rollout options carefully: Will you introduce DevOps with a grassroots effort fueled by small wins, or a company-wide, top-down shift?
Both can work, says Peco Karayanev, director product management for Riverbed Technology. “I’ve seen organizations successfully introducing DevOps tools and processes silently on pilot projects, without calling it out as such,” says Karayanev. “If you are not introducing DevOps as a big cultural change that everyone must get behind all at once, there is less reason for middle management to resist it. If you go this route, you can build out the methodology and the team’s knowledge around these projects – and let the results speak for themselves.”
On the other end of the spectrum, he says, top-down approaches can also work when the CIO creates a new DevOps team as part of a digital transformation initiative.
“This is a greenfield situation that allows you to bring in new technologies and align on core DevOps principles from the start. It also sidesteps the type of silo wars that middle management can be constrained by,” says Karayanev.
[ Want to give your team a greater sense of urgency? Get our new resource: Fast Start Guide: Creating a sense of urgency, with John Kotter. ]
