I feel like we've all seen so many "DevOps engineers" that we've kind of forgotten that DevOps is not a job title but a philosophy (which you also mentioned in the article). Often I see that behind these titles are just infrastructure people who are siloed in their own little world and are not always helpful for building actual DevOps culture. Don't get me wrong- I love infrastructure people and I think they're essential, but DevOps should be a collaboration between the dev team who owns what they ship and the infra engineers that work to enable the dev team to do it. So often it doesn't really look that way...
I agree with both sides here but in most orgs and this generation. Especially the advent of vercel and “easy” to run infra trying to upskill your team to this level will require time and skill cost.
Yes it’s a mindset and philosophy but I think Fred states it best here most orgs aren’t mature enough especially as they are trying or just achieved product market fit. The contractor solution does feel like the safest you can cut if it doesn’t work and you scale it if it does until you reach your team.
100%, devops was meant to be a philosophy to bridge the gap between dev, QA and ops, but it became a job, and there are reasons for that:
- lack of cloud skills amongst the systems engineers
- need to scale that new trend
- need to build a business over the trend (and the YAML engineer was born)
Being a systems engineer and 30 years long UNIX practitioner (and maybe expert after all), I must confess I have some issues with people who deploy things but have no idea how they work in the background.
I feel like we've all seen so many "DevOps engineers" that we've kind of forgotten that DevOps is not a job title but a philosophy (which you also mentioned in the article). Often I see that behind these titles are just infrastructure people who are siloed in their own little world and are not always helpful for building actual DevOps culture. Don't get me wrong- I love infrastructure people and I think they're essential, but DevOps should be a collaboration between the dev team who owns what they ship and the infra engineers that work to enable the dev team to do it. So often it doesn't really look that way...
I agree with both sides here but in most orgs and this generation. Especially the advent of vercel and “easy” to run infra trying to upskill your team to this level will require time and skill cost.
Yes it’s a mindset and philosophy but I think Fred states it best here most orgs aren’t mature enough especially as they are trying or just achieved product market fit. The contractor solution does feel like the safest you can cut if it doesn’t work and you scale it if it does until you reach your team.
100%, devops was meant to be a philosophy to bridge the gap between dev, QA and ops, but it became a job, and there are reasons for that:
- lack of cloud skills amongst the systems engineers
- need to scale that new trend
- need to build a business over the trend (and the YAML engineer was born)
Being a systems engineer and 30 years long UNIX practitioner (and maybe expert after all), I must confess I have some issues with people who deploy things but have no idea how they work in the background.
Amazing article. This is so true A-Z