[zippergz]

This is all well and good if you build your product from the beginning with the vision that it will some day be sold by sales people to huge companies. But if your expectation is that it will always be self service, a bunch of design and engineering work to make it flexible just looks like wasted effort. If you guess wrong in either direction in your early development you'll have problems. Either get to market more slowly because you spent time up front building for a future that may never come, or get to market quickly and deal with the repercussions later.

[ghaff]

It can be both. AWS and Google in particular (Microsoft was obviously always an enterprise company) started out the individual credit card route and I'd argue a major reason they've been able to grow--AWS better than Google modulo GSuite--is that they recognized they actually needed an enterprise sales force and the things that are associated with it.

[SteveNuts]

Google has been exceedingly difficult to work with from an Enterprise standpoint. We spend millions with them for Google Workspace and I don't even know our account executive's name, nor have we ever talked with them if we even have one. Everything is done through our VAR.

In the meantime I'm well aware of and speak to our Microsoft rep regularly, they know our business and what we need, and have been helping round up resources for upcoming projects and initiatives. It's night and day between MS and Google.

It seems like Google thinks their products are so perfect and infallible that they can cut out the human element entirely. That may work for personal Gmail accounts and such but not so great when you spend millions with them.

[closeparen]

Isn’t it the point of a VAR that the VAR, not the vendor, owns the client relationship?

[SteveNuts]

Yes but we still have relationships directly with our other vendors (Microsoft, AWS, Oracle, Red Hat, Cisco, VMware, the list goes on).

Despite buying all those through a VAR we still have account managers/executives, dedicated systems engineers that we work with directly at the vendor, except Google.

[majormajor]

"Sometimes there will be bugs."

Having human overrides to correct or change data is equally useful for just fixing what you get wrong yourself, as it is for special cases.

[josephg]

This sounds terrifying in its own way, but one of the best decisions I made at a tiny (5 person) startup a few years ago was sitting the smart, non-technical CEO down and teaching him SQL. All our data lived in a Postgres database, and he was amazed by the sort of questions he could ask the database. I showed him some SQL desktop tool (and helped him set it up). And showed him some different sql queries he could run and how to export data into CSV for excel. He instantly understood the “single source of truth” idea and why data modelling was important. He was gleeful about being able to change content on the website without asking someone else to do it for him.

I’m sure he’ll make a mess of something down the line, and I hope someone after my time added audit logs (to track what he inevitably changes and breaks). But there’s something deep and important in empowering other aspects of the business to interact with the computing silo. There’s a time for automation. And there’s a time before that where custom tooling isn’t worth building yet. And just changing records manually is the right approach.