But… I’m going to say the dirty, quiet, and unlikable thing out loud.
That had nothing to do with DevOps or its philosophies, processes, or patterns. That was bad leadership from the top down plain and simple. It’s likely not even the individual engineers faults. It’s leaderships fault for not setting clear objectives, implementing them, ensuring that the engineers had a real plan before beginning, and making sure no individual was too in charge of things.
Leadership in your case was likely career management who knew very little about technical items. Managers who were technical were probably shot down for not playing politics properly, not producing the correct “metrics” and “kpis”. So they moved on.
That’s a company culture issue that has little to do with tech.
I have known and worked with some really great former sys admins gone devops. I am working on mentoring one right now, but I have to be kind of insulting about it and be like “forget everything you knew before it probably won’t help now” which sucks because sys admins do form pretty decent understanding of OS’s, databases, networking, etc. however, when it comes to the code part and more importantly taking all of these concepts and applying them to reasoning about infrastructure code and complex systems is very hard for most people and you have to take a “im a total newb” mentality a lot of people dont seem easily capable of doing.
Still, it made me very wary of the idea that devops is separate to development.
The complete, unapologetic desire of devs and security teams (but also many infra teams) to not have any kind of ownership was horrifying to me.
In the end there's not a single solution or strategy, it really goes back to the organization and where your weaknesses and strength are as an org. If you have a gazillion consultants following the "best practice" of the day and exceptions on top of exceptions you are dead, devops or otherwise. You will still make billions if you are the right company though regardless of your software practices, so...
I worked for a bank for a short period of time, where the development team had gone a bit far with a shotgun approach to moving their systems to Azure. It was pretty hard to find things and as their approach evolved, the older conversions weren't revisited. Most of that team quit. New team is brought in (including me) which had some excellent engineers with years of experience in system architecture, how to make Azure work better. So we tried to homogenise things around a more reasonable approach.
This caused operational problems to worsen (understandably) but it was a short term pain, long term gain thing we couldn't be allowed time to do. So the CIO decided to take all the sysadmin/devops type work and give it exclusively to the system administrators. Who weren't developers. They fixated on one particularly narrow solution for deployment. To make it easier for themselves, but one that didn't really address the bigger picture of how to make it easy to monitor and deploy etc.
Anyway it ended up a disaster. The development team in their newly narrowed roles struggled to make their systems fit in the rigidly defined holes. Operationally it was no better and sometimes worse, but there was absolutely no compromise on how things should work or any consultation with the devs at all, ever.
I no longer work there. If you're going to do devops you have to listen to your experienced engineers, not the snotty kids who think clickops is engineering.