DevOps for doubters: How to deal with 9 kinds of people who push back

At first glance, the benefits of DevOps are hard to deny. Continuous delivery of new software and features makes customers happy and businesses more agile. Highly collaborative, transparent, cross-functional ways of working can rally teams around a shared mission and purpose.

It’s no wonder that companies big and small are singing DevOps’s praises and expecting everyone to get on board and never look back. That’s why it can be surprising when leaders encounter team members who seem to intentionally dig in their heels or create obstacles that slow DevOps down, says Matt Poepsel, senior vice president at The Predictive Index.

“When a leadership team changes a team’s structure, introduces a new technology, or redesigns a key process, people issues inevitably surface,” says Poepsel. “A DevOps transformation is no different. Accelerating code deployment cadence, for example, may threaten a risk-averse engineer’s desire to avoid quality issues. Likewise, increasing cross-functional collaboration may be difficult for more introverted team members.”

Addressing both the technical and people aspects of a DevOps transformation will create change management issues for nearly every personality type, Poepsel points out. “That means taking the time to consider how each individual team member’s personality will influence their motivation and perceived benefit from the introduction of DevOps practices.”

[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]

We asked IT leaders and DevOps experts to share the personas and roles where they’ve experienced the most resistance and pushback. If you’re starting your own DevOps journey – or have stalled somewhere along the way – tune into these people in your organization. Getting them on board may be just the catalyst you need.

The “frozen middle”

Matt Takane, agile coach, Red Hat Open Innovation Labs: “The ‘frozen middle’ is a made-up term that includes anybody who says no to new ideas on how to get work done. Common phrases you hear from these people are ‘that can’t work here,’ and ‘that is such and such’s department, not ours.’ People who feel the new idea is a risk to their job or responsibility will become part of the frozen middle and try to shut it down before it affects what they want to do. It is an invisible barrier that is not tied to any one role or person but passed along and used to give reasoning behind not trying something new.

“Those that are in the frozen middle tend to be quick to tarnish progress if anything goes slightly wrong and be the loud voice of dissent. They also tend to ask many questions on how the new idea relates back to the old metrics used to measure progress and tracking.

“To win these folks over, show how the new idea makes the system and their ability to influence it better. There is a bit of a leap of faith, but keeping an eye on the prize (the business value) and enabling them to deliver it in a slightly different yet more transparent way is what truly helps the frozen middle to thaw.”

The innovator

Matt Poepsel, senior vice president, product, The Predictive Index: “Innovators welcome change, but they will bristle at anything that will prevent them from achieving their goals. They may think that too many rules about writing automated tests and quality gates will slow them down. 

“Reinforce DevOps best practices by assuring them that while automation does require discipline, an emphasis on lean software development techniques and A/B testing will actually increase speed, not slow them down.”

[ Some people get confused about Agile vs. DevOps. We break it down: Read Agile vs. DevOps: What’s the difference? ]

The middle manager

Chris Short, principal product manager, Red Hat Ansible, 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 (being from another team could help if better collaboration is a goal for the business).

“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.”

The engineer who has been burned before

Manuel Pais, IT consultant and co-author, “Team Topologies”: “Those people exist, but usually their behavior is a reflection of either bad experiences or wrong incentives from the organization. They might have been through too many reorgs and strongly believe DevOps is just another fad. Perhaps they put their heart and soul on the latest agile transformation, but because all the company did was send people to Scrum training, they realized nothing substantial ever changed. Other people are genuinely afraid to lose their power and consequently their jobs. They might have low interest in the work or are happy with repetitive work.

“At the end of the day, when you can prove things like decreased lead time, more frequent and more successful deploys, faster feedback from users, etc., then the arguing eventually stops and whoever still feels uncomfortable will likely leave. And that’s ok.”

The stabilizers

Poepsel: “These are people who pride themselves on quality and safety; they have tremendous empathy for the end user and think speed is dangerous and that you’ll create more quality issues by going too fast.

“Remind them that increased speed is an expected benefit of DevOps, but this also applies to how quickly you can fix software issues for your users.”