> Or you'll be asked to allow team x to use a new widget, instead of the old one. But then team z will want to use a different new widget to do the same thing.

> Or you'll be asked to allow team x to use a new widget, instead of the old one. But then team z will want to use a different new widget to do the same thing. THIS. I'm a senior developer in a large org and this happens constantly. I was in one department who just about every few months was using a new JS framework to build medium sized, dynamic apps. After a year, we had four or five of these apps, all on different frameworks, and a huge technical debt because all of the framework knowledge was tied to a few individuals. It was great to build something the way you want to and test out new frameworks - but in a large org, all it did was create a ton of chaos down the road. Now, the team has been tasked with transitioning the apps to a single framework - no simple feat when you have thousands of daily users and no one wants to give you the budget or time to re-work all of these applications. Like OP said, stick to your guns and learn to say No. You might have to stand by your decision, but you have to really be thinking ahead and what's best for the org. Letting a dev team run wild and do what they want will kill you down the road.