I'd have a contrary view which is that yes you DO want your engineers to understand dev and ops (and sec and change etc etc) and actively be able to own a service through its lifecycle.
Those engineers might have different focuses; so maybe building a data store, or an api, or a Jenkins system, or an artefact store....
If you leave your cicd tooling and toolchains to a team then you create a dependency, and for me a key part of devops is reducing dependencies.
The suggestion in your post is that by blurring the traditional roles you make those people less productive. And therefore the solution is to create a new role.
That's fine: but that's the old thinking (IMO) hanging around. The original intent of devops would definitely run counter to that :)
Those engineers might have different focuses; so maybe building a data store, or an api, or a Jenkins system, or an artefact store....
If you leave your cicd tooling and toolchains to a team then you create a dependency, and for me a key part of devops is reducing dependencies.
The suggestion in your post is that by blurring the traditional roles you make those people less productive. And therefore the solution is to create a new role.
That's fine: but that's the old thinking (IMO) hanging around. The original intent of devops would definitely run counter to that :)