How should I approach an anti-devops company culture?

Question

I've recently joined a small company, maybe sub 200 people, as a Senior DevOps engineer. The company is about a decade old at this point.

While it was made clear in the interview process that the company was very immature in their DevOps journey, after seeing inside the company for a little bit, it's becoming clear to me just how anti-devops the company culture is.

I could honestly write thousands of words as to how backwards their DevOps approach is - for one thing, we do monthly releases because there's no CICD integration from QA, who do half their testing by running and watching scripts, and the other half manually.

In the short time I've been here not only have I basically seen every DevOps anti-pattern written about, I've seen active defences of them.

How do I go about determining if I've got a chance at making any kind of impact in such a company, and when should I decide to just call it a day and start looking for other positions? I'm honestly feeling at a loss as to what I can do here - I've never been in a company this opposed to any kind of basic modern practice before.

Casey Dai · Accepted Answer

I hear you in terms of aversion to DevOps or Engineering discipline as whole, as one of the biggest problems I had to tackle when leading an engineering team working with another large team of data scientists had a lots of these symptoms you're referring to. We eventually got into a better state where there's a more robust path to getting enterprise-grade software out the door with some Git and CI/CD in place, but that takes time and persistence (at least 1 year in my situation).

That being said, before choosing to jump ship, here are a few things I'd try / consider.

Find the people who were part of your interview process that are an advocate for DevOps. Enlist their help and start with understanding what led them to create this role. There has to be some benefit they're expecting, which correlates to implementing DevOps (or some consequences they experienced by not doing so).
Socialize your "DevOps anti-patterns" finding with those who you think are most likely to support you first (i.e. people from #1). Do this in a constructive way though where you frame this as how it will benefit the company if you do X. For every anti-pattern bring some solutions / options they can consider.
In parallel to enlisting support from #1 and #2, find some areas where you are not dependent on other people and implement that change yourself - this can be a wide range of things: write a test, use version control, use infrastructure-as-code, etc. Take a baseline before you start and then measure / quantify the benefit after you make that change (DORA metrics are a good starting point - fewer bugs, faster delivery times, etc.)
If there was a P1 / Sev1 incident recently that can be traced back to one of these anti-patterns, you can use that as a case study and suggest a different approach. Leverage your supporters from #1 & #2 to back you up.
Talk to the people who you feel are adverse to DevOps and understand some of the underlying reasons why. For my situation, it was mostly caused by thinking writing tests and putting in engineering rigor is going to slow them down. Others simply weren't aware of DevOps concepts since they didn't come from a traditional SWE / CS background. Get to the underlying reason why they are resistant and build your case around that in #3 & #4.

On last thought it to not take implementing DevOps to an extreme after you've gotten a bit of traction. One mistake I made was anchor too much on quality/discipline after a certain point, which wasn't necessary given the use case / business criticality.

How should I approach an anti-devops company culture?

Discussion