The Scream

When your Devops implementation is flawed what do you do? Run in circles, scream and shout?

DevOps is difficult. It's not something that can happen overnight no matter how hard teams try. It requires compliance, collaboration and the willingness to try new things. There is no one way of implementing DevOps across a team. From what I've read, lots of teams within various companies do it differently. However, though there are different practices, these teams exercise the same core principles which basically amount to multiple teams working together to support each other while testing and deploying rapidly.^[1]

Culture Clash

Unfortunately, one of the biggest issues when implementing DevOps (in my experience but most will agree) is the cultural shift. And that's what makes DevOps difficult. It's not the tools, it's the people. You can change tools, make them "work", that's the easy part. But you can't change people, you can only persuade them.

The cause of this depends of course on the situation. It could be lack of knowledge from leadership who may be unwilling to follow this new path simply because they do not understand it. And for this reason they may feel threatened. Another reason could be not wanting to change. Because who wants or needs change? "Things have been great the way they've been and we've never needed this as everything has been working fine." Which makes total sense because here in tech things move slowly and there is no such thing as advancement.^[2]

And sure, you may take the time to deliver multiple presentations internally, educating your team or even your Technical Lead one-on-one to minimize conflict and social engineer the situation to sway them when asking for change. However, no matter how hard you try the result is imperfect. You're at a better place than in the beginning. But it's not where you need to be. Because your DevOps implementation is half-assed. Who re-painted the purple fence red on the front but left the back purple?

Then you're stuck.

So what do you do? Surely, you don't want a war. Your job isn't to be a soldier and you know you should stay out of politics. In this case, it's best to minimize conflict. Because you understand that this transition won't work if leadership isn't on board.

"This is Fine" GIF

Let things Fail

The issue it seems is communication. How do you reach your leaders? Surely, the presentations aren't working. Is there something else going on? You're getting paranoid. You need to tone it down. You're too passionate. Don't be this passionate or you will be disappointed.

Just wait and see. Let it happen and eventually when things fail you'll have multiple examples of why the current process isn't good enough and that's why you must "go all the way."

And through the flames you emerge.....

Hellmo GIF

It's unfortunate that this is what it takes to not only "force DevOps" but do what you set out to do. Yet, this is the only alternative when educating leaders doesn't work once you've exercised all options. This is part of continuous improvement. I personally believe that in scenarios such as these, it's important to let things fail. The reason being so you have an example to reference such as, "...this is why we should tag commits. So we can track changes between different environments" for instance.

Fail to succeed

When bringing DevOps practices to a new team it's important to understand that it will take time. For this reason, you have to lower your expectations. You also shouldn't resist. If you're hired as a DevOps Engineer it's because your team or organizations needs it. And whether or not it's embraced by leadership or developers instantly, if there are any issues they will be exposed. So you must give in and endure the resistance.

Failure overcomes resistance to change better than education because failure in a way is in itself a learning tool. You held the meetings, gave the presentations on why changes need to be made in order to "achieve DevOps." Though that didn't work, you've allowed things to fail. Learning from our mistakes is something we first learn as children and continue to learn. It makes us better humans. Incidents such as these are bound to that same philosophy. It's part of the process. It's not only a learning experience for leadership but also for the DevOps Engineer.

You may also feel responsible if things go wrong or blamed for things going wrong and that's okay. Blame culture is extremely toxic. It's unproductive and creates an uncomfortable work environment. However, this is all part of the process too and as such you have to be stoic in how you respond. Eventually, these failures will become their own examples and you will be able to pick up the pieces.

Be Gentle

In the beginning of this post I mentioned how DevOps is implemented differently in various organizations. However, it's important to note that regardless, if a team chooses to not have a Dev environment there are still things that must be implemented independent of tools that need to be followed or you will fail.

Teams have to not only work together but change how they work.

Approach this gently. If leadership refuses to follow the principals or make lazy excuses regarding there not being enough time to practice the tenets of DevOps it's important to have a "This will be fine" attitude. Allow everything to play out because eventually things will come crashing down. Because DevOps practices aren't something you can cherry-pick and expect to work. You have to go all the way.