All fair points. (Although I'm not a fan of the climbing analogy, the joy of programming is that you can practice anything you want without risk of real harm, a

All fair points. (Although I'm not a fan of the climbing analogy, the joy of programming is that you can practice anything you want without risk of real harm, and I think that's what makes unicorn-like programmers: they've repeatedly done the equivalent of free solo El Capitan practice in their spare time and lived to to tell the tail.) I think it's help to consider excellence in the context of principals and practice. Everyone should be aiming for excellent principals for their domain and environment. But the practice that implements the principals needs to be specific to the capabilities. E.g. I think in principal, any company with any tech should have backups, and ideally the ability to rebuild after a disaster. If you have a team of unicorn engineers ("company A"), the principals might be put into practice by meticulously tight and efficient SDLC and accompanying pipelines, tooling and other scripts and automations. If you have only one very competent engineer ("company B"), but a huge bunch of traditional ops people, that principal might have to be put into practice with a more manual, basic process (Bob from accounting once a week makes a copy of the important spreadsheets on a CD and stores it in a fireproof safe at home.) Both businesses can deliver excellent and reliable service for their customers because they implement excellent principals in a way that their employees can deal with. Swap company A and company B's practice, and even though it's for the same excellent principal, everything falls apart. I think we're in agreement here. It's an uncomfortable truth that - on average - 50% of environments are company B. There's a problem that 90% of companies want their practices to look like company A. Nobody wants to feel mediocre.