People like new things.
When a developer sees a new technology (let’s call it X) on a job description page, or noticed X popping up as a topic on recent Meetups, they may try to convince their managers to use it at work so they can learn it and have experience with it. I mean, who doesn’t want 12 years of Kubernetes experience? (You got to get in early!)
But using new technologies is risky. The community may be young and so you may not get good support when you run into a problem. There are likely many unconsidered use cases in the design, meaning you’ll have to deal with many rough edges. If the technology doesn’t get momentum it may become unmaintained in a few years.
There’s real risk to trying out new technologies, make sure the potential rewards balances out the risks. Question the developer proposing the technology until you get to a concrete reasons for it. Make him/her/they write it down and present to the rest of the company and have the crowd question the idea even more. Ask yourself if you can achieve the same with more established technology. Make sure you have analyzed the pro’s and con’s yourself.
It’s important to nurture developers’ curiosities, But make sure you don’t treat a business-critical project as a playground for developers to satisfy their curiosity. Rather, create a healthy work-life balance so they can try new technologies in their own time, and organize hackathons and 20% Project time so developers can be paid for trying new technologies in a sandboxed environment.
