I've seen engineers build and run a clustered database and make a total pig's ear out of it. Every day was another outage (or the continuation of yesterday's outage). Several times we were a hair's breadth from actual irrevocable customer data loss. Just because you got a few of your salaried engineers to build a DB doesn't mean that they had the correct knowledge and respect for data to do it properly.
I’ve seen people make a mess out of SaaS offerings that are supposed to be foolproof. If we assume that we’re hiring incompetent engineers, we can make a mess out of any situation.
You’re both right: most companies want to hire the least competent (least costly) engineer capable of doing the job. Then they have mixed luck in hiring and wind up with a distribution of engineers, including some plain incompetent ones. They barely have competent enough engineers to build their core product, let alone perform undifferentiated technical operations on self-managed infrastructure.
I agree with you that if we assume all our engineers are strictly competent, then that gives us a major advantage over our vendors, and tilts the scales to build over buy.
I don't think it's strictly about competence and more about specialism. In my personal experience, which you can take with a large grain of salt, what happens is that the engineering manager with a certain type of career history tends to look down on any type of operations work and anyone who does it. I have heard things that come off sounding like this: "We hire world class computer scientists from prestigious Ivy League schools and FAANG experience, so why do I need to hire some one-trick-pony DB guy, when my engineers could build their own databases from scratch?"
