> For example, one pitch in particular was for a product which promised to remove the need for me to write SQL in exchange for being able to set up all my dependencies from a drag-and-drop editor, with the sales pitch consisting of "You can get rid of thousands of lines of all that SQL you hate!" - no I can't, fucko, because your application is still connecting to Postgres so it's just writing the SQL for me with another layer of licensed abstraction on top of it. Why would I pay to have more abstractions designed for you to sell software to multiple clients, you blue-suited dementor? Eight times out of ten, I want to pay you to remove them from my codebase.
See, the problem is that you can't fully remove the original SQL. It's still there, in the code. The database is still there. So instead of having one interface to access the database - SQL - now you have two, the low-level SQL and this bastardized abstraction. Some of your employees will write SQL, and some other of your employees will use the abstraction. They use different tools, so the tools will fall out of sync, and the employees will fall out of sync, and you'll get discord.
Pick one tool. As far as it's technically feasible, pick one database, one programming language, one UI framework, one wiki vendor, one CRM, one ops visualization framework that is right for the business. Don't pick up some fad-of-the-day, and don't let your "artisan" engineers do "research" projects to see whether some other framework might suit their needs "better". Tell your engineers, here's the business problem, here's the pre-existing stack, solve the problem with the already-existing and already-supported tools. If the engineers are truly artisans - guess what, an artisan doesn't blame his tools. Pick new tools only slowly, deliberately, when you have no other choice, and only with a solid plan for standardizing the tool for full adoption across the enterprise.
Why? Because high-performing organizations ensure that they are always building upon prior work. Five engineers with five years' experience with React will be a stronger team - more productive, faster, more accurate at forecasting, have an easier time reviewing and supporting each others' code - than will John with 5 years React experience, Sally with 5 years Vue experience, Wang with 5 years Svelte experience, Cynthia with 5 years Angular experience, and Ilya with 5 years jQuery experience. If Ilya gets hit by a bus? The other engineers will have difficulty picking up the load. Not much of that React, Vue, Svelte, Angular experience will help with supporting the jQuery parts of the codebase.
Commodification requires a standard. We appreciate the value of standards when we succeed at establishing them - tabs vs. spaces, Docker containers, infrastructure providers, project management tooling - because they eliminate discussions that do not revolve around the more fundamental question of how to deliver value to users. Shouldn't you ask yourself, if you're evaluating a new language, tool, or framework, whether you really benefit from breaking the company standard?