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\u2019s 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?<\/p>\n
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 \u201cDrive\u201d by Daniel H. Pink, \u201cMindset\u201d by Carol S. Dweck, and \u201cThe Goal\u201d by Eliyahu M. Goldratt. Of course the whole Agile\/Scrum, Lean, and Continuous Delivery movements, cannot be forgotten in this regard.<\/p>\n
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.<\/p>\n
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\u2019s going on there, is no joke. Because\u00a0this is an article about DevOps, let\u2019s 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.<\/p>\n
Before things get uncomfortable for my team at \u201cAT Computing\u201d, when they read this, I must confess I\u2019m 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.<\/p>\n
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?<\/p>\n
All of the above result in a kind of stalemate. On the one end are the engineers that say, \u201cI want to change things, but the management doesn\u2019t allow it.\u201d or \u201cI\u2019ve changed, but they are still doing the same thing.\u201d On the other end are the managers saying things like, \u201cMy engineers are stuck in old habits;\u00a0they do not want to change,\u201d or, \u201cI\u2019ve started a project to implement DevOps, but it failed because the engineers did not embrace it.\u201d 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!<\/p>\n
How can we battle this status quo? That\u2019s 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?<\/p>\n
This meeting will not magically solve issues. After it\u2019s over, you cannot say, \u201cwe are DevOps now.\u201d 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 \u201cThe First Way of DevOps\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"