Another rule/heuristic that seems to work well, along with Rule 4 from the article, is having a limited number of golden tickets per team. A golden ticket gets used up when you use a "new shiny thing" or "cool but not widepsread" thing.
For us, the risky choice in our stack [1] was Haskell. It's been amazing and has paid off immensely, but the challenges are very real. Over time we've wanted to go whole in on things like ReasonML too, but we haven't pulled the trigger or made safer choices, because that one golden ticket has been used up.
(I can't take credit for coming up with this, but I don't know who did! I'm sure it's already better articulated somewhere.)
I think the usual term is "innovation tokens", from the "choose boring technology" post at https://mcfunley.com/choose-boring-technology. It's definitely very helpful in preventing projects from choosing all the shiny new tech at once while not preventing any all innovation at all. Some of the shiny tech is actually worthwhile, after all.
This is a great way of thinking about technical decision-making. I'm most familiar with this idea through the framing of "innovation tokens" from the essay "Choose Boring Technology" [1].
For us, the risky choice in our stack [1] was Haskell. It's been amazing and has paid off immensely, but the challenges are very real. Over time we've wanted to go whole in on things like ReasonML too, but we haven't pulled the trigger or made safer choices, because that one golden ticket has been used up.
(I can't take credit for coming up with this, but I don't know who did! I'm sure it's already better articulated somewhere.)
[1] https://github.com/hasura/graphql-engine