I’ve also found a lot of devops to be generally unhelpful and adversarial as well. They seem to forget the developer part of the job title and don’t help the developers deliver value to the customer. Instead some devops teams just break things unannounced, make sweeping changes that leave everyone unhappy, require unnecessary extra steps for simple procedures, and remain passive or negative.
I call those teams “developer obstructions” or DevObs for short.
Really this probably highlights the problem of having devops be it’s own role instead of a responsibility of a software team.
That resonates with my experience at large as well, which I find to be unfortunate.
I actually have come across a number of highly knowledgeable and talented sysadmins along the way, and I truly wanted the Dev part of DevOps to work and invested a lot of personal effort into trying to make it work although in vain each and every time.
Such individuals also have a tendency to create new, deeply entrenched silos that continue on to keep developers in shackles.
> I call those teams “developer obstructions” or DevObs for short.
With your permission, I will ecstatically add the new term into my daily professional vocabulary.
It’s very unfortunate! I don’t really know of a good solution other than stronger and more collaborative leadership preventing these “us vs them” silos. In effect the developers should be considered the customers of the devops team therefore they should be doing everything they can to aid the developers. Or, just have them in the sane team.
Yes definitely you can use it, credit would be nice though if the expression becomes well known ha ;)
I call those teams “developer obstructions” or DevObs for short.
Really this probably highlights the problem of having devops be it’s own role instead of a responsibility of a software team.