- Taschenbuch: 200 Seiten
- Verlag: The Pragmatic Programmers; Auflage: 1 (3. Dezember 2010)
- Sprache: Englisch
- ISBN-10: 1934356603
- ISBN-13: 978-1934356609
- Größe und/oder Gewicht: 19 x 1,2 x 23,5 cm
- Durchschnittliche Kundenbewertung: Schreiben Sie die erste Bewertung
- Amazon Bestseller-Rang: Nr. 248.221 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should (Englisch) Taschenbuch – 3. Dezember 2010
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
""At its core, Driving Technical Change is a fantastic book about design patterns. In it, Terrence Ryan clearly outlines common, problematic personalities--"skeptics"--and provides proven solutions for bringing about progressive change. It is certainly an unfortunate fact of human behavior that people are oftentimes resistant to implementing best practices; however, using Terry's book as a guide, you will now be able to identify why people push back against change and what you can do to remain successful in the face of adversity.""--Ben Nadel, Chief Software Engineer, Epicenter Consulting
""Politics is one of the most challenging and underestimated subjects in the field of technology. Terrence Ryan has tackled this problem courageously and with a methodical approach. His book can help you understand many types of resistance (both rational and irrational) and make a strategy for getting people on board with your technology vision.""--Bill Karwin, Author of "SQL Antipatterns: Avoiding the Pitfalls of Database Programming"
Über den Autor und weitere Mitwirkende
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.
Die hilfreichsten Kundenrezensionen auf Amazon.com (beta)
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.
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.
Of course the correct way is selling it to your colleagues, but of course there are different types of people to conquer and Terry groups these into the seven groups of skeptics:
* The Uninformed
* The Herd
* The Cynic
* The Burned
* The Time Crunched
* The Boss
* The Irrational
Terry covers each of this with their own chapter and gives you tips on how to spot them. Once they have been introduced, you will, as I did, start to think of people you currently work with or people you have worked with in the past and put them into these groupings.
Terry talks through nine techniques, on how to counter these groups of skeptics. Each technique counters a few of the groups, so you need to decide which technique you will need to use to over come them:
* Gain Expertise
* Deliver Your Message
* Demonstrate Your Technique
* Create Trust
* Propose Compromise
* Get Publicity
* Focus on Synergy
* Build a Bridge
* Create Something Compelling
Each of the techniques has a nice little introduction with tips on how to perform them, and why they work. He also indicates which of the groups of sceptics that the technique counters and any pitfalls you might encounter.
Terry's last section of the book covers some strategies on putting these techniques to use and getting to your end game plan.
All in all, the entire book is a great for anyone who is always looking to improve the process where they work, and always seem to hit a break wall. Reading the book won't make this happen over night but will certainly arm you with some good ideas how to get the ball rolling.
For me this was a vivid portrayal, that I could instantly relate to having working with the full spectrum of such people.
He gives advice on how to handle these groups of people, and basically create allies, converting the masses to your cause, but in such a way as to not come across as blowing your own trumpet.
In essence this boils down to converting the low hanging fruit (colleagues) to your cause and gradually tackling the more challenging ones. Garnering such support you don't appear to be a lone crusader when presenting your case to management and if you heed the advice given on handling situations correctly, you can avoid appearing confrontational.
It also clarifies how to allocate and your time productively building relationships with colleagues and not expending effort on the irrational.
Some of the IT terminology would be alien to people outside this arena, but the psychology lessons could equally be applied to other industries.
A good book, I could have done with reading years ago. As a result I'd probably have a few less battle scars right now! Going forward I'm sure it's something that will help me in my career.
Oh. On a final note, I learnt about Google Alerts. Had never used them before. Cool tip.