There are many books out there on effecting change in an organization. But what if effecting change is not the most effective strategy?
A Story
Imagine for a moment that you have recently heard about a new recursive development technique called "DDD Driven Development." The proponents of DDD (a recursive acronym) claim that it speeds up your development cycles by increasing feedback, but only anecdotal data exists so far. Some groups have claimed it led to higher system reliability and development speed, others the opposite.
As team lead, you pick up the premier DDD book and read through it. The arguments, while not airtight, seem to indicate that at least some aspects of the approach would be useful in your organization.
You play around with the techniques in a personal project, and then pitch using DDD on a pilot project. The project goes mostly smoothly, and most of the team members agree that it was useful. A couple dissent, and you can see that it might be difficult to get buy-in from other engineers in the organization who are not as open to change.