Author: Terrence Ryan
Publisher: The Pragmatic Programmers (www.pragprog.com)
Published: November 2010
ISBN 10: 1-934356-60-3
ISBN 13: 978-1-934356-60-9
Formats:
•    Paper Book, soft cover, 200 pages
•    EBook: epub (for iPhone, iPad, Sony, etc.); mobi (for Kindle, etc.); PDF
Prices:
•    eBook ($21.00)
•    Paper Book ($32.95)
•    eBook + Paper Book ($41.35)

Overcoming Resistance to Good Technical Ideas

Devising clever, even innovative solutions, to technical problems, doesn’t always guarantee that those solutions will be adopted or implemented by the company or the organization you work for. Unfortunately, regardless of how brilliant you may regard yourself to be, there is another factor you also need to take into account, and that is the ability to “sell your technical solutions” to your boss and/or colleagues. Because none of us work in total isolation – even the most dedicated backroom IT professionals have to interact with fellow professionals at some point or other – it is essential to learn how to influence others from a technological perspective. That’s why I strongly recommend that you read the book “Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should.”

Terrence Ryan, the book’s author, believes that reading his book will “enable you to convince co-workers to adopt new tools and techniques.” He stresses that “you should be able to do this without having to become some sort of cutthroat office politician. This doesn’t mean that you won’t need to use politics, just that you don’t have to use them evilly.”

Even though this book is published by a publisher called “The Pragmatic Programmers”, don’t immediately jump to the conclusion that the book has been designed specifically to be read only by programmers and developers. In fact, all sorts of IT professionals can benefit from its advice including server administrators, designers, database engineers, IT and business consultants, and hardware engineers. Different levels of management are also advised to read it as well, but especially project managers as their daily work involves significant amounts of contact time with technical staff.

Having said that, it is equally important to acknowledge how the content of the book has been strongly flavored by the background and experiences of Ryan, the book’s author. As he states in the opening chapter, “my anecdotes and scenarios are going to be about developer topics. Sorry, that’s who I am. However, it doesn’t matter what language or tool set you are using. This is going to apply evenly, whether you are a .NET or a Java programmer, an open source fan, or someone in love with some company. This is for anyone who has tried to get co-workers to change the way they work, regardless of how you wanted them to work.” As reported in a short bio on his publisher's Web site, Terrence Ryan “currently works as an Evangelist for Adobe Systems. He focuses on the promotion of ColdFusion, Flash, Flex and AIR. As an evangelist his job is to encourage people to try new tools and techniques. Before that, he spent ten years in higher education overseeing the work of a team of developers, running code reviews, pushing standards, and trying to convince co-workers to come around to new tools and techniques.”

The content of “Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should” has been divided into four sections, with the second and third sections being the major ones. The opening section is introductory in nature, setting the scene for the rest of the book by defining the problem to be solved, namely, “selling professional development to skeptics.” Ryan defines professional development as including “any tool or technique that makes you more productive as a developer, your work less vulnerable to failure, or your code more understandable to your teammates.” In regard to skeptics, Ryan describes them as being “by and large your co-workers who are not using the tool or technique that you want them to adopt. Some don’t know about it. Some don’t care to know about it. Some know about it and just refuse.”

