5 ms·

DevOps is not a role, but a culture inside an organization I think we need to give up on fighting this fight. The thousands upon thousands of job postings wit

DevOps is not a role, but a culture inside an organization I think we need to give up on fighting this fight. The thousands upon thousands of job postings with that job title clearly indicate otherwise. Better to accept that the philosophical battle has been lost and that DevOps Engineer is the new name for other titles like "System Administrator", "Infrastructure Engineer", "Operations Engineer", or "Site Reliability Engineer". e.g. "The person responsible for dealing with making sure there is a way for the software to run somewhere and that it stays running."

philk10 3y ago
Like the fight between being called a QA and a tester = "we'll get the QA guy to QA the latest release" - oh, you want the tester to check the release as part of the QA process
- pavlov 3y ago
  "I've got a great idea for an app. Just need a coder to code the codes"
- Bilal_io 3y ago
  That's why we use Quality Engineer (QE) at my job
lucasyvas 3y ago
It's hard not to agree but this is a total loss. DevOps as a culture works, and what most organizations do doesn't. Why is it so hard to embed these specialists in a vertical team and bring that cultural change? My guess is that they have two work streams and effectively two people to report to: The team leader, and their own manager/director. I think this is a problem for businesses since it complicates traditional hierarchies in ways they are not prepared to deal with. A counter example is QA, that does more often get embedded within a team and promotes a quality first mindset - why get this right and not DevOps? I'm confused.
- tennis_80 3y ago
  Spitballing here but perhaps it's because people don't realise the DevOps work that can be done in a team, rather than just what has to be done. I work in a cultural DevOps place at the moment, and often spend my time improving CI workflows, improving the local dev environment and upgrading dev tools to make it easier to write features when requests come in. I could easily spend my entire week doing things like this, and it seems to pay off as we have a very low cycle time and fix bugs within minutes. However if you have a non-technical manager - they struggle to see value in this work. DevOps becomes "the way we get the project we built into our production environment" which is usually quite a small piece of work compared to actually building the project. So it becomes - we don't need one per team, hmm, maybe they should be centralised so we can share their time between teams, and then you lose the culture DevOps was supposed to create.
- ElevenLathe 3y ago
  The problem is that management needs there to be zero slack in the system, or they don't think they're doing their job well enough. I've seen this pattern over and over: 1) a new vertical team is created, including seasoned devs and ops hands, a bulldog of a PM, maybe a business analyst and QA as well 2) the team is successful, creating a new product that legitimately brings value 3) executives want a new line of business and so spin up a new dev team, but figure they can do it on the cheap by having the old team's QA/PM/Ops folks work for the new team too. 4) this happens a few times and now we've spun out the support functions to separate teams with their own managers 5) we're back at square 0 Why do they do this? Because they need to increase "efficiency" in order to justify their existence. They're managers, after all, so they can't directly produce value. Their only hope is to increase the efficiency with which work gets done. The problem is that a maximally efficient team/system is a minimally resilient one, and there's no one in the org who thinks their job is to promote resiliency. There's also the problem that showing an "efficiency" like one guy doing the job of three is concrete and easy to prove. An increase in systems-level efficiency -- by having three people doing three jobs and therefore not blocking any of the other expensive professionals on those teams -- is seen as as theoretical and largely hokum. I don't know that there is a solution to this really. Even bronze age militaries experienced similar dynamics, so I'm not hopeful we can solve it by doing "agile". Also, sometimes they are right: there really isn't enough ops work on a vertical team to justify a whole full-time employee, and they really can produce more value consulting for multiple teams. I find that this is rare though, and takes a special person who is adept at context-switching. Most people aren't, and I don't know of a repeatable way of training or identifying these people, so it isn't a practical strategy for big orgs who need these things at scale.
HelloNurse 3y ago
Grouping the minority of good organizations where DevOps actually means DevOps with the majority of clueless organizations who hire "DevOps engineers" meaning System Administrators is morally and practically wrong.
olddustytrail 3y ago
Site Reliability Engineer is a newer title than DevOps.
- elric 3y ago
  Those are very different things in my book. SREs can certainly use DevOps practices, much like software engineers can use TDD.
  - deleted 3y ago
    [deleted]
- RyeCombinator 3y ago
  That is so 2014, platform engineering is the new thing now.
elric 3y ago
It's sad and ironic. Organizations that have DevOps as a role often have DevOps teams, which tend to operate in silos, which is the antithesis of DevOps.
- siva7 3y ago
  Very true. It's a pretty common misconception even among more experienced software teams.
jbverschoor 3y ago
DevOps is the Dev taking part in the Ops. DevOps these days is sysop+better scripting and less iron
alexjplant 3y ago
> I think we need to give up on fighting this fight. The thousands upon thousands of job postings with that job title clearly indicate otherwise. > Better to accept that the philosophical battle has been lost and that DevOps Engineer is the new name for other titles like "System Administrator", "Infrastructure Engineer", "Operations Engineer", or "Site Reliability Engineer". As soon as I had a recruiter ask me "why are you looking to write software if you're DevOps?" incredulously on the phone I knew that there was no coming back from this. The fact that somebody whose literal job it is to have a good grasp of the technical labor market thinks that somebody can "be DevOps" (just because they have Kubernetes on their resume... never mind the slew of languages and frameworks) and that being such is orthogonal to software development is an unfortunate state of affairs.
- screwturner68 3y ago
  Most recruiters don't know the difference between C-shell and a seashell, why would you expect them to understand a topic most IT people can't fully grasp?
