The "concierge" idea is a new one that I hadn't heard before. It helps describe a piece that I feel is missing from what it is I feel that I do, because, so oft

The "concierge" idea is a new one that I hadn't heard before. It helps describe a piece that I feel is missing from what it is I feel that I do, because, so often, perhaps because the terms "operations" or "system administrator" don't have the word "software" in them imply that I don't understand it or can't apply engineering to it. Although I don't feel comfortable going as far as dictating the outcome of some version of the build vs buy decision, I agree that, when I happen to be on staff, tremendous value is lost by not at least consulting me as to what "buy" [1] alternatives are available. As an experienced technology (not just software!) concierge, I often know even more than one. Unfortunately, by the time I'm hired, it's almost always too late. Especially at modern startups, programmers very much run the show, so the focus is very much on writing new software. That said, I don't think this notion is unique to ops engineers. It can be extended to programmers, as well, in that very senior ones tend to follow similar models, of simpicity, code reuse, libraries, and, ultimately, eschewing actually writing (especially rewriting) new software unless necessary. [1] quotes because it's often free-gratis, merely not custom-written there