First half of the DevOps movement: teaching sysadmins to code. From that we got infrastructure as code (Terraform, Cloudformation), configuration as code (Chef, Ansible), CI/CD (Jenkins, TravisCI, CircleCI).
I (and my colleagues) argue that the second half of the DevOps movement should be about teaching developers to take ownership of their service in production. Thanks to decades of work from SREs, sysadmins, infra and ops engineers, and others, we now take for granted many mechanisms to make our services more reliable: autoscaling, load balancing, retries, failovers.
That means what's left are much more interesting problems--subtle ones that are hard to debug and often involve a confluence of factors, in both the business logic and the infrastructure. Ops engineers can't be expected to respond to these issues alone.
On top of that, I believe both parts of the DevOps movement can reduce burnout and improve job satisfaction. We've gotten good at identifying and reducing problematic toil, but that's not enough. Practitioners need to see the impact of their work.
Most people want to do a good job, but without tight feedback loops it's difficult to know if what you're doing is right for your users. If you're going months between releases then by the time a change goes out you've long since forgotten about it. It's easy to extrapolate how a team with such a long release cycle would end up on a death march, building the entirely wrong product according to spec and burning out in the process.
It's not just about making engineers happy, as much as we love to talk about that. Helping your team improve their practices enables them to do better work, more efficiently, and with fewer issues. Most people want to do a good job. As practitioners, we take pride in our work. Help us pour that into making your business more successful. Don't let that priceless enthusiasm go to waste.
Accelerate, book by Dr. Nicole Forsgren, Jez Humble, and Gene Kim