as a long-time consultant in this space, i don't fully agree with this take. the entire point of devops was to make devs more ops-y and ops more dev-like, i.e.

as a long-time consultant in this space, i don't fully agree with this take. the entire point of devops was to make devs more ops-y and ops more dev-like, i.e. everyone is a developer. to some extent, the movement has been successful on this front. devs generally have a better idea of how to run platforms, and ops generally can write enough code to kind-of support them. tooling like terraform and kubernetes have helped a lot here. there are many companies that have definitely lost the plot (by forming devops teams that are glorified cloud admins or release engineers), but i'd say overall the bar is higher now. a lot of sysadmin jobs require shell experience and Git, which was definitely not the case ten years ago. the real reason why the culture part of devops hasn't "happened" is complex. in many bigcos, devs and ops are completely separate business units with different corporate agendas and kpi's. dev teams are also restricted from admin'ing their own stuff in production bc of audit risk, so even if they wanted to, it's an uphill battle. however, dev teams at these companies are by large incentivized by what they ship; ops is not as high of a priority. what i've seen a lot of lately are ops teams becoming platform feature teams with dev teams as their customers. many ops teams have embedded into dev teams like consultants to help them move stuff onto these platforms, and they make admin as hands-off for themselves as possible. devops is to thank for all of that. before "devops," zero-touch platforms were the hotness for ops teams, but they didn't have the chops to write the code needed to do that, so they became huge exercises in COTS integrations. i do agree that devops is very infra-biased, /r/devops is /r/syadmin redux, and that forming a "devops team" requires serious questioning