I used to repeat this statement, but a few years of the current pattern, I disagree. (I'm going to generalize for UNIX systems, apologies in advance) Your tra

I used to repeat this statement, but a few years of the current pattern, I disagree. (I'm going to generalize for UNIX systems, apologies in advance) Your traditional systems engineers are well versed in the ways of UNIX, but that does not automatically qualify them to wear the DevOps hat. And vice versa. Systems and DevOps are two different sides of the house. There is an entire tooling set that someone with the DevOps attribute needs to be aware of (CI/CD, tools that enable code review, etc), how they tie into the tools that the developers use, and how to troubleshoot when these things break down. You, Systems Engineer, will be called when someone can't run "npm install" and an ERRNO message scrolls down the screen. While it could be something as innocent as a missing header file from an external dependency, it's still on you to rapidly troubleshoot and resolve. You also need someone with UNIX and networking infrastructure chops. Someone who is familiar with a how to generate and read a packet capture, or maybe even use strace. You, DevOps, will be asked why does it take forever-and-a-half to run 'ls' in a directory containing 10,000 files. Scratch that, you will asked to make it faster. It's unreasonable to ask either of these folks to stretch and cover the other role, it results in a lot of resentment in how they're expected to do "two jobs" as well as complaints from developers that the DevOps/Systems Engineer's priorities and timelines don't line up with their own. Worse, you'll see abominations (a relative viewpoint) because everyone knows their tools the best. To a person with a hammer, everything looks like a nail. I've seen automated DNS failover triggered via Jenkins, and I've seen automated code deployment triggered via cron on a 5 minute schedule. DevOps is more than automation, it's about enabling developers to rapidly iterate in a sensible way that doesn't cause too much wake around a growing startup, an already functioning business, or a fast moving behemoth. It's about enabling operations to rapidly provision new applications, monitor existing applications, properly perform capacity planning, and create repeatable infrastructure ...repeatedly. And it's about both developers and operations coming together to onboard new employees into the environment in a short timeframe, so they can become productive. This is all not to say that DevOps and traditional Systems Engineers + Network Engineers should live on different teams. Ideally, they're all on the same team, with different roles, and plenty of communication and cross-training.