Managing Burnout in a Continuous Environment

dreamstime_xs_35919178DevOps has been touted as the next big answer to all of our problems. But as with the answers that came before, there is a cost involved. Burnout rates are high and the collateral damage of perpetual integration is taking a toll on the guys in the trenches.

By way of example, let me take you back a few years. In the days after 9/11, Search and Rescue dog handlers began noticing strange new phenomena with their canine counterparts. The number of people found alive in the rubble was (sadly, though understandably) very low, and because of the way the dogs had been trained, they equated searching out survivors as being of higher value than recovering the dead. Due to this, the dogs became depressed, believing that they were not doing a good enough job, and had to be swapped out with much greater frequency than usual. Success was improperly defined and as a result, the workers (the dogs in this example) were unclear on when they had achieved it.

Humans are geared much the same way. We measure our work lives by the victories we achieve and the projects we complete. But in a continuous integration, DevOps environment, there’s not always a discernable victory. There are always more functionalities to break and more code to deploy. Mental fatigue can give way to burnout, and burnout lives just a few doors down from full-on depression. The key to avoiding this is two-fold:

 

  • Management should implement techniques that provide relief
  • Team members must strike work-life balance

I asked our practice director, Jim Leichtenschlag, to share some of his ideas on techniques and methods for DevOps managers to consider that can help prevent team burnout in a DevOps environment.   I’ll address the work-life balance ideas for DevOps team participants in a subsequent blog.

Management Techniques:

  • Pace Yourself: The natural team instinct is to move and deliver as fast as possible.   But short-term urgency can evolve into longer term exhaustion if you’re not careful. Build a roadmap that identifies minor and major efforts and plan out sprints that maintain a high level of sustainable delivery, but not constant heroic efforts that can ultimately ruin an otherwise “good thing.”
  • Claim Victory: The human condition longs for and NEEDS the feeling of accomplishment. Create and publish measurements so that when realized, the team can claim victory. If you don’t, a DevOps approach can seem for many team members to be a long journey, with no realization of incremental successes. Most importantly, remember to celebrate and reward these victories.
  • Manage Expectations Share your plans with the internal groups that depend on you so there is a basis for negotiating changes in priorities and identifying the impacts of emergency variations. The need for acts of heroism should arise from unexpected circumstances OUTSIDE the plan and should not be needed regularly as it is simply not sustainable. Planned, constant, quality results over time generally a have more positive impact than delivering on a few emergencies.
  • Cross Train This is not necessarily unique, but it is critical in a DevOps environment due to the pace and constant participation of team members. Take the time to allow resources to cross train across disciplines and with tools – e.g. a QA automation engineer becoming trained on an IT Ops tool such as CHEF.   This cross training will permit team members to take time off, maintain some flexibility, and reduce stress that can occur if they are the only “expert” on the team.

What works for you? Discuss in the “Comments” section below!

 

Lee Carter

3 Comments

  1. It seems that one of the central ideas of Agile and DevOps is smaller and more frequent releases. I think that does put more pressure on IT because you never have those long periods with no urgency. Releases are not as big but you have a very short window. Pace Yourself and Manage Expectations are good ideas but I think they both require agreement with the functions and within IT on the schedule(project plan?), level of effort estimates and resource assignment.

    Reply
  2. Excellent advice!

    Reply
  3. Good article. Including DevOps as part of a sprint’s Definition of Done (DOD)/Acceptance Criteria helps with the success of continuous integration, which is a driver in alleviating some of these issues.

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

Share This Page
Share on FacebookTweet about this on TwitterPin on PinterestShare on LinkedInShare on Google+Email this to someone