This is the fifth in a series of posts around DevOps culture and lessons learned from Patrick Lencioni’s leadership book The Five Dysfunctions of a Team - A Leadership Fable.
- 5 Dysfunctions of a DevOps Team: Absence of Trust, explored how trust is the underpinning of adapting your team’s culture to transform for the DevOps movement.
- 5 Dysfunctions of a DevOps Team: Fear of Conflict, explored how high performing teams are not afraid to engage in passionate dialogue around issues and decisions that are key to the business or mission.
- 5 Dysfunctions of a DevOps Team: Lack of Commitment, explored how organizations of all shapes and sizes need better buy-in around objectives and deliverables as it relates to their DevOps initiative.
- 5 Dysfunctions of a DevOps Team: Avoidance of Accountability, explored how clarity of new roles, expectations and KPIs are needed to hold one another accountable.
Now I would like to explore the fifth dysfunction of a team - Inattention to Results.
Inattention to Results
The fifth dysfunction, inattention to results, is the ultimate dysfunction of a team and refers to the tendency of team members to care about something other than the collective goal / mission of the group. An unrelenting focus on specific objectives and clearly defined outcomes is a requirement for any team that judges itself on performance. And while it is true that many organizations in a capitalist economic environment ultimately measure their success by profit, revenue or shareholder returns, this dysfunction refers to a far broader definition of results, one that is related to outcome-based performance.
One of the key ingredients to DevOps is velocity. Many, if not all, DevOps teams (and Agile teams as well in truth) measure themselves on frequency and quality of releases. The ability to 1) understand what is most important (derived from accountability) and 2) quickly being able to make decisions and act under pressure is a monumental skill that must be mastered to achieve velocity. Automation can help, but it isn’t the solution to every problem either.
Time is the dominant parameter.
Some DevOps teams are using OODA (observe, orient, decide, and act) loops which was designed over 50 years ago to aid military combat. The basic premise was that victory could occur by creating situations in which one can make appropriate decisions faster and catch the opponent off guard. This is exactly the scenario that DevOps teams face today given the continuous change within cloud computing, virtual systems and modern, web-based applications. The confluence of cloud computing and open source code has made it easier than ever to quickly deploy systems into production and iterate frequently.
However, this agility often comes at a price: as the pace of development speeds up, IT operations staff are constantly playing catch up to the current state of the system. Visibility and context suffer. Ops and Dev people become adversaries instead of allies. In modern IT operations, the OODA loop process can help DevOps teams stay ahead of issues and react quickly and accurately. An OODA loop can also facilitate a DevOps team’s ability to respond to specific objectives and clearly defined outcomes.
More information on OODA loops is available here.
Caution Ahead
A trend that we’re seeing in enterprises is DevOps teams being created. As it relates to the 5 Dysfunctions of a Team, this has potential consequences dependent on the makeup of the team. These small teams who spin out to go figure out how to do DevOps in your business can fall prey to the lure of status. The team status of that hand-picked team begins to seep into the culture and they often just see success as merely being associated with their special organization. As a leader, this is definitely something to be mindful of.
As obvious as this dysfunction might seem at first glance, and as clear as it is that it must be avoided, it is important to note that many teams are simply not results focused. They do not live and breath in order to achieve meaningful objectives, but rather merely to exist or survive. Unfortunately for these groups, no amount of trust, conflict, commitment, or accountability can compensate for a lack of desire to win.
Perhaps more than with any of the other dysfunctions, a DevOps team leader must set the tone for a focus on results. If team members sense that the leader values anything other than results, they will take that as permission to do the same for themselves. Enabling streamlined collaboration between different parties, preferably in the DevOps fashion, is imperative to supporting the model of OODA and fostering business agility. Companies want to realize the benefits of DevOps ― cost savings through automation, agility and driving innovation, to name a few. Making the best decisions rapidly can be a life or death matter in the modern IT operations environment.
