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

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

Are certain people clinging to the old ways of working? Here’s how to identify them – and get them on board with your DevOps efforts

up
178 readers like this, including you

The “not my job” person

Anthony Blardo, manager of development operations, Skuid: “In my experience, the most common people issue encountered with large-scale DevOps change is ‘not my job’ syndrome. When team members are asked to take on new responsibilities, it can be hard to convince them of the value that is realized by sharing responsibility. I have had very good luck with having one-on-one conversations with each team member, along with asking for input from the team as a group to figure out what the bottlenecks in the software delivery process are and potential solutions that the team could come up with by working closer.

You have to truly listen and allow people to work on problems they encounter on a day-to-day basis.

“You can’t simply ask people to do more; you have to truly listen and allow people to work on problems they encounter on a day-to-day basis that feel like impediments to progress, and empower them to solve those problems by collaborating with all of those who have a stake in the product.

“Also, training is a hard requirement of any successful transformation. There will be new tools, new vocabulary, and new processes that will all come about as a result of a shift into DevOps. Providing for time and potential budget to accommodate the new information will be critical.”

The producers

Poepsel: “Producers are results-first people who want it done and want it done right. They think cross-functional teams lack clear ownership and individual accountability. But while DevOps is a team sport, new measurements in important areas such as reliability, scalability, and monitoring will give teams the empirical data they need to continuously demonstrate improvement over time.”

The engineer who can’t let go

“Do they care about business efficiency and sacrificing previous efforts, or are they more intent on looking good and defending their efforts to their peers and execs?”

Steve Burton, DevOps evangelist, Harness: “The strongest DevOps engineers focus on time-to-market and automating themselves out of a job, while weaker ones concentrate on job security and building/maintaining/hugging everything themselves. You can identify the latter by seeing how resistant a DevOps engineer is to change and new ideas, specifically if it impacts what they’ve worked on in the past or things they’re currently managing. Do they care about business efficiency and sacrificing previous efforts, or are they more intent on looking good and defending their efforts to their peers and execs?

“Getting those DevOps engineers onboard is a matter of giving them specific insight into what business impact their efforts have. For example, an engineer might have built the best continuous delivery pipeline using Bash scripts and Jenkins but be unaware that only 10 percent of development teams are using that pipeline, which means the overall impact is low. Without adoption, the business impact of automation is minimal. In sum, DevOps engineers need to have their goals, efforts, and compensation align more with business metrics and outcomes than technical ones.”

The wary CIO:

Short: “I’ve met this person. Their fiefdom is crumbling or they have been burned by previous incidents. They might have made a late decision on adoption and now the competition is eating the organization’s lunch.

“The good news is it’s not too late. Show them what is likely an easier on-ramp thanks to maturity. Advise them that even the large vendors they are doing business with are pivoting. Also, remind them that playing catch-up is possible, but there has to be a real concerted effort with headcount and funding. See if you can bring in friends from across the organization here to help too. You’re not the only one feeling the pain, I guarantee it.”

[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]

Pages

2 comments

I want to be the devil's

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

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?

Pages

7 New CIO Rules of Road

CIOs: We welcome you to join the conversation

Related Topics

Submitted By Kevin Casey
June 03, 2020

What exactly is technical debt? When discussing your organization’s technical debt - and possible changes to it - with various audiences, you need to articulate the key issues in plain terms. Here’s expert advice on how to do that.

Submitted By Stephanie Overby
June 03, 2020

To successfully implement AI into your business processes, rethink traditional IT approaches and some common wisdom. Consider these tips

Submitted By Eran Kinsbruner
June 03, 2020

The shift-left approach helps development teams make software better and faster. So why hasn't it caught on - and how can you beat the barriers to success?

x

Email Capture

Keep up with the latest thoughts, strategies, and insights from CIOs & IT leaders.