Its a great Q. As the leader of the group you would be the visionary and have outlined your aspiration to have your team on a unified code base. I would suggest you involve the team in a brain storming session(s) to discuss the stacks and what the pros/cons of each base are for each of them and as a collective, continue to probe each individual and then propose your opinion that 'sound like we would be a lot more productive/efficient working on a single code base' and lead that conversation into the one that majority agree on. But this may take a couple of sessions depending on how irritated some individuals get by the idea of 'letting go' of their preferred base. Goodluck.
First I would move all of them to golang (unless you need ML/data science which is python).
Next, I would create microservices using GRPC and define an interface between them, this way they can continue working on each stack (and you can replace it in future date).
I assume that if you choose a unified stack there will be a rewrite which is risky.
It is hard to answer without knowing the individual developers and the company you work at. I work at Amazon and if I were to approach the same problem, I would do something like the following:
1. Understand if the consumers of the API have driven the choice or it is driven from development team. If it is consumer driven choice, you have a longer path ahead. 2. Focus on operational capabilities of the team and hopefully, point out that having three foundational tech stacks make the operations difficult. 3. Understand the skill set of your engineers and are they all comfortable moving from one tech stack to another? 4. All of these migrations are difficult and maybe start by building a facade in a commonly agreed upon tech stack to move the consumers out and then start moving one API at a time?
Use the powers vested in you in a subtle way to nudge people by providing carrots - maybe a positive impact on their career path, better recognition from other teams, cross-org influence etc.
Take your developers into confidence, be ready to explain why you want to move to a single tech stack and how it will help the team improve and be better for the developers and the consumers of the service. All the rest is about execution.