> engineering culture when every team has its own tech stack
Isn't this literally one of the more common arguments for microservice architecture?
It empowers teams to choose the right tool for the job, i.e. run their own tech stack.
The successful micro-service architectures I've seen have a remarkable level of uniformity. Many such environments have standards down to the level of use this particular http lib +internal wrapper.
At the end of the day there are not large enough differences between say ruby and python to justify different teams choosing ruby or python at the same (medium-sized) company. If you have this level of difference, you've effectively permanently engrained conway's law into your organization.
You can immediately spot a misaligned engineering culture when every team has its own tech stack and its own ops as it means that none of the teams trusted each other for anything and had to resort to federation. On the flip side you can se bad engineering cultures where decisions are made based on pure conformity with what was previously built regardless of the problem being solved.
There's a happy middle-ground, a company like etsy with 200-400 engineers can happily afford a small team of 2 engineers trying out scala/mongo for something, it might work out, and nuking it from orbit won't cost that much in the grand scale of things.