The second section of the book, titled “Skeptic Patterns”, consists of individual chapters devoted respectively to each of the following types of skeptic:
• The Uninformed: individuals who are blissfully ignorant of the current situation. Ryan reports that the uninformed don’t use technology for a variety of reasons: “usually, it’s because they don’t know about it. Some haven’t run across it yet; some may have encountered it but didn’t understand the problem it was solving. More importantly, they didn’t realize that they had the problem that the technique solves. Whatever the reason, they need but know not that they need.”
• The Herd: those individuals who follow blindly instead of taking charge and leading. Ryan categorizes these types of individuals into two sub-groups: 1) “those who don’t know they can lead”; and 2) “those who have other priorities.”
• The Cynic: Ryan suggests that are a number of reasons why individuals become cynical: “some people simply like to argue. Others like to prove that they are smarter than someone else. Others have worked in industry for a while and have been repeatedly disappointed and therefore never see the upside of anything. But there is one really important reason that you will encounter this: in our industry, this behavior is rewarded.”
• The Burned: Ryan points out that understanding this type of individual is “pretty straightforward. The cause of this behavior is that they have used the tool you are pushing before, and it didn’t work for them. The problems they encountered can run the gamut. They could have used the technology and seen no significant advantage. It’s also possible they tried it and had a spectacular failure. They might have installed it but had no idea how to get it to do anything.”
• The Time Crunched: no doubt, all of us can identify to some extent with this type of skeptic. The challenge here is to show the “time crunched” individuals how they can save time if they adopt your technology, or alternatively, invest in procedures that change the way they normally carry out tasks.
• The Boss: sometimes the hardest skeptic to overcome is the boss because of the power they have over you. But rather surprisingly, Ryan’s research has revealed that “the single biggest reason that management resists professional development techniques is because management doesn’t understand them. That might sound harsh, but it isn’t. It’s not their bailiwick. Even if they were promoted from the ranks of developer, if they aren’t doing development anymore, they may wonder why you need this thing that they never needed to do their job.”
• The Irrational: Ryan asserts that this last type of skeptic is the hardest to overcome, simply because you cannot engage them in a reasonable and logical discussion. They refuse to use your product, technique, or procedure, and offer no rational premise as to why! Because you’ll never convince the irrational, Ryan recommends not spending “a lot of time on them. It just leads to wasted effort.”

Now that you know about the different types of skeptics you are likely to encounter, it is an appropriate time to turn to the third section of the book where techniques for overcoming skeptics are discussed in depth. These techniques cover everything from becoming an expert or proposing compromise through to focusing on synergy or creating something compelling. In total, there are nine different techniques, with a separate chapter for each of them. These chapters are structured in the same manner, with each of them containing the following common topics:
• an investigation into why the technique being discussed actually works;
• a list of the different sorts of skeptics that are successfully countered by the technique in question;
• the various pitfalls to watch out for when trying to implement a technique.

For example, in the chapter about “creating trust” as a technique, Ryan says that this works because “people do not like to be manipulated. Tougher than that is that people don’t want to even feel like they’re being manipulated. This is why the used-car salesman has such a bad common stereotype in our culture. They’re seen as deceptive and manipulative (even when they often aren’t).” The sorts of skeptics thwarted by the “creating trust” technique include “the burned”, “the cynic”, and “the irrational.” In terms of the downsides to this technique, Ryan believes that “telling the truth has few pitfalls.” However, he warns his readers that “there is one big one: in your effort to be seen as trustworthy, you point out and emphasize the flaws in your solution. You want to acknowledge that your tools have flaws, downsides, or compromises, but advertising them is another matter altogether.” Ryan suggests that a practical solution to this dilemma is to “acknowledge the weakness, and spell out why you don’t think that the weakness outweighs all your solution’s strengths.”

Unfortunately, knowing about the different types of skeptics, as well as the techniques you can deploy against them, is not enough. You also need an overall strategy. And that is what Ryan provides in the fourth, and final, section of his book. He summarizes his strategy as follows: “basically do your best to ignore those who are downright antagonistic, not wasting any effort on them. Then you apply your tactics to the most willing people you have access to. Then you motivate your converts to participate in a tactic or two. They become advocates, and you continue to the next most easy group and repeat. You do this until you convert everyone you can.”

Sounds a simple enough strategy. But not an easy one to implement! So I suggest you read this particular book in its entirety to give yourself the best possible chance of getting your ideas, techniques, solutions or procedures accepted by the people that you are trying to influence.

To ascertain for yourself whether you could benefit from reading this book, a selection of extracts from it are available on the site of the book’s publisher, The Pragmatic Programmers, at http://pragprog.com/book/trevan/driving-technical-change.