I have been privileged to be a part of the technology sector these last two decades. In the last four years, we have seen a fantastic shift in ability for companies to innovate, thanks to what has been aptly called "DevOps". Drastically oversimplifying, DevOps is the unification of the Operations and Development groups inside of an organization; leveraging Culture, Automation, Lean, Measurement, and Sharing (CALMS) to rapidly accelerate software from Development to Production. Companies like eRetail startup Etsy have used DevOps to rapidly develop their products and capture huge market share; likewise, DevOps has also brought light speed agility to established giants such as Amazon, Apple, Facebook, and Fidelity to be able to deploy thousands of times a day. In the face of such demonstrable results, it is uncertain how companies that aim to compete in the marketplace can do so without embracing DevOps.
And since software rules the world, we tend to look to software to improve our situation. Indeed, software has allowed us to automate, measure, and lean "all the things" to achieve some amazing results. Yet, every day companies seem to be waking up to the realization that software alone isn't enough. Just a simple google of "DevOps failures" gives several pages of new listings from the last month. It seems that these companies are just late to learn what Patrick Debois discovered near the beginning of the DevOps movement: “DevOps is a human problem”. Fittingly, the IT Revolution Press bookends the DevOps acronym of core principals with two people-centric items: Culture and Sharing. But, even some of those that have put people first are among those who have failed. So then, what is the missing ingredient that hinders IBM's success with DevOps and enables the Etsy’s? I am afraid I don’t know of any spell to conjure, but I but my meditation on this subject has led me to three magic letters: DNA.
In reading numerous interviews of some of the DevOps Elite, I have noticed a recurring pattern: Servant Leadership. Ken Blanchard breaks down Servant Leadership into a threefold role: servant, steward, and shepherd:
The Servant – seek to meet the needs of others
The Steward – take great care and consideration of what has been entrusted to you
The Shepherd – protect, guide, and nurture those under your sphere of influence.
In the preface of The DevOps Handbook, Jez Humble, Gene Kim, Patrick Debois, and John Willis give brief interviews as to how they got involved with DevOps. Though I have only met Gene Kim a couple of times, and know none of them personally, I do not believe they were motivated by a quest for glory or self-interest. The common theme among their interviews was that they saw their peers struggling and, thus, they felt compelled to find a better way to help their community. This required many years of swimming upstream against a long-established IT culture of anti-patterns rewarding fiefdoms, silos, and lone wolves. For those of us who have been in the industry any real length of time, we have either been participants or victims of this culture (or perhaps both).
Servant Leadership, isn’t that just culture? No, though if you have a culture of Servant Leadership, that is a beautiful thing. Culture is the result of group action and thinking, and each of the aforementioned pioneers had to initially go it alone. Such was their isolation, that in their brief few paragraphs, each of them noted the moment when they encountered like-minded individuals. The realization that you are not alone in the world is a life changing moment.
What then would make them do an about-face and sacrifice of their own selves to swim upstream for the greater good? I submit that it is the same thing that drive the salmon upstream: DNA. Not that these individuals were endowed with some sort of “altruism” gene; but somewhere along the way these individuals had developed a sense of purpose that extended beyond themselves. This could have been instilled in them in the home as young men, or perhaps a result of counseling from a great mentor in the workplace. Subscribing to Dan Pink’s theory of what motivates us, because of that purpose, they leveraged their autonomy and mastery in the pursuit of the solution to this complex problem.
And I think this is a common missing component across the Technology-sphere, whether you are “DevOps’ing”, or not. One cannot simply list “Servant Leadership” as a core value in the employee handbook and reap the rewards in a few quarters. To truly get your organizations to go against the current, begin to openly collaborate and share, and work to a common business objective; you are going to have to rely on individuals that have the Servant Leadership DNA. Even if this requires a transplant. This is needed at all levels, or your servant leaders will leave. With top-level servant leaders in place, your front-line servant leaders will have the support they need to continue to face cultural adversity for the sake of everyone under their watch.
I believe the heart of a Servant Leader can only be taught by example. I am the truth of that statement. I owe Dave Lavanty, now VP Public Sector at Adobe, a debt of gratitude. When he met me, I was a quick-tempered lone wolf upstart. I am certain that I was a challenge that caused him to lose a few winks on occasion. And the entirety of the lessons he taught me still haven’t fully soaked in. I am still learning from those past lessons today. If it wasn’t for his persistence of Servant Leadership towards me, I am certain that my current state would be far worse than I enjoy today. And because of this truth, I do my best to be a servant leader in all things I do, both in and out of the workplace.