3 ms·

Good article, resonate a lot with my experience. When recruiters come by and say "I looking for a DevOps engineer" that's a big red flag: DevOps is not a job,

Good article, resonate a lot with my experience. When recruiters come by and say "I looking for a DevOps engineer" that's a big red flag: DevOps is not a job, it is a philosophy to be applied to all related jobs within the software supply chain! As idiotic as if people come by to present themselves as "Agile Engineers" or "Scrum Engineers"... However: I do not think the DevOps philosophy is bullshit, far from it. Not perfect, like Agile methologies, meant to be bended and adapted. But once a month I hear stories from legacy ITIL-based organisations, which are point-to-point mentioned pain-points from "The Phoenix Project"...

tstrimple 3y ago
Not sure why you're being down voted here, but I agree. So many companies are building "DevOps" teams which is just another silo. Folks who understand DevOps should be embedded in the project team. They should be functional developers who also know how to automate workloads. They shouldn't be building and maintaining pipelines for 40 hours a week. They should be working on the product and one element of their role is automating the infrastructure, builds and deployment of their components. The companies I've worked for which grokked DevOps didn't have dedicated DevOps teams. They had developers who understood automation embedded in the project team and the DevOps component was just one small piece they were working on. In companies which struggled, they setup separate dedicated DevOps teams and hired explicit "DevOps engineers" which you'd submit tickets to in order to get your pipelines built and changed. One of these enabled the teams to accelerate development and releases significantly, and the other just felt like you had a traditional ops team that was more of a barrier to getting work done. I view building software delivery teams similar to (in my imagination) building a "special forces" team. You cannot afford for your team to be taking on a building of terrorists only to come up against a locked door so your team shrugs and says "guess we'll have to open a ticket with the door breaching team". You've got to have the "specialists" you need embedded in the team or your "mission" will grind to a halt waiting to borrow resources from teams with different priorities.

tstrimple 3y ago

Not sure why you're being down voted here, but I agree. So many companies are building "DevOps" teams which is just another silo. Folks who understand DevOps should be embedded in the project team. They should be functional developers who also know how to automate workloads. They shouldn't be building and maintaining pipelines for 40 hours a week. They should be working on the product and one element of their role is automating the infrastructure, builds and deployment of their components. The companies I've worked for which grokked DevOps didn't have dedicated DevOps teams. They had developers who understood automation embedded in the project team and the DevOps component was just one small piece they were working on. In companies which struggled, they setup separate dedicated DevOps teams and hired explicit "DevOps engineers" which you'd submit tickets to in order to get your pipelines built and changed. One of these enabled the teams to accelerate development and releases significantly, and the other just felt like you had a traditional ops team that was more of a barrier to getting work done. I view building software delivery teams similar to (in my imagination) building a "special forces" team. You cannot afford for your team to be taking on a building of terrorists only to come up against a locked door so your team shrugs and says "guess we'll have to open a ticket with the door breaching team". You've got to have the "specialists" you need embedded in the team or your "mission" will grind to a halt waiting to borrow resources from teams with different priorities.