It's interesting to read the proposed "SoftOps" approach - it's something I've been trying to do in my own little bubble, working on making the lives of develop

It's interesting to read the proposed "SoftOps" approach - it's something I've been trying to do in my own little bubble, working on making the lives of developers easier (especially when getting their code from repo to prod), with the developers creating systems. I volunteer for a convention run entirely within VRChat, with a handful of supporting services (API for tracking players, instances and registration, frontends for admin and attendees, and so on), and while the department is named "DevOps" (too late to change it, and everyone knows what we mean), I landed on the infrastructure subteam. While part of the job was building out our new Kubernetes cluster (mostly for scaling. I'm still working on the blog post about this sort of stuff), I wanted to make sure that the developers could be completely abstracted away from _where_ their code was running, and as much as possible _how_. Of course, they're free to mess with whatever tooling I setup for them (mostly Docker images, GitHub Actions, etc), but I've found it very fulfilling to "exist to serve" (because infrastructure? servers?) the developers pushing out code. If we need some custom internal tooling to support that development cycle I'm more than happy to get something written and deployed (something for the blog post). It may be barebones but I wouldn't stop a developer from another team contributing (provided they don't have something more pressing). All this to say... I really like supporting developers in their work, as a sort of meta-engineer. edit: worth pointing out I do something sort of similar at my current employer, but it lands a bit more on the type of devops that the author describes as having failed, and I'm actively working to see if I can find a position that better suites my skillset!