Jessica DeVita and I recently had the pleasure of speaking at The Incredible Automation Day in Paris, France. TIAD has themes around learning to learn, experimentation, cloud, IoT, and de-automating ourselves.
That last one, de-automating ourselves, was particularly intriguing to me. That concept can be taken several ways. To me, it sparked ideas around how we–the royal we, as DevOps practitioners–should strive to extract ourselves from our automated processes. Recent trends in automation (especially IoT) illustrate that effective automation is about using the inherent advantage machines have in order to teach them how to do jobs faster, safer, and more reliably than we can. That being the case, why is it that in DevOps we’re inclined to simply automate the exact same things we used to do in front of a keyboard rather than taking advantage of computers to decentralize operations and de-automate our own legacy practices in the process?
For Jessica, TIAD sparked ideas around continuous improvement and practical ways each of us can implement Kaizen principles in our daily lives. As we move toward ubiquitous automation in our lives, are we losing the relationship with our surroundings and ourselves? Sometimes we need to take a step back and think about broader goals. Her challenge to technologists is to think more closely, now more than ever, about what we want to actually accomplish.
We both had a chance to discuss DevOps culture with Julien Lemarchal from D2SI. The interview below is translated from the original (French).
Julien: Although DevOps is sometimes discussed as a matter of tools, it is above all about culture. Leading a successful DevOps transformation requires understanding and integrating a culture based on collaboration, transparency, and automation. Are we past a culture of competition and now in one of cooperation?
Jessica: IT has a long history of suffering from a culture of information retention. The knowledge people have, their knowledge of a particular process for example, can sometimes become their only perceived value. But businesses and IT departments have had to adapt to meet growing demands and figure out how to scale. Tribal knowledge doesn’t scale. In the era of automation and DevOps, not sharing information goes against the core tenets of collaboration and transparency. That’s a cultural change, but that change must be supported by tools.
George: Indeed, that transformation relies on tools, but it’s not about the tools themselves. For example, I’m often asked if using Chef requires using Git. As long as you’re using some type of source control, my answer is that it’s not so much about using git itself. The real question is whether your source control manager allows anyone to fork your code to make it their own, does it allow them to easily submit contributions to your code, can you collaborate and discuss those changes openly and easily? Those are the outcomes we want. Git just does that by default. You can’t change culture directly, but you can change behavior. Certain tools enforce the behavior you want and that behavior becomes your culture.
Julien: Automation is a new way of working and potentially threatening to some. How can we take steps to ensure that automation isn’t seen as threatening in order to promote adoption?
George: Automation can be daunting at times. In companies where employees have performed the same task for many years, even decades, it may feel threatening to your sense of security. But in these situations, we need to lead by example. Automation solves problems. Work with people to understand the problems they’re experiencing. Understand what can be improved. Progress means advancing in small steps. Find the quick wins. Show how automation can improve our jobs and make them more enjoyable. It’s time we shatter the myth that automation means the end of IT jobs. I’ve been trying to automate myself out of a job for 20 years and it still hasn’t happened. When we adopt automation, it changes the scope of our work. It changes what we do. Instead of acting directly on systems, we’re acting on code and that code acts on systems. We have to test our code,we make changes faster, we have to test our underlying dependencies, we have to gain visibility into all of that underlying automation…we open ourselves up to new and more interesting challenges. Automation is an opportunity to learn new things.
Jessica: Adopting automation is a cultural transformation and it’s necessary to help people make that change. We can’t see that need as “trolling” or as a barrier. We’ve all had times when we needed help learning how to change. First and foremost, we need empathy in those situations.
Julien: Is advancing in small steps towards a culture of DevOps also characteristic of the Kaizen philosophy you’ve spoken of at TIAD ?
Jessica: Yes, Kaizen is a philosophy that plays a big part in the journey toward the automation we all have to adopt. We all have mechanisms that make us resistant to change, mostly because we can be uncertain about how to take our first steps. We’re afraid of making the wrong decisions or choosing the wrong tools. Engaging in radical change requires courage. Gaining confidence is a personal process and to help us do that we rely on Kaizen principles.
Julien: How is the rapidly accelerating pace of technology changing the ways we learn in IT?
Jessica: We need a new approach to learning. IT has long favored formal and structured training. That approach still has validity, but what we see in IT is that a particular degree is not necessarily a reflection of talent. A certification does not guarantee the success of your project. In today’s market, IT professionals are learning what they need to know on the job, which is why they’re driven to work in interesting situations. Continuous learning in IT is one of the greatest benefits of our journey into automation: anyone can learn static skills, it’s not about what you know it’s about how you learn. That doesn’t mean it will be easy. You have to want to be challenged. But that’s something we must encourage: the willingness to learn and to question what we know.
Julien: Does adopting DevOps mean that companies must also transform into being completely open and transparent?
Jessica: The impact of adopting a DevOps culture is that it forces transparency. It is impossible for a company to scale without ensuring that everyone has the necessary knowledge to be effective in their role.
George: The flip side is that some think that DevOps means absolutely everything is open, everything should be transparent to everyone: destroy all silos! But I think the purpose of DevOps is to ensure that the right people have access to the right information when they need it. DevOps is about striking the right balance between transparency and compliance. We need to share information quickly, but we also need to have visibility into and–if necessary–audit who has access to that information just as quickly. As we share more information and as we expand a culture of DevOps across our entire company, it’s necessary to ensure we’re maintaining compliance at that new and higher velocity.