[dpkirchner]

Sure, and they should have that option. But in my experience business-folks ask techies to evaluate services all the time, and ideally we can just start out in the low-/no-touch tier to feel things out. If that tier isn't available, us techs might just try a different service.

[timr]

The kind of products hidden behind sales calls are generally the sort where the opinion of IC-level tech staff is next to irrelevant. With these kinds of products, the purchase decision is being made at a group level, the contract sizes are large, and budgetary approvals are required. It’s a snowball the size of a house, and it started rolling down the mountain months (or years) before it got to your desk. Literally nobody cares if you buy a single license or not, and if you (personally) refuse to try it because it doesn’t have self-service, you’ll be ignored for being the bad stereotype of an “engineer”, or worse.

About the only time you’ll be asked to evaluate such a product as an IC is when someone wants an opinion about API support or something equivalent. And if you refuse to do it, the decision-makers will just find the next guy down the hall who won’t be so cranky.

[TheTaytay]

I think this is true at larger organizations, but even a “small/medium” startup can easily sign contracts for single services for $100k+, and in my experience, salespeople really do care about commissions at those price points. A lot of software gets a foothold in an org by starting with the ICs, and individuals, not groups, are often the ones that request or approve software. Github and Slack are good examples of services who make very good use of their ability to self-serve their customers out of the gate, in spite of also supporting very large orgs.

In these conversations, I never ever see the buyers justifying or requesting a sales process involving people and meetings and opaque pricing.

It’s true that complicated software needs more talking, but there is a LOT of software that could be bought without a meeting. The sales department won’t stand for it though.

[timr]

> A lot of software gets a foothold in an org by starting with the ICs, and individuals, not groups, are often the ones that request or approve software.

Not really. Even if we keep the conversation in the realm of startups (which are not representative of anything other than chaos), ICs have essentially no ability to take unilateral financial risk. The Github “direct to developer” sales model worked for Github at that place and time, but even they make most of their money on custom contracts now.

You’re basically picking the (very) few services that are most likely to be acquired directly by end users. Slack is like an org-wide bike-shedding exercise, and Github is a developer tool. But once the org gets big enough, the contracts are all mediated by sales.

Outside of these few examples, SaaS software is almost universally sold to non-technical business leaders. Engineers have this weird, massive blind spot for the importance of sales, even if their own paycheck depends on it.

[cortesoft]

This is really not true in my experience. In fact, all my experience has been with products that aren’t THAT expensive, and the individual dev teams do decide. These are SaaS products, and sometimes the total cost is under $1000 a year, and I still can’t get prices without contacting sales.

Also, it isn’t just ICs. I have worked as a senior director, with a few dozen people reporting into me… and I still never want to talk to a sales person on the phone about a product. I want to be able to read the docs, try it out myself, maybe sign up for a small plan. Look, if you want to put the extras (support contracts, bulk discounts, contracting help, etc) behind a sales call, fine. But I need to be able to use your product at a basic level before I would ever do a sales call.