- 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. 94.605 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.
Wenn Sie dieses Produkt verkaufen, möchten Sie über Seller Support Updates vorschlagen?
""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
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.