In most professional organizations, decisions are made by compromise, rather than by explicit directive. 

As information security professionals, this is a frustrating reality in which we must function. Only when we are able to convince a large (and relevant) enough group of stakeholders, our recommendations will have a change of being implemented successfully.

The ability to influence those stakeholders, and to get a large part of our agenda realized, is the realm of information security leadership (as opposed to security management). While there are many different definitions of  leadership, most revolve around the notion that leadership is about providing direction and guidance in a way that is consistent with the leader's goals.

From that, it follows that in order for information security leaders to be successful, we need to be able to lead our technical staff and direct them to do what we feel is the best for the organization we work for, but it also means that we need to lead our non-technical organizational counterparts on a path that involves decisions that we believe are the right ones.

In order to achieve convincing those non-technical entities, I believe that a good security leader should have an excellent rapport with key constituents. That is a skill in itself; it requires an understanding of the environment in which we function (so that we can identify those key players), but it also means understanding their motivators. Some tricks that come in handy are: doing favors for others without asking for something in return, be polite and understanding, actively listen to their concerns and respect them, and to never say no. 

Especially the last one is something that we are generally poor at. Unfortunately, the information security professional is too often known as the person who always says no. In reality, there is really no reason for saying no very often, while the effect is still that objections are addressed. 

A simple choice of words is often a make-or-break factor. For example, rather than attempting to implement a policy to block specific "stuff", we can phrase it in such a way that "stuff" is only allowed under certain circumstances. It may seem like a subtle difference, but in the mind of a reader, that is much more acceptable that simply saying no.

So, next time somebody decides to implement your in-house app in a popular (often buggy) toolkit, don't say just no, but say "Okay, but let's see how we can make this happen the best". You should not make your requirements impossible to meet, but there is nothing wrong with asking some tough questions. Next, schedule a lunch meeting with somebody who matters, and try to figure out why they came to asking for this toolkit in the first place. You'll be pleasantly surprised how often the problem simply disappears after a good lunch.