Depends on the business model, cater to high end clients and having a ~1M$/year doctor be the once answering the phone can be a major selling point.
Further you optimize around costs, when having people answer phones is expensive you try a minimize the need for someone to answer a phone. A 5 minute call with someone making 200k is like 8.50$. Empower them to figure out and fix the underlying issue thus avoiding the next 1,000 calls and that looks cheap.
I don't want to wade too deeply into the argument is a computer support engineer worth 200K USD per year, but this comment really stands out to me:
> Empower them to figure out and fix the underlying issue thus avoiding the next 1,000 calls
Some of the best software engineers that I have worked with saw every support issue as a chance to fix a bug and/or improve logging/docs. Sometimes they built little tools to do more complex support tasks (update complex config) in moments instead of hours. (Yeah, yeah, I know about this XKCD: https://xkcd.com/1205/)
If I were to guess about Oxide's view of "support engineers": They aren't traditional L1/L2 support. They are essentially software devs who happen to excel at support. As a mentioned earlier, if they respond to a customer call (or email), they might have a quick workaround, then go and fix a bug or update logging/docs.
Moving the goalposts so that support engineers with deep technical skillsets are actually software devs is kind of a dick move.
From someone who's worked both sides of the glass -- support engineering is way harder.
You don't get to play in a nice, standardized, performant environment. You're often parachuted into a random customer issue, with little context and an unstable environment, someone nervously watching over your shoulder, and a customer director/VP demanding updates every hour.
And from watching traditional software devs be pulled into those calls and flounder past "works on my machine," live debugging is a very different skillset on top of technical expertise.
Not only do you have to thoroughly understand the happy path, but you also have to tread both known and unknown failure paths.
One of my litmus tests for product companies is how they set up their support orgs and escalation paths: as checkboxes or continuous improvement loops.
The former approach tends to produce shitty products.
I mean, if a software system is not behaving as the user expects, either the software system behavior is incorrect or the system producing the user expectations of the software is incorrect, and wherever the problem is, if it is not fixed it is likely to recur.
Further you optimize around costs, when having people answer phones is expensive you try a minimize the need for someone to answer a phone. A 5 minute call with someone making 200k is like 8.50$. Empower them to figure out and fix the underlying issue thus avoiding the next 1,000 calls and that looks cheap.