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