This is the third 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.
Now I would like to explore the third dysfunction of a team - lack of commitment.
Lack of Commitment
The third dysfunction is a lack of commitment among team members. In the context of a team, commitment is a function of two things: clarity and buy-in. Great teams make clear and timely decisions and move forward with complete buy-in from every member of the team, even those who voted against the decision.
One of the fascinating trends we're beginning to see in this whole DevOps thing is that many organizations are participating in some form or another of collaboration amongst key stakeholders, but that the definition of what success looks like for their DevOps initiative is unclear which creates ambiguity throughout the team and business. How can DevOps be successful if success criteria aren't clearly articulated? Are enterprises ‘doing DevOps’ just to do it or is there a transformation underway? And does anyone outside of the skunkworks project you’re heading up even know what DevOps is?
DevOps needs better definition and buy-in around objectives and deliverables pronto. And there is no one size fits all approach to DevOps, but rather an emerging set of critical requirements to ‘do DevOps’. But a warning signal for you to be on the lookout for is a tools mentality when discussing DevOps. Tools have a place most definitely, but dealing with these cultural and organizational issues are job number 1.
In a recent survey UpGuard conducted, we found that 27% of all DevOps initiatives were being driven top-down. Conversely, over 36% of all DevOps initiatives are considered a grassroots movement.
DevOps is still in its infancy stage where more startups have the advantage over larger enterprises due to their lack of financial, political, and technical debt. Additionally, there still is confusion amongst stakeholders as to what DevOps is, why they are doing it and what success looks like. This uncertainty creates a lack of buy-in from executives which then can lead to a dangerous ripple effect. You can have a kickass team that trusts one another and isn’t afraid to deal with the hard problems straight on, but without commitment from all of your business counterparts (Ops, development, QA, service management, security) and leadership teams (management, executives) you will slow yourself down from achieving greatness.
Conclusion
DevOps is a crappy term for a game-changing approach to how IT is delivered. I have little doubt that organizations of all shapes and sizes need better buy-in around objectives and deliverables as it relates to their DevOps initiative. We all know that feedback loops are critical (we’ll cover that another time), but once clarity of purpose is achieved and communicated, it then should be about understanding what you have and preparing yourself for automation. Because remember...you can’t automate what you don’t understand. It is not about looking for consensus whatsoever (that is impossible), but rather to rally around whatever decision is ultimately made by the group.
