I’m really happy to see that the media is thinking the DevOps movement is going prime time (The Wall Street Journal: Reporter’s Phablet: Big Companies Agree, DevOps Has Hit the Big Time). It is awesome to see the success of DevOps Enterprise Summit (DOES15) conference: great presence and great presentations where major corporations has presented their DevOps journey.
I’m afraid that we’re starting to celebrate too early.
There is much more to be done to enable the new approach to go mainstream. I believe that we’re just barely passed the middle of the “early adopters” cycle. By the “Crossing the Chasm”’s (Geoffrey A. Moore 1991) terms we’re approaching a dangerous and treacherous zone of the “chasm”.
You can observe this by ever increasing amount of “DevOps tooling vendors” and a lot of burned out people that curse failing DevOps initiatives.
I believe that we’ve just passed the “peak of inflated expectations” of the Hype cycle and going down the the slope towards the “Trough of disillusionment”.
I believe that, in Simon Wardley model of Pioneers, Settlers and Town Planners terms, we’ve just passed the “Genesis” stage and now heavily colonizing the “custom built” one with the explosion of the DevOps automation tooling and solutions. In my opinion we’re a bit far from moving to “Product + rental” stage. We’re still “pioneers” of DevOps. It’ll need something extra, next evolutionary step to become “settlers” – the main stream adoption requires a little bit different ingredient. I’m convinced that the step from the settlers into the “town planners” will be much harder than from the “pioneers” into “settlers”.
Over the last 5 years of leading DevOps adoption in multiple organizations, I’ve identified an illusive element that was present in the successful transformations and was missing in not so successful ones. This element is very rare in nature and very hard to find it in pure form – this element is Leadership.
This element is the third pillar of the successful DevOps in addition to two already identified ones – Culture and Automation/Tooling. In fact, I’m convinced, it was always present in CALMS definition (John Willis, 2010) – it was, in fact, hiding behind L (Leadership). Originally L was for Lean, but if we’ll squint for a second, one can argue, that we can get Lean from proper Culture and Measurement – we’re not going to engineer something that our measurement doesn’t prove.
The Leadership ingredient is the most elusive one. It’s hiding behind each and every successful DevOps implementation success story. It is hiding within a great “culture” story. I think it is time to extract it into a self-evident one and call in for what it is. It deserves it’s own visible place in DevOps.
Let’s put Automation and Technology part of DevOps aside for a moment – it’s pure engineering problem and we know how to deal with them. The Culture refers to some “fuzzy” things like trust, empiricism, values, etc. The Leadership is what creates and enables great cultures which invent and create great tools and automation.
I want to explicitly talk about Leadership and not about Management.
“Managers are people who do things right and leaders are people who do the right thing” (Bennis & Nanus, 1985, p. 21). Burns (1978) describes managers as transactors and leaders as transformers.
Some may argue that Culture (in CALMS) is assuming a presence of Leadership. I disagree because “culture” exists on its own – it is an amalgamation of the group’s norms of behaviors, shared values, beliefs and experiences. This amalgamation can be great for some people and not so great for others. Some may say that their own company has a great culture, but, what I’ve seen, that doesn’t necessarily means that they can implement, sustain and foster DevOps. Without great Leadership nothing will happen on its own. On the other hand, having a great vision with amazing Leadership and buying awesome automation tools, without a proper Culture, the DevOps implementation is doomed to fail – over-enthusiastic and, sometimes not well DevOps-educated, leadership can create a lot of confusion when the Culture is not in the right place.
So I’m making the point that, only when you have these BIG 3 (Leadership, Culture, Automation) ingredients present together you may have a chance of enabling DevOps. We need to start talking about importance of Leadership.
Just recently I’ve heard Damon Edwards saying: “The only way to fix the complex system is to create conditions for the system to fix itself“. This means that you need to ENABLE the proper Culture. This is the job for Leadership.
James Kotter in his international bestseller “Leading Change” (1996) provides a recipe, the 8 ordered steps for introducing change into the organizations:
Establishing a Sense of Urgency
Creating the Guiding Coalition
Developing a Vision and Strategy
Communicating the Change Vision
Empowering Employees for Broad-Based Action
Generating Short-Term Wins
Consolidating Gains and Producing More Change
Anchoring New Approaches in the Culture
Kotter believes that “Cultural Changes Comes Last, Not First”. This is why he puts it as the last step #8. As he sais in the book (p. 164), he once shared the common prevailing belief that “first you change the culture and the rest will follow”, but all his research proved this to be wrong. He learned that process of anchoring the change in the culture has the following characteristics:
It comes last, not first. Most alterations in norms and shared values come at the end of the transformation process.
It depends on results. New approaches usually sink into the culture only after it’s very clear that they work and are superior to old methods.
It requires a lot of talk. Without verbal instruction and support, people are often reluctant to acknowledge the validity of new practices.
In addition I’ve found, that to drive the change into the organization you need to have 2 main forms of Leadership:
Top-down – executive leadership
Lateral or horizontal – pier-to-pier leadership and grass-roots
This discovery is supported by the recent revision (2014) of Leading Change” where Kotter International expands the scope from “Drive change with a small, powerful core group” to “Form a large volunteer army from up, down and across the organization to serve as the change engine”.
I’d like to summarize my point that it’s now time to crystallize Leadership as a main driving force of the DevOps adoption across the industry. It deserves it’s own focused attention from everyone. We all, at all levels of the organization, need to learn how to be and become Leaders if we ever want to transform our industry.
In my future posts I’ll dive deeper into the types of DevOps Leadership. It is a big topic on its own and deserves a special attention.
Meanwhile I’d love to hear your thoughts on the topic.
Note: Main picture Translated from the French at Quebec Meme.