I have a few scattered thoughts about this, and I'm not sure I have a single thesis in this post, but I'll type up some of my experiences and hopefully it'll be helpful in some way. I have also been doing DevOps for 10-100 person engineering orgs for around 5 years, and I have also felt stagnant, interrupt-driven, and generally frustrated by perfectly capable engineers waiting on me to make them a database while I'm busy trying to keep their applications executing on computers.

I'll apologize in advance for talking about myself a lot in this post, I'm not sure exactly where you're at career-wise, and I don't like to be prescriptive about generalities, but hopefully something about my own experience can be helpful to you or someone else.

Thought 1: Norms become exponentially harder to change the longer they exist.

I did a poor job of setting the right norms when I started my previous job, and it resulted in a completely unsustainable environment where engineering was 100% focused on development goals, and I was responsible for keeping the product afloat. I consider this my mistake, because I was the one explicitly hired to handle that problem, and the way I handled it was by creating a single point of failure - me.

I don't consider that job a complete failure, I delivered on the things I was hired to build. But by the time I realized my mistake, it was already The Way Things Are Done. I didn't have the skills to change it, or even the words to explain it yet.

These days I generally try not to ops anything I didn't dev, and I expect the same from my colleagues from day 1. When someone asks me for a database, I say "Sure, let me come sit with you and we can walk through creating one." Which leads me to thought 2:

Thought 2: It's harder to teach someone to fish than it is to give them a fish.

But the corollary about eating for a lifetime is still true. It's usually faster for me to spin up a new database, but if I do it, I'm robbing the team of a chance to learn how their new database works. I am neglecting my responsibilities as a senior engineer when I don't take the time to teach.

I've been at my current employer for about a year and a half, and it's paid off - engineers routinely write infrastructure code, build their own containers and CD pipelines, and deploy new services to production. They use some of my tools to do it, and I make sure to take the time to help them be successful with them, but I make sure that they're the ones pushing the buttons. The payoff is in quotes like this, which one of my colleagues shared in our engineering channel today (paraphrased):

> This is long overdue but I wanted to give a shout out to @edwards for the ops tooling!!! I was able to deploy a new API (staging AND production) in minutes which, if I did manually, would have taken days. Thanks for iterating and giving us the tools to build things that Just Work. I have easily spent days on this in the past, especially things like connecting load balancers to services. And, with Cloudformation, we know we can easily recreate environments in case something goes wrong. Amazing stuff!!

Thought 3: Soft skills are harder than hard skills

No part of a computer is magic, and at some point you just sorta figure out how they work, and the mystery and awe of it fades out completely, and the job you're left with is giving rote instructions to an army of perfectly obedient, _ruthlessly_ pedantic children. They understand nothing and they don't sleep.

The difference between a junior engineer and a mid-level engineer is the breadth and/or depth of their technical knowledge, but the difference between mid-level and senior is how well they communicate that technical knowledge, and how they collaborate with others. This doesn't necessarily mean management, but it does mean a big adjustment in the coding/collaboration ratio. (These days I probably delete as much code as I write...)

One of the biggest ch...