Except then it's not DevOps. If you have people working on 'DevOps' 100% of the time, that means they aren't working on Dev, and are only working on Ops.

The idea behind DevOps is that Dev(elopers) do their own Op(eration)s, rather than throwing stuff over the wall for a separate team to manage.

Not only has the industry done the opposite in many cases, they kept the name DevOps, meanwhile the full time operations staff have over complicated deployments and builds to the point that even they don't understand how they work anymore.

I agree that the term was kinda stollen and in many places Ops became DevOps while still doing Ops stuff 100%.

I think there is a place for both. Going into DevOps does not mean you need to get rid of your Ops team.

I like the approach when Ops are handling the backbone infrastructure of the organization while individual teams work in DevOps methodology meaning they are responsible for building necessary application infra, programs, as well as bringing it to production and monitoring.

Yes, many enterprise devs I know are completely uninterested in infrastructure.

This is also a great way of scaling teams - keeping a path of least resistance that is secure and compliant while giving observability and conventions.

Infrastructure in enterprises is usually completely uninteresting, to be fair. You need like eight different people on a call in order to stand up a VM, install a service, and configure a database connection.

Broken processes and missing self-service, as you point out, is why creating a platform team is important for these types of places. They might not know it yet, although some are trying.

It doesn’t make the infra technology more or less interesting?

Or any CS field for that matter.