Your co-workers' resistance to new technologies can be baffling. Logical arguments can fail. If you don't do politics, you will fail. With Driving Technical Change, by Terrence Ryan, you'll learn to read users' "patterns of resistance"-and then dismantle their objections. Every developer must master the art of evangelizing. With these techniques and strategies, you'll help your organization adopt your solutions-without selling your soul to organizational politics.
Finding cool languages, tools, or development techniques is easy-new ones are popping up every day. Convincing co-workers to adopt them is the hard part. The problem is political, and in political fights, logic doesn't win for logic's sake. Hard evidence of a superior solution is not enough. But that reality can be tough for programmers to overcome.
In Driving Technical Change: Why People On Your Team Don't Act on Good Ideas, and How to Convince Them They Should, Adobe software evangelist Terrence Ryan breaks down the patterns and types of resistance technologists face in many organizations.
You'll get a rich understanding of what blocks users from accepting your solutions. From that, you'll get techniques for dismantling their objections-without becoming some kind of technocratic Machiavelli.
In Part I, Ryan clearly defines the problem. Then in Part II, he presents "resistance patterns"-there's a pattern for each type of person resisting your technology, from The Uninformed to The Herd, The Cynic, The Burned, The Time Crunched, The Boss, and The Irrational. In Part III, Ryan shares his battle-tested techniques for overcoming users' objections. These build on expertise, communication, compromise, trust, publicity, and similar factors. In Part IV, Ryan reveals strategies that put it all together-the patterns of resistance and the techniques for winning buy-in. This is the art of organizational politics.
In the end, change is a two-way street: In order to get your co-workers to stretch their technical skills, you'll have to stretch your soft skills. This book will help you make that stretch without compromising your resistance to playing politics. You can overcome resistance-however illogical-in a logical way.
Browse our Bookshelf Favorites store for big savings on popular fiction, nonfiction, children's books, and more. |
Book Description
Frequently Bought Together
Editorial Reviews
About the Author
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.
Product Details
Would you like to update product info or give feedback on images? |
More About the Author
Terrence Ryan currently works as a Flash Platform Evangelist for Adobe Systems. 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.
Customer Reviews
Share your thoughts with other customers
Most Helpful Customer Reviews
7 of 7 people found the following review helpful
By Bas Vodde
Format:Paperback|Amazon Verified Purchase
Driving Technical Change is about exactly that. If you have an idea, a new tool or technique then how to you convince others that it is actually a good idea. What are the techniques you could use to convince the 'skeptics'.
This book consist of three parts (ignoring the introduction section in the beginning). The first part defines types of stereotypical resisters. The second part defines techniques to convince them and the third provides a strategy on how to use these techniques.
The first part defines seven types of stereotypical resisters: the uninformed, the herd, the burned, the cynic, the time crunched, the boss and the irrational. The author uses these stereotypes as extremes which he then can explain the techniques with. I personally was very uncomfortable with these seven stereotypes and didn't think of them as useful thinking tools. Grouping people in boxes like this is incredibly counter productive.
The second part defines techniques to use to convince 'skeptics'. Most the the techniques were fairly obvious, such as deliver the message or find synergy. I liked the fact that the author focused a lot on solving the right problem rather than selling what you believe in and that the author focused on gaining expertise first. It makes the techniques less like silver bullet tools that will solve all your problems.
The last part was about strategy. It describes how to first convince people who are ready and not to waste your effort on people who are not ready. I think this is sound advise. However, in the end the author suggested that it was a good idea to convince management to enforce a policy. I regret that there is still such a command & control traditional management aspect in the book. As the author later shares in his own story, advise like this frequently backfires to policies being enforced that aren't useful anymore.
Driving Technical Change is about 130 pages. It is an easy and quick read. The advise is useful, however the stereotypes are IMHO a little dangerous. The only advise I disagreed with was the strong management enforcing comments made in the end. Overall, the book had some good ideas, yet I wouldn't recommend this book when driving technical change. Instead I'd point people to Linda Rising and Mary Lynn Manns change patterns book called Fearless Change: Patterns for Introducing New Ideas. So, the book isn't bad, but it isn't very good either. I'd go for between 2 and 3 stars and decided to go to 3 stars because it is an easy read.
This book consist of three parts (ignoring the introduction section in the beginning). The first part defines types of stereotypical resisters. The second part defines techniques to convince them and the third provides a strategy on how to use these techniques.
The first part defines seven types of stereotypical resisters: the uninformed, the herd, the burned, the cynic, the time crunched, the boss and the irrational. The author uses these stereotypes as extremes which he then can explain the techniques with. I personally was very uncomfortable with these seven stereotypes and didn't think of them as useful thinking tools. Grouping people in boxes like this is incredibly counter productive.
The second part defines techniques to use to convince 'skeptics'. Most the the techniques were fairly obvious, such as deliver the message or find synergy. I liked the fact that the author focused a lot on solving the right problem rather than selling what you believe in and that the author focused on gaining expertise first. It makes the techniques less like silver bullet tools that will solve all your problems.
The last part was about strategy. It describes how to first convince people who are ready and not to waste your effort on people who are not ready. I think this is sound advise. However, in the end the author suggested that it was a good idea to convince management to enforce a policy. I regret that there is still such a command & control traditional management aspect in the book. As the author later shares in his own story, advise like this frequently backfires to policies being enforced that aren't useful anymore.
Driving Technical Change is about 130 pages. It is an easy and quick read. The advise is useful, however the stereotypes are IMHO a little dangerous. The only advise I disagreed with was the strong management enforcing comments made in the end. Overall, the book had some good ideas, yet I wouldn't recommend this book when driving technical change. Instead I'd point people to Linda Rising and Mary Lynn Manns change patterns book called Fearless Change: Patterns for Introducing New Ideas. So, the book isn't bad, but it isn't very good either. I'd go for between 2 and 3 stars and decided to go to 3 stars because it is an easy read.
3 of 3 people found the following review helpful
Format:Paperback
This book employs a conversational tone and very positive attitude to help developers sell their teammates on new technology. Terry defines the common patterns of skeptics and gives a brief description. He is also quick to emphasize that you must treat your skeptic with respect. They're not automatically bad people because they disagree with you. Then Terry launches into the different types of strategies you can use, and which skeptics they work on. Don't be fooled by the book's small size. There is a lot of great advice and it is a fun book to read. You could get through it in a weekend and go into work on Monday ready to counter skeptics with the facts in a polite and positive manner.
2 of 2 people found the following review helpful
By R. Hilton
Format:Paperback
This book is about a problem techies encounter regularly: I want us to use a specific tool or technique at work, and I need to figure out how to get my team to buy-in. As a book on that topic, it succeeds quite well.
First, a disclaimer: I have a lot of experience in this area, as I worked somewhat recently with a team that was resistant to a lot of changes. I, along with a small handful of other members, repeatedly tried to get buy-in on tools and techniques. Occasionally, we were met with success, but more often we were met with failure.
This book made a LOT of sense of what happened at that company. After reading it, I have a much better understanding of why we failed and succeeded when we did, and what we could have done differently.
Driving Technical Change is a patterns book. Rather than design or architecture patterns, it contains people patterns. The author, Terrence Ryan, argues that most people who are resistant to change fall into one of seven patterns of skepticism. Each pattern is different, and must be dealt with in different ways. As with design patterns, a lot of the patterns are just common sense, but because Ryan gives a very specific name to each pattern, it is useful as a shared vocabulary among forward-thinking techies. It's not immediately obvious from the titles of the patterns exactly what they all mean, so it's helpful to read the book; when I looked at just the titles of the chapters I couldn't decide what one particular co-worker was, but after reading the book I completely knew.
The rest of the book is devoted to different strategies, and which ones are effective against which skeptic patterns. This portion of the book is also useful, though occasionally it feels a bit padded due to structure. Again, it's a lot of common sense, but the author words it in a way that makes it really hit home. There are only a few books that I feel really help tech-minded developers grow the soft skills that they really need to thrive in the industry, and I wouldn't hesitate to add Driving Technical Change to that list.
Though a lot of it is common sense, it can be argued that most of the seminal The Pragmatic Programmer is also common sense. Both are worth reading. Driving Technical Change still gave me some moments to think about and some good advice to internalize, and I'd recommend it for someone forward-thinking in the software industry.
Some people might argue that the book's attitude, which effectively categorizes those who resist changes you are trying to implement at work as enemy combatants, is antagonistic. In an ideal world, all technical change would be a group decision, and the entire team would drive things forward together. It would be nice if this were true, but anyone who has worked in the industry for a little while knows that this is a naive viewpoint. The fact is, when you're certain that a particular tool or technique would help your team and your product, there are sometimes people who put barrier after barrier in your way. It's nearly unavoidable to see these people as enemies (or at least, obstacles). This book doesn't pussy-foot around this fact, it acknowledges it and provides strategies for defeating hostile co-workers. If this seems too harsh to you, I'd recommend giving the book a second look two or three years from now when you'll see things more as they are.
First, a disclaimer: I have a lot of experience in this area, as I worked somewhat recently with a team that was resistant to a lot of changes. I, along with a small handful of other members, repeatedly tried to get buy-in on tools and techniques. Occasionally, we were met with success, but more often we were met with failure.
This book made a LOT of sense of what happened at that company. After reading it, I have a much better understanding of why we failed and succeeded when we did, and what we could have done differently.
Driving Technical Change is a patterns book. Rather than design or architecture patterns, it contains people patterns. The author, Terrence Ryan, argues that most people who are resistant to change fall into one of seven patterns of skepticism. Each pattern is different, and must be dealt with in different ways. As with design patterns, a lot of the patterns are just common sense, but because Ryan gives a very specific name to each pattern, it is useful as a shared vocabulary among forward-thinking techies. It's not immediately obvious from the titles of the patterns exactly what they all mean, so it's helpful to read the book; when I looked at just the titles of the chapters I couldn't decide what one particular co-worker was, but after reading the book I completely knew.
The rest of the book is devoted to different strategies, and which ones are effective against which skeptic patterns. This portion of the book is also useful, though occasionally it feels a bit padded due to structure. Again, it's a lot of common sense, but the author words it in a way that makes it really hit home. There are only a few books that I feel really help tech-minded developers grow the soft skills that they really need to thrive in the industry, and I wouldn't hesitate to add Driving Technical Change to that list.
Though a lot of it is common sense, it can be argued that most of the seminal The Pragmatic Programmer is also common sense. Both are worth reading. Driving Technical Change still gave me some moments to think about and some good advice to internalize, and I'd recommend it for someone forward-thinking in the software industry.
Some people might argue that the book's attitude, which effectively categorizes those who resist changes you are trying to implement at work as enemy combatants, is antagonistic. In an ideal world, all technical change would be a group decision, and the entire team would drive things forward together. It would be nice if this were true, but anyone who has worked in the industry for a little while knows that this is a naive viewpoint. The fact is, when you're certain that a particular tool or technique would help your team and your product, there are sometimes people who put barrier after barrier in your way. It's nearly unavoidable to see these people as enemies (or at least, obstacles). This book doesn't pussy-foot around this fact, it acknowledges it and provides strategies for defeating hostile co-workers. If this seems too harsh to you, I'd recommend giving the book a second look two or three years from now when you'll see things more as they are.
Most Recent Customer Reviews
1.0 out of 5 stars
very lightweight and obvious stuff
Th premise of this book is good but the content is not there. There is really about 10 pages of content stretched out to 130 pages into simplistic overlapping examples dealing with... Read more
Published 1 month ago by jt
3.0 out of 5 stars
An okay book if you haven't read similar ones before
I've been going through several books lately on technical leadership. I'm interested in this for my software engineering course as well as a course on software project management... Read more
Published 4 months ago by Gary F. Pollice
1.0 out of 5 stars
A misleading book written by an obnoxious author
So why do you need to "drive"? if the change is so obviously beneficial, there would be need to drive. Read more
Published 10 months ago by Björn
4.0 out of 5 stars
Going on my bookshelf
Terrence Ryan has provided a worthwhile volume for my bookshelf. This was a book that was easy to read and absorb valuable lessons from. Read more
Published 13 months ago by bloggy
5.0 out of 5 stars
I wish I had this book 10 years ago
Having just spent the best part of 10 years trying to get people to adopt new tools, I really wish I had this book a long time ago. Read more
Published 20 months ago by Peter W Smith
4.0 out of 5 stars
Great resource for dealing with skeptics of change
Having problems convincing your team, organization, company, customer, etc. to adopt a new methodology or technology? Like that's never happened to anyone else before... Read more
Published on March 7, 2011 by James Holmes
5.0 out of 5 stars
If you want so technical change to happen, read this book first!
Have you ever tried to convince your co-workers to adopt a new development technique, your boss to buy a new product? Maybe you succeeded/failed or were too afraid of even trying ? Read more
Published on January 10, 2011 by Cyril Hanquez
1.0 out of 5 stars
Master of the obvious
If Terrence treats his co-workers they way he treats his readers he forgot an 8th type of employee, The Office Blow-hard. You can d/l for free on ebooks. Read more
Published on December 7, 2010 by Michael Byrom
5.0 out of 5 stars
A Great Resource for Developers and Managers Alike
Reading this book, you will swear that Terrence has been a part of your team and in your meetings because his descriptions of the various types of team members is often so spot on. Read more
Published on November 23, 2010 by B. Rinaldi
5.0 out of 5 stars
Sage advice on dealing with office politics
Reading through this book, Terrance classifies people into different groups.
For me this was a vivid portrayal, that I could instantly relate to having working with the full... Read more
For me this was a vivid portrayal, that I could instantly relate to having working with the full... Read more
Published on November 19, 2010 by Mr. Jeremy Flowers
What Other Items Do Customers Buy After Viewing This Item?
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
Listmania!
So You'd Like to...
|
|
