Don't want to get too deep into your analogy. I was addressing the "DevOps cannot code" part. To me it is a leadership failure if a DevOps team is still afraid of tackling bigger challenges (like the example given by the OP). That, of course, depends on whether DevOps teams will exist in the long run.

▲

prmoustache 9 hours ago | parent | next [-]

The very fact that we are talking about "DevOps" teams (that do not include dev) is wrong from the very start.

DevOps is a methodology, not a role.

▲

blutoot 9 hours ago | parent | next [-]

I've always felt that DevOps became a function/team partly because companies and especially SWE's started complaining that they were spending too much time "doing Ops work" and product/business started demanding more features for which they running out of cycles. And add to that the burnout from being on-call (especially if the dev team is relatively small and you have to go on-call every 2-3 weekends).

	▲	verdverm 9 hours ago \| parent [-]
		When I still did on call ops, devs got notified before us if their apps were the problem. We got notified first if it was our infra Having an ops team does not mean devs get to through on call team over the wall to someone else. That's a sure recipe for resentment and turnover

▲

pjmlp 4 hours ago | parent | prev [-]

For most HR departments it is a role, it even has a career path.

▲

verdverm 9 hours ago | parent | prev [-]

> the "DevOps cannot code" part. To me it is a leadership failure

Have you done devops yourself? It sounds like a resounding No. Like you complained ops doesn't like to code (not a core skill for the job), ops complains that devs can't understand basic concepts of how their software runs. Is this also a failure of leadership? Is everyone supposed to know parts of everyone else's jobs?