Problem:

When implementing DevOps, experts typically focus on process and tooling, but little emphasis is given to the psychological and social aspects of team members, which can pose encumbrances to DevOps adoption in production software houses. Training development staff on DevOps tools and processes is costly, so a significant risk occurs when training fails to produce full adoption by development teams. At the end of the day, people will adopt the tools and processes, but if there is no heathy culture, then DevOps fails to help the organization, and eventually may even cause more harm. In this blog post, I explore strategies for understanding and overcoming employee resistance to DevOps.

Team members have a psychological and social experience at work that often directly impacts a person's productivity and willingness to team. While team leaders are often trained on matters related to software engineering, they may not be well versed in the sociology and psychology of teaming and the team skills required for healthy and productive teaming. We know from studies of aviation and health care teams that proper teaming skills with a psycho-social slant can significantly improve the team error rate, efficiency, and effectiveness. What are those skills? Before I cover these skills, let me immerse you in the psycho-social experience of the development staff when DevOps is introduced.

It's been our experience in working with software application development teams that the development staff is often required to take mandatory DevOps training. However, many employees may be unaware of problems that drove management to adopt DevOps processes, which in turn breeds anxiety and fear. Suppose most employees had some knowledge of problems that led to DevOps instantiation. A common attitude among seasoned developers is: Well, the field has developed code for decades, and nobody has lost their job yet. In fact, we need more software engineers, so why should I change. Developed code still sells. DevOps cannot fix poor legacy attitudes.

The decision makers behind the DevOps instantiation are often removed from daily software development routine. How could these decisions makers be expected to know what the problems are and to know what solution, whether DevOps or not, is the best fix if these individuals are not immersed in the ranks to witness the daily grind?

The daily exposure to psycho-social team problems that often impedes team productivity and/or makes meetings unpleasant results in an unforgettable memory that demotivates. These problems can include dealing with an underperformer on the team that everyone must compensate for, or the manager who micromanages team processes. Often DevOps is sold as a panacea for any software development problem. However, DevOps alone cannot fix poor teamwork, social disputes, and managers who cannot evolve management practices to best suit the needs of their employees. Although productive work collaboration is a trainable skillset, it does not magically appear as a personality-based virtue as a result of frequent team meetings.

With the increased reporting requirements accompanying the new DevOps process, the team workload will rise and the privacy will drop. The quickest way to demotivate a team is to increase productivity output with incremental incentives and a looming fear of disincentives.

Tools used to improve team productivity and collaboration are typically repurposed to monitor individual and team performance. DevOps tooling is powerful and will be able to identify whether a person is an underperformer; which is anxiety-provoking. Even for the most productive, the unauthorized full-disclosure of work productivity and work quality is fear-inducing, even when these people have the least to fear. For less-productive employees, transparency can also incite stress, which further slows down work productivity. If DevOps leads to more meetings, additional reporting commitments, and learning new tools employees must eat those costs on their own time (e.g., in their evening hours and/or weekends) or suffer less productivity.

Finally, the DevOps tooling (see our posts on DevOps tools here, here, and here) is not safeguarded from repurposing to penalize team members for perceived poor performance. These tools are not designed to provide objective performance data for managers to analyze for promotions and job performance reviews. Instead, data (such as number of deliverables completed, number of tasks completed, average time on task, etc.) are repurposed as objective performance measures. However, these measures are often ridden with noise and missing data. Different team members have different reporting habits, even if the productivity is the same. As a result, employees may be incentivized to game the system, either by adding extraneous information to improve the appearance of productivity, minimizing their reporting, or hacking the tooling.

Remedies:

So what are the incentives to continue to work in an environment with increasing work demands, stress and a loss of personal privacy? There is no magic cure-all to these problems, but we do offer some suggestions based on research. First, the fields of healthcare and aviation safety have determined that teamwork skills are trainable, and training programs demonstrate significant reductions in overall team errors.

Crew Resource Management (CRM) is one such training program required by all aviation crews working for commercial carriers. This type of annual training includes team mental model building, team communication strategies, team situation awareness building, etc., and uses a metrics based approach to assess team performance changes after trained skills are implemented. Many interpersonal team disputes erupt from poor skills in these above areas. Intra-team disputes can slow down efficiency when interpersonal disrespect, stress, and anxiety pervade long after the dispute because teams lack skills to move forward after disputes. Team member attrition is a common side effect of interpersonal disputes that are never resolved.

Other remedies include the following:

• Start an honest conversation about efficiency risk. Not every employee works at the same pace, and some people are more error prone than others. Because DevOps makes each person's work pacing and quality more transparent, it is critical to remove fear of interpersonal judgment.
  
  For example,
  
  • Policies must be in place to protect team members whose mistakes will be made explicit.
    
    
  • De-emphasize team performance monitoring until team rhythm is perfected. Team members may want evidence that DevOps is addressing efficiency problems, but premature logging of team performance is risky.
    
    
• When the team becomes more efficient, any time savings the team accrues must be given back to the team to improve morale (e.g., time off).
  
  
• Customize rewards that enhance team member motivation and morale.
  
  
• Reduce team member hierarchies as much as possible and equally distribute power, respect, responsibility and importance across members.
  
  
• The organization must make it explicit that employees are their greatest asset, and actions must back up the sentiment.
  
  
• Leaders should build a learning culture by success stories and collectively solving mistakes.

Looking Ahead

As we explore DevOps implementation and best practices in various domains, we will also examine the impact of people. Organizations can establish best processes and best technologies with the right tool stacks, but successful DevOps implementation hinges on the people who use these technologies with the right processes. We welcome your feedback on the DevOps Blog, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To view the webinar DevOps Panel Discussion featuring Kevin Fall, Hasan Yasar, and Joseph D. Yankel, please click here.

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.