How not to kill your DevOps team

Gloss over certain needs and warning signs and your DevOps initiative might just burn your team out. Follow these do's and don'ts to keep making healthy progress.

By

on

June 04, 2018

A thriving DevOps culture should mean a thriving IT team, one that plays a critical role in achieving the company’s goals. But leave certain needs and warning signs unchecked and your DevOps initiative might just grind your team into the ground.

There are things that IT leaders can do to foster a healthy, sustainable DevOps culture. There are also some things you should not do, and they’re are just as important as the “do’s.” As in: By not doing these things, you will not “kill” your DevOps team.

With that in mind, we sought out some expert advice on the “do’s” and “don’ts” that DevOps success tends to hinge upon. Ignore them at your team’s – and consequently your own – peril.

Do: Remove friction anywhere it exists

One of the goals of the early days of DevOps, one that continues today, was to remove the traditional silos that long existed in IT shops. The name itself reflects this: Development and operations are no longer separate wholly separate entities, but can now function as a closely aligned team.

That’s a fundamental example of removing friction – in this case, between people and teams. But it doesn’t stop there, nor is eliminating friction a given just because you bring a bunch of people together under the moniker of DevOps (or DevSecOps).

Nate Berent-Spillson, senior delivery director at Nexient, says IT leaders must strive for frictionless workflows as much as possible to ensure the health of their DevOps teams. If something is unnecessarily slowing the team down or causing headaches, or simply isn’t serving a meaningful purpose, get rid of it.

Do not: Retreat from failure

DevOps and the blame game don’t mix. You can’t tell your team to “fail fast” or some similar mantra about embracing failure and then punish people when they do just that. It’s a common killer of DevOps initiatives and teams.

“Instead of asking who is to blame, I would ask, ‘What are the next areas to improve using DevOps?’”

“DevOps creates a path for us to improve, and organizations need to use those failures as indicators of areas that will provide the most business value in fixing,” says Robert Reeves, CTO and co-founder at Datical. “Instead of asking who is to blame, I would ask, ‘What are the next areas to improve using DevOps?’”

Declaring “we’re a DevOps shop!” while maintaining a failure-averse philosophy is a fence-sitting strategy – more on that kind of hedge position below – and people will see right through it.

Ed Price, director of compliance at Devbridge Group, sees this manifest in what he calls “AgileFall” shops: That is, organizations that say they’re embracing DevOps culture and Agile methodologies, but very quickly roll back to manual processes or waterfall development when they hit a rough patch. When your DevOps team is once again hamstrung by arbitrary deadlines or approval processes to get into production, for example, you’re gone astray.

“The biggest mistakes organizations make is to resort back to manual and waterfall deployment models because they think DevOps isn’t working,” Price explains. “The 'fail ­fast' mentality means you will have some bumps along the way and the leadership needs to ride out the wave.”

Do: Measure your efforts

One of the most glaring warning signs of imminent DevOps failure? When there are no warning signs, according to Reeves.

“The reason you have a DevOps initiative is to increase the speed and decrease errors of application deployments,” Reeves says. “But, if you aren’t measuring those, you can’t tell if you are improving, treading water, or backsliding.”

Reeves recommends measuring the following as musts:

Mean time to recovery (MTTR)

First-time success rate of deployments to production

Number of production deployments

Lead time (amount of time from code check-in to production deployment)

Metrics will vary by organization, but these may be a good foundation or baseline that you can measure against over time. When the numbers move in the wrong direction relative to your baseline and goals, something’s amiss.

Red Hat technology evangelist Gordon Haff stresses that DevOps metrics should reflect what’s important to the success of your organization - say in terms of customer experience and operational efficiency.

“If it’s customer experience, a metric such as Net Promoter Score might be appropriate. If it’s efficiency, more cost-centric measurements will be the better match,” he notes.

DevOps metrics should be tied to business outcomes in some manner, he says. There are plenty of technical metrics you could track, but what you really care about is “the degree such metrics can be correlated with customers abandoning shopping carts or leaving for a competitor,” notes Haff.

Do not: Ignore the warning signs of burnout

Burnout in the IT profession is real. A healthy DevOps culture should minimize burnout, but that’s not promised to anyone, especially if “DevOps” is a red herring for “making people work 24-7.” Burnout is something to watch out for even in less dramatic scenarios, especially as people get used to new ways of doing things.

“Burnout is one of the biggest, if not the biggest, risks in IT,” says, Dary Merckens CTO of Gunner Technology. “Tech people by nature are the kind of folks who will push themselves as hard as they can to complete something.”

Couple that with the driving forces behind DevOps – delivering products and services faster, more frequently, and with fewer errors – and you could be turning the heat up on a boiling kettle. You need to keep tabs on morale or risk significant negative consequences.

There are plenty of ways to do so, including simply becoming a better listener. But Merckens offers another metric you can track.

“You can get a pretty good sense of the mental energy of your team by looking at bug frequency.”

“You can get a pretty good sense of the mental energy of your team by looking at bug frequency,” Merckens says. “If you start seeing lots of bugs being deployed, you need to be wary of your team running out of steam.”

When you do see the symptoms, work to address them (and their underlying causes) head-on.

At Merckens’ firm, they’ll perhaps take an afternoon off to do something non-work-related as a team – “the new Solo movie being the perfect example of some fun, nerdy thing we can all do,” for example, he says. Or, give the team an extra day off after a particularly grueling stretch. Regardless, do something.

“There are lots of things you can do to prevent or remedy burnout, but the one thing you don't want to do is ignore it,” Merckens says.

Related content

Tags:

Kevin Casey writes about technology and business for a variety of publications. He won an Azbee Award, given by the American Society of Business Publication Editors, for his InformationWeek.com story, "Are You Too Old For IT?" He's a former community choice honoree in the Small Business Influencer Awards.

Email Capture

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

About This Site

The Enterprisers Project is an online publication and community focused on connecting CIOs and senior IT leaders with the "who, what, and how" of IT-driven business innovation.

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. The Enterprisers Project aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.

A note on advertising: The Enterprisers Project does not sell advertising on the site or in any of its newsletters.