The DevOps Paradox

As the evolution of technology marches forward, more and more tools and knowledge becomes available. We actually have so many tools and so much knowledge at our disposal nowadays that it’s sometimes difficult to choose what tool(s) we use and what knowledge we use. Of course, all tool-inventors and knowledge-makers have their own opinions, mental models, and beliefs. The same goes for Linux and Open Source engineers and management (in the broadest sense of the word). With this in mind, how is DevOps ever going to work?

Modern scientists and a growing number of authors argue that we drastically need to change the way we are currently working. We need to alter our mindset, company goals and the way we achieve those goals. Some of the publications in the field form the scaffolding for DevOps. Think of “Drive” by Daniel H. Pink, “Mindset” by Carol S. Dweck, and “The Goal” by Eliyahu M. Goldratt. Of course the whole Agile/Scrum, Lean, and Continuous Delivery movements, cannot be forgotten in this regard.

All these words of wisdom say we need to collaborate, invest in culture, and stimulate personal growth. Great! Point is: if you encourage everyone to grow as an individual and endorse people to have their own opinion, how do you make sure things will still get done? What might be a good idea to person #0, may sound like the worst idea to person #1. (In IT we start to count at zero, right?) Since every engineer should be stubborn by nature, things might not improve.

Then, there is management. In a way, they are even worse and more stubborn than engineers. They have a lot of wild ideas and are very opportunistic, but often have no clue how to actually implement something. Sad, but true. Managers are often busy with change management on a corporate level, be it restructuring, cost saving, optimizing, R&D-ing, and other types of ing-ing. So in a way, they are always busy changing, and in most cases, with the intention to improve things. Since companies rely on IT a little more every day, decent knowledge of what IT is and what’s going on there, is no joke. Because this is an article about DevOps, let’s keep it close to the chest. As a DevOps trainer, I sadly have very few managers, executives or chiefs in my classrooms. Of course, there are several ways to upgrade your IT knowledge, but I find the lack of management in my classroom to be troubling.

Before things get uncomfortable for my team at “AT Computing”, when they read this, I must confess I’m not an engineer myself. Yes, I try very hard to keep track of all the cool CLI-stuff my team is doing, but they are simply way more talented in that area than I am. Despite this sometimes causing a dent in my technical self-confidence, and a lot of fun and laughter, it does not relieve me from trying to stay in their slipstream. And neither should this for other managers or directors.

If you have no clue of what the (Linux) engineers are doing, how will you be able to facilitate and support them? Even worse, how are you going to make the right decisions for the company?

All of the above result in a kind of stalemate. On the one end are the engineers that say, “I want to change things, but the management doesn’t allow it.” or “I’ve changed, but they are still doing the same thing.” On the other end are the managers saying things like, “My engineers are stuck in old habits; they do not want to change,” or, “I’ve started a project to implement DevOps, but it failed because the engineers did not embrace it.” As you can see, both sides want to change and are, on their own, trying to change, but because they are blaming each other, nothing really happens. That sounds like quite the paradox to me!

How can we battle this status quo? That’s really simple and really hard at the same time. First, we need to start talking. Not through email, Telegram, Slack, or a good old conference call, but all together, in the same room. Make sure there is coffee and some snacks, and make sure you leave all your assumptions and grudges at home. Be open. Be honest. Listen to understand, not to respond. Try to find mutual interests, common goals, or irritations, and just get to know each other a little better. We all have a personal life and some hobbies, right?

This meeting will not magically solve issues. After it’s over, you cannot say, “we are DevOps now.” What will this conversation do, then? It will make you level. It will make it clear that, within the company, you are all on the same ship, and you all have reasons to help that ship sail. This improved understanding provides a small but firm foundation to take the next step. Maybe managers will be willing to attend a technical training, and get out of their comfort zone. Maybe engineers will be interested in learning more about coaching, collaboration, and leadership. Most important, is that the DevOps journey starts. Only in that way, will the principle of flow originate. And, by pure coincidence, that happens to be “The First Way of DevOps”.