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.”
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.”
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.”
I want to be the devil's advocate: and if it were yet another "vapourware" or "crapware"?
Holding the reins tight on production evironments was not only an obsession of ops teams and letting to devs responsability of running applications is not always a good idea.
At some point in time, top management will want to return to putting the responsibility in the hands of a single team, because they need to blame someone if things go wrong, especially in large organizations.
Good article, recognisable personas. However, the description does not ony apply to resistance to DevOps adaptation specifically, but to any organisational change in general (and, unfortunately, I know most of those - so probably I am one of them as well ;) ). Furthermore, DevOps is described here as being the solution to life, the universe and everything, which of course cannot be the case. I believe in Agile as a set of principles, but there are many flavours of Agile and sometimes even waterfall is better. Lastly, yes, I think DevOps is a fashion statement of this time. First, there was light and after a while there was Agile, then came Scrum which specialised(?) into DevOps, now there is BusDevOps and what will the next step be to make it fit the real world environment?