Over the time this strategy proved beneficial. My team ended up having the highest salaries and bonuses in the company along with being given most interesting projects (developing new products from scratch as a rule).
I still went on my own after some time as I could not really tolerate that employer/employee style of interaction.
I'm curious how did you test candidates for this? Did you give them any specific tasks to accomplish and then evaluate their ability to learn?
One example given is that if you're booking a flight for an executive "to New York" you should pick JFK, not because it's the best option, but because it's the most popular.
The reason is that if you pick Newark, say, and it all goes swimmingly, the best you can hope for is a "thanks!" .. whereas if there's a delay or some other problem, the person is likely to blame you for picking "a weird airport" (this story comes from a British perspective – I'm sure Newark is better known amongst Americans.. to reverse the story, it'd be like an American flying into Gatwick instead of Heathrow). If they got delayed at JFK, they're more likely to blame the airline, etc.
I'm thinking of digging into this a bit further as I think some of this explains why certain programming languages, tools, and services grow in popularity while others don't. AWS feels like the JFK of clouds, for instance. There's also the old "no-one gets fired for buying IBM" adage at play.
People pick AWS or JFK not because it's the best option but because it's guaranteed by popularity to not be the worst.
You seem to be mostly concerned with CYA here and in the JFK example.
>People pick AWS or JFK not because it's the best option but because it's guaranteed by popularity to not be the worst.
But this doesn't follow from CYA. It might be the best outcome for you, because your boss doesn't blame you. But it doesn't mean it's overall the best option.
I never had a great experience with IBM tools. They're the first example that comes to mind of software which gets bought because buyers aren't users in big corporations and buyers not having a personal incentive to choose better software.
In a large company with 100.000 employees where everybody loses 1h a week due to bad UX, slow UI and server restarts, you're losing multiple millions of dollars a week to protect your position.
If Newark is on average better than JFK, you're losing your executives time to protect your position.
I'm not saying protecting yourself isn't worthwhile, but it's a bad reason to pick tools from the company's perspective.
Absolutely, and that's the real point. I don't think I disagree with any of your points, but perhaps I am more resigned to the fact that people act how people act. I'm not super experienced in this area (which is why I was enjoying the book in question) but I believe this is all related to the phenomenon of "ambiguity aversion" (https://en.wikipedia.org/wiki/Ambiguity_aversion). I'm interested in how to engineer around (or cheat) these biases rather than present a purely logical argument for one technology (or airport!) over another.
He's in lots of videos, TED talks, etc. if you want to get the cut of his jib for free, e.g. https://www.youtube.com/watch?v=iueVZJVEmEs
Tools get popular for a reason. You get community support and a test-of-time guarantee that whatever you invest in today is more likely to last compared to the niche choice.
Sometimes/often for completely wrong reason. And even if the reason was good in particular context then suddenly the tool gets dragged to be used well beyond the original intent.