This is the fourth 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.
Now I would like to explore the fourth dysfunction of a team - avoidance of accountability.
Avoidance of Accountability
The fourth dysfunction is an avoidance of accountability among team members. In the context of teamwork, it refers specifically to the willingness of team members to call their peers on performance or behaviors that might hurt the team. The essence of this dysfunction is the unwillingness of team members to tolerate the interpersonal discomfort that accompanies calling a peer on his or her behavior and the more general tendency to avoid difficult conversations. Members of great teams overcome these natural inclinations, opting instead to ‘enter the danger’ with one another.
The basic premise of DevOps is that most organizations with IT functions have separate teams responsible for software development and for IT operations (aka Service Management). These teams are motivated by related, but different, problem sets that create natural tension between those who deliver changes and those who are incentivized to maximize service availability and hence prevent changes along with other such obvious threats. So it is not difficult to imagine that as new ‘DevOps teams’ are formed, these tensions hit a boiling point. But how a team responds to these issues will determine their ability to be successful or not.
One of the best ways to make it easier for your DevOps team members to hold one another accountable is to clarify publicly exactly what the team needs to achieve, who needs to deliver what, and how everyone must behave in order to succeed. For most organizations, the definition of success/failure is vague or undefined which can lead to your DevOps team not having a clear set of expectations that they can hold one another accountable to. As a leader it is imperative to take the time to define what success looks like and to create a culture of accountability. In order to create this sort of culture, team members should regularly communicate about how they feel their teammates are doing against stated objectives and standards.
The enemy of accountability is ambiguity
Another aspect of your DevOps team that needs to be clearly articulated is the separation of duties and roles & responsibilities of those on the team. DevOps is not and cannot be reduced to a single role. If anything, it's more about the makeup of teams than individual roles. If you're doing DevOps, you regularly have Devs, Admins, DBAs, Storage, etc. all in the same room working on the same thing. You can't really abstract that interaction into a separate role.
Spike Morelli (@spikelab), a DevOps consultant, listed a set of skills anyone with "DevOps" in their job title should have:
As your DevOps initiative takes shape, part of the learning process should be to clearly document these new required skills/roles, what the expectations and dependencies are, and any key performance indicators that you want to achieve. But to make it work and to avoid team dysfunction, leaders have to be willing to set the example, confront difficult issues and demand personal accountability from their team members. Eventually, the concept will seep into the team culture, giving the team more autonomy and the leader more time to focus on other pressing issues.
