Hey folks, do you think hiring „DevOps“ is already an anti-pattern today?

Not necessarily. Software development has reached a point where it makes sense to have developers who specialize in certain skills or aspects of development. You have devs that specialize in UI design or security or performance optimization. By the same token, you can have devs who specialize in build and release processes, environment configuration, etc. I think the problem is that as a label, “devops” doesn’t really have a widely agreed-upon definition. Every interview I have starts with me trying to nail down what the other person thinks “devops” means (regardless of which side of the table I’m on). However, if you’re trying to find candidates with certain specific skills, it’s a more useful label than just “software engineer”. These days, I’ve taken to referring to what I do as “developer productivity engineering”. Basically, I use technology to make dev teams more efficient and productive. I’m more “dev” than “ops”, because I started my career as a developer (and still think of myself as one).

That sounds good 👌🏼 Initially DevOps stated as a Mind-Set that ideally (every?) developer should have “you build it you run it” The “productivity engineering” or Dev in DevOps now seems to be part of Platform engineering. I also approached DevOps from the engineering side. The Ops of DevOps could also be a dedicated SRE Position, which could be a good fit for former “Ops” engineers or?

It’s important not to get too hung up on labels or classifications. At the end of the day, my objective is to get developers working and testing in an environment that is as close to production as possible, as painlessly as possible. The closer to production they get, the more reliable their software will be. The more painless it is for them, the more happy and productive they will be. Productive developers creating reliable software are more likely to generate profit. “You build it you run it” is fine, provided “run it” isn’t so difficult that it erodes dev productivity because they’re spending more time “running” and less time “building”. “Platform engineering” is fine, so long as it doesn’t abstract devs so far away from production that they end up developing for the abstraction and not the “real world” — that’s just another variant of “works on my machine”. Also, one must keep forefront the idea that the platform serves the product and isn’t the product itself. If your dev team is having to adapt itself to the platform (seen it happen!), then you’re sacrificing productivity. SRE is a critical function, but if SREs take production in a direction that becomes increasingly difficult to approximate in development, you will again end up with variants of “works on my machine” problems. These hazards become increasingly difficult to avoid as the organization scales upwards and engineers have to become more and more specialized. That’s why I get more satisfaction out of working with smaller orgs… ;-)

Agree on that 👍🏼 As the question originated from hiring perspective it could still be helpful to see for applicants what to expect, instead of asking “what’s your definition of DevOps” 😅

Heh. Yeah, from a hiring perspective I think a more clearly defined job description will get you a long way. Since “DevOps” is such a general term, instead you might want to hire for “SRE” or “Platform Engineer” or “Developer Productivity Engineer”. I know, for example, if I see that last title I’m probably more likely to be a match than for just “DevOps Engineer”.

i really love this page and the info here https://web.devopstopologies.com/ personally I think having devops as a team or job title is a bit of an anti pattern and this page can help think through what someone means

It's definitely an anti-pattern for hiring. Organizations need to hire capabilities not roles. DevOps doesn't represent a capability or a role. Hiring should be based on a clear capability gap associated with a problematic constraint (we need to improve quality, automate database changes, scale environments) and devops is too broad to be useful.

For me it is about products, abstraction and reducing cognitive load. DevOps came about because we figured out how to virtualise infra and that led to the ability to define it in code and have it on demand. That in turn led to lots more code that dealt with stuff that even the full-stack devs of the day weren't really up to speed with. Our build/deployment scripts became provisioning scripts, became fully-fledged applications whose domain was infra and deployment and networks and... way too much for any one app team. The DevOps team anti-pattern evolved out of necessity. It was not a great solution, but someone needed to give all those unloved scripts some real love! In the absence of the right abstraction that would let teams focus on one domain at a time, it was what we ended up with. Today, this is evolving into platform engineering and platform as a product. We are introducing abstractions that let app teams focus on their app and not on the infra which we all sleep-walked into owning. As I see it, DevOps team is an anti-pattern when you view DevOps as a team that does all the scripting that none of the real devs want to do. The better implementation is platform teams and platform as product, which leaves app teams with a "you build it you run it" responsibility that isn't too big of an increase in their cognitive load.