[simonw]

At a small scale, pick the smallest set of boring technologies possible and be strict about using them. Introducing a new technology should only be done if it gives a sizable advantage that can't be had with your existing set. https://boringtechnology.club/

As you get larger (> 50 engineers in my opinion) you may need to switch things up a bit. I really like the "golden path" methodology described by Charity Majors: https://charity.wtf/2018/12/02/software-sprawl-the-golden-pa...

Short version: pick a set of tools that are fully supported by the organization: projects that use them get backups and deployment and testing and ops and development environments all provided by default.

Teams can stray from that golden path, but they'll need to solve that operational stuff themselves.

UPDATE: I just read https://developer.app/expectations/code-neutral/ and I mostly disagree with it: allowing developers to mix and match any langauges and frameworks they feel like is a huge competitive disadvantage and will greatly damage your ability to maintain software and build features productively over time.

The exception is editors and personal development tools - developers should be able to use whatever works best for them there because it has no impact on other developers - my work in unaffected by your decision to use Emacs instead of VS Code.

But don't make your Python programmers on a tiny team have to fix bugs in a Ruby app because some other developer liked Ruby better!