siva7 3y ago
This saddens me. Part of the blame is on the side of product namings like "Azure DevOps" which indicates to inexperienced devs that this is some kind of operations role if all they ever use are the build and deployment features. Then again, many junior devs start out as devs without ops experience so they don't have much knowledge about end-to-end development in state-of-the-art teams. Some even start out in shitty teams so they never learn much of the established best practices.

philk10 3y ago

Like the fight between being called a QA and a tester = "we'll get the QA guy to QA the latest release" - oh, you want the tester to check the release as part of the QA process

pavlov 3y ago
"I've got a great idea for an app. Just need a coder to code the codes"
Bilal_io 3y ago
That's why we use Quality Engineer (QE) at my job

lucasyvas 3y ago

It's hard not to agree but this is a total loss. DevOps as a culture works, and what most organizations do doesn't. Why is it so hard to embed these specialists in a vertical team and bring that cultural change? My guess is that they have two work streams and effectively two people to report to: The team leader, and their own manager/director. I think this is a problem for businesses since it complicates traditional hierarchies in ways they are not prepared to deal with. A counter example is QA, that does more often get embedded within a team and promotes a quality first mindset - why get this right and not DevOps? I'm confused.

tennis_80 3y ago
Spitballing here but perhaps it's because people don't realise the DevOps work that can be done in a team, rather than just what has to be done. I work in a cultural DevOps place at the moment, and often spend my time improving CI workflows, improving the local dev environment and upgrading dev tools to make it easier to write features when requests come in. I could easily spend my entire week doing things like this, and it seems to pay off as we have a very low cycle time and fix bugs within minutes. However if you have a non-technical manager - they struggle to see value in this work. DevOps becomes "the way we get the project we built into our production environment" which is usually quite a small piece of work compared to actually building the project. So it becomes - we don't need one per team, hmm, maybe they should be centralised so we can share their time between teams, and then you lose the culture DevOps was supposed to create.
ElevenLathe 3y ago
The problem is that management needs there to be zero slack in the system, or they don't think they're doing their job well enough. I've seen this pattern over and over: 1) a new vertical team is created, including seasoned devs and ops hands, a bulldog of a PM, maybe a business analyst and QA as well 2) the team is successful, creating a new product that legitimately brings value 3) executives want a new line of business and so spin up a new dev team, but figure they can do it on the cheap by having the old team's QA/PM/Ops folks work for the new team too. 4) this happens a few times and now we've spun out the support functions to separate teams with their own managers 5) we're back at square 0 Why do they do this? Because they need to increase "efficiency" in order to justify their existence. They're managers, after all, so they can't directly produce value. Their only hope is to increase the efficiency with which work gets done. The problem is that a maximally efficient team/system is a minimally resilient one, and there's no one in the org who thinks their job is to promote resiliency. There's also the problem that showing an "efficiency" like one guy doing the job of three is concrete and easy to prove. An increase in systems-level efficiency -- by having three people doing three jobs and therefore not blocking any of the other expensive professionals on those teams -- is seen as as theoretical and largely hokum. I don't know that there is a solution to this really. Even bronze age militaries experienced similar dynamics, so I'm not hopeful we can solve it by doing "agile". Also, sometimes they are right: there really isn't enough ops work on a vertical team to justify a whole full-time employee, and they really can produce more value consulting for multiple teams. I find that this is rare though, and takes a special person who is adept at context-switching. Most people aren't, and I don't know of a repeatable way of training or identifying these people, so it isn't a practical strategy for big orgs who need these things at scale.

HelloNurse 3y ago

Grouping the minority of good organizations where DevOps actually means DevOps with the majority of clueless organizations who hire "DevOps engineers" meaning System Administrators is morally and practically wrong.

olddustytrail 3y ago

Site Reliability Engineer is a newer title than DevOps.

elric 3y ago
Those are very different things in my book. SREs can certainly use DevOps practices, much like software engineers can use TDD.
- deleted 3y ago
  [deleted]
RyeCombinator 3y ago
That is so 2014, platform engineering is the new thing now.

elric 3y ago

It's sad and ironic. Organizations that have DevOps as a role often have DevOps teams, which tend to operate in silos, which is the antithesis of DevOps.

siva7 3y ago
Very true. It's a pretty common misconception even among more experienced software teams.

jbverschoor 3y ago

DevOps is the Dev taking part in the Ops. DevOps these days is sysop+better scripting and less iron

alexjplant 3y ago

> I think we need to give up on fighting this fight. The thousands upon thousands of job postings with that job title clearly indicate otherwise. > Better to accept that the philosophical battle has been lost and that DevOps Engineer is the new name for other titles like "System Administrator", "Infrastructure Engineer", "Operations Engineer", or "Site Reliability Engineer". As soon as I had a recruiter ask me "why are you looking to write software if you're DevOps?" incredulously on the phone I knew that there was no coming back from this. The fact that somebody whose literal job it is to have a good grasp of the technical labor market thinks that somebody can "be DevOps" (just because they have Kubernetes on their resume... never mind the slew of languages and frameworks) and that being such is orthogonal to software development is an unfortunate state of affairs.

screwturner68 3y ago
Most recruiters don't know the difference between C-shell and a seashell, why would you expect them to understand a topic most IT people can't fully grasp?

siva7 3y ago

This saddens me. Part of the blame is on the side of product namings like "Azure DevOps" which indicates to inexperienced devs that this is some kind of operations role if all they ever use are the build and deployment features. Then again, many junior devs start out as devs without ops experience so they don't have much knowledge about end-to-end development in state-of-the-art teams. Some even start out in shitty teams so they never learn much of the established best practices.