I think there are different definitions of DevOps.

I see a difference between a more definite operations team (SRE) vs an engineering team having responsibility for how their service works in production (DevOps).

DevOps is something that all teams should be doing - there's no point in writing code that spends it's life generating problems for customers or other teams, and having the problems arrive at the owners results in them being properly prioritized.

In smaller orgs, DevOps and SRE might be together, but it should still be a rotation instead of a fulltime role, and everyone should be doing it.

Engineers who don't do devops write code that looks like:

  if (should_never_happen) {
    log.error("owner=wombat@example.com it happened again");
  }

Where the one who does do devops writes code that avoids the error condition entirely (usually possible), or decides what the code should do in that situation (not log).

> The only folks who like devops are those that haven’t touched anything else, or are scared to move out of that molehill.

IDK I've been called everything from: SysOp, SysAdmin, Network Engineer, Systems Architect, Solutions Engineer, Sales Engineer, Platform Engineer, etc. Half of those at different companies are just "DevOps" depending on the org.

In my career, DevOps was never a separate organization. It was a role assumed by the code owners. SRE (is it up, is the hardware working, is the network working?) was separate, and had different metrics.

Having separate teams makes it adversarial because both orgs end up reporting into separate hierarchies with independent goals.

Think about the metrics each team is measured on. Who resolves conflicts between them? How high up the org chart is it necessary to go to resolve the conflict? Can one team make different tradeoffs on code quality vs speed from another, or is it company-wide?