This and
>DevOps is about avoiding the, "Just throw it over the wall," mentality, not making one person handle the whole thing.
this are why it's now part of my interview process when I'm interviewing for a new role "how does your company/team define DevOps?" and I listen very closely for things that sound like 'over the wall-Ops'. Admittedly having the fortune at this point in life to be quite judicious about the answers given.
Ostensibly, if I'm applying for a 'DevOps' role, I shouldn't have to do this if the job description is written well enough, yet even then this has become a learned behavior even when coming across the rare well-articulated job req.
Having devops teams and engineers isn’t the same as practicing devops, but once you scale up your org, you’re going to end up with them, anyway.
For example, someone who is good with ci/cd pipelines, infra as code and just generally in automation and observability, as opposed to someone who is strong with linux internals or JavaScript
You can tear down silos all you want, but everybody can’t know everything and people will always specialize.
The organizational question is whether the ops folks are (physically/organizationally) colocated with developers on dev teams, or colocated with themselves on an overarching ops team.
Do we really need a new term for this?
It just sounds like common sense.