April 2, 2019: Question Series #13
Written By: Ryan Ferguson
Follow Us on LinkedIn!
The DevOps Handbook recommends a lot of different ways to introduce and implement DevOps processes. One of the more interesting proposals is that you don’t need to do it from the top down. A grassroots effort, supported by a focused team, is capable of making great strides and proving the overall premise. This would theoretically take place prior to a broader, organization-wide transformation. While true, this premise doesn’t address a key simple fact — transformational change is always more effective when supported by visionary leadership. In the remainder of this article, I hope to give just a little bit of guidance to executive leaders on how they can provide that supportive, visionary leadership to ensure a successful transformation.
The most important thing to remember when leading DevOps is that it’s ultimately about speed: speed to market, speed to new ideas, speed to respond, and speed to recover. When a company invests in DevOps, it’s investing in speed. The second most important thing to remember about DevOps is that it’s a lot like roller coasters, sports cars, or anything else that goes zoom — if you don’t first build in safety, nobody will be comfortable going fast. The consequences of disregarding this could be disastrous.
This safety concept will apply throughout the transformation, but it has to begin with giving the team the psychological safety to experiment. DevOps can be phenomenally scary for all sorts of people:
- Will I automate myself out of a job?
- What if my automation fails and causes an incident?
- What if I fall behind in my other work while I’m experimenting with this difficult new thing?
- How can I implement DevOps when I need so many other people to help?
- How will these measurements be interpreted?
- Will there be an impact to our performance review?
These are some of the most common, fear-based questions I’ve answered when coaching DevOps. If leadership doesn’t ruthlessly eliminate the underlying fears, the DevOps transformation is doomed to tepid success at best, but more likely it will fizzle out like wet campfire wood: a few pops and some smoke, but nothing worth being excited about.
The best thing a leader can do to support their DevOps transformation is to give the team their full-throated support for investing time and energy into it. What does this look like? It means dedicating sprint capacity for your development team(s) to get educated and focus on opportunities to improve their daily work. It means vocally, via public town halls or other large scale events, drawing attention to the initiative. It means collaborating with peers to engage their support (as we’ll see below, a DevOps initiative can only go so far before it touches multiple departments). It means clearly and unambiguously stating (and showing) that the only result of any failed experiment will be learning, and that success will be rewarded with new opportunities and not job elimination.
Once a leader has created psychological safety for the team, it comes time for the hard part. A great DevOps transformation LOOKS like an automation effort, but it’s really a cultural transformation around what the technology organization prioritizes and values. Automation is the symptom, but the root cause is a culture of safety, measurement, continuous improvement, and intellectual curiosity. As leaders, it’s our job to let the team focus on the automation while we establish and nurture the culture.
I can hear you now asking, what can leadership DO? What, specifically, is a leader responsible for when leading such a transformation? Like any other Agile product creation, we should start by providing the team with a clear, manageable objective that they can independently complete and demonstrate. In many organizations, this is the creation of a small-scale automated test suite. In others, it’s a metrics dashboard that can guide future sprints’ work by giving insight into what’s working good enough and what needs to be fixed right away. The state of the organization, where the burning platform is, and what resources are immediately at your disposal will guide where you start, but I suggest the following based on my experiences:
- Let the team pick what to build (automation-wise) first. They will frequently already know, as a result of their daily frustrations, which is the most important first target. If they don’t know, or are unsure, suggest to them to build the metrics platform first to gather measurements. This will encourage intellectual curiosity in the culture, too. Measure, then make a change based on the observed data, and then measure the results again to plan the next change.
- Emphasize that learning is more important than success. If the team learns something from every action, success will follow. This can be done with things like failure parties — where the team comes together to share what they learned and celebrate their failed experiments.
- Incrementally invest in the right training, infrastructure, and tools for success. Remember, the most successful teams have the safety to experiment. Such safety includes test laboratories and robust live systems that are failure tolerant. If the organization doesn’t already have these, ask the team how building them can be achieved, so that the remaining efforts can be done with a higher degree of freedom (and, therefore speed).
- Monitor the team road map for when the time is right to expand the effort. Market the learning and successes widely so that when the time comes to involve other departments (such as IT Operations, Service Delivery, Info Sec, or Development groups) they are excited, willing participants to support the continued efforts.
There you have it. Those are my four key items to consider to lead a successful DevOps transformation. This article is just a starting point; a place from which to inspire and begin the DevOps transformation journey. It starts by creating psychological safety for the team, expands into self-directed improvement of daily work supported by canny investments, and continues into a broader organizational movement, inflamed by localized wins. The ultimate goal of a DevOps transformation is to implement the fast, consistent flow of value to our customers. It starts by creating a safe, learning-oriented environment within our own organization, long before the customers ever see a change. Building such an environment is a technology leader’s most challenging modern task, but the market has proven that such a journey is not optional, and, thankfully, bears rewards equal to the difficulty.
What do you think? What is in your Top 4 list for a DevOps transformation? Thanks for reading!
Be on the lookout for more upcoming #QuestionSeries articles on the topics of Program Management, Leadership, Technology, and Careers.
Want to read more featured articles from the Question Series? See our Featured Articles page for more!