[Driving Technical Change] [By: Ryan, Terrence] [November, 2010]

by Terrence Ryan

Driving Technical Change by Ryan, Terrence [Pragmatic Bookshelf, 2010] (Paper...

Genres: Programming, Management, Technical, Technology, Business, Nonfiction, Leadership

Paperback

First published August 25, 2010

Reviews

[Ash Moran · Rating 1 out of 5]

I really wish I'd read the reviews before buying this. This book reads almost cover to cover as "how to get your favourite new toy into your organisation".

There's a nod here to how to really solve problems (Chapter 3 is called Solve the Right Problem). But in the middle it contains a spectacular contradiction. Chapter 17 (Create Trust) says specifically to never lie by omission. A few pages later in chapter 21 (Create Something Compelling) he describes the following: build a solution to a pain point in your organisation, then attach it to the shiny new toy you want to introduce. The example is a Java tool that was, for no other reason than the developer wanted the team to switch to Eclipse, built as an Eclipse plugin. If anyone can think of a better way to destroy trust in a team using an IDE, please let me know.

There is some mildly interesting content in here, the rest reads pretty much how you'd expect a book written by someone with the job title "evangelist" to read. And the bibliography contains nothing to do with psychology or sociology. Why exactly would I want to follow this up with Pragmatic Version Control with Git?

Ignore this entirely. If you want to learn about selling or giving advice, read Trust-Based Selling and/or Secrets of Consulting instead.

[Coby Randquist · Rating 1 out of 5]

I can see how the book is good, if you're trying to prop up a company with bad management and sucky co-workers. But I'm more of the opinion that if an environment sucks, instead of learning coping mechanisms to make the job more tolerable you should find a place of employment that shares the same values you do.

[Peter · Rating 1 out of 5]

Meh. This book was couched in a "me vs. the world" viewpoint. Technical change should be a collaborative process, not a war to be won as Mr. Ryan framed it. I expected better from the Pragamitic Programers.

If you wand to drive change, read the Heath brothers book, "Switch: How to Change When Change is Hard"

[Nikolay · Rating 2 out of 5]

A quick book.

Two bad things, and one good:

* Bad: the book was about how to drive small or medium technical change. Like how to convince others to use the new toys, not how to truly change perceptions.
* Good: defining the different skeptic patterns (the uninformed, the herd, the cynic, the burned, the time crunched, the boss, the irrational). This is what I kept from the book, and it helped me understand how people think I bit more.
* Bad: the solutions were too general and shallow. It sounded like and objective algorithm, but in my experience it can't be followed without truly knowing how the specific people think. The skeptic patterns gives us some idea, but if our end goal is something more than making our colleagues try git, we need deeper understanding.

If you're complete novice in technical office politics the book is an OK introduction, if you're not, you probably won't learn much.

[Gina · Rating 4 out of 5]

I am not a technical person, but I do work in a technical environment, Dan recommended this book as I was encountering a few difficult characters who very clearly had issues with a tool I maintain. This book was great in helping me identify what type of skeptic group those individuals fell into and how to deal with them in an effective and positive way.

The book also made me think about what my tool could offer and whether it was the right solution to the problem and taking it a step further back, asking myself if I knew what the actual problem was.

I am pleased to say I have been putting what I have read into practice and although I don't understand my Githubs to my SVN, that didn't matter, the principles still apply.

[Patrick · Rating 2 out of 5]

This book was clearly aimed at techies, and was mostly about how to get your favorite tool or framework accepted by your colleagues. By assigning personas and describing patterns that can counter the various personas, it provides solid advice on influencing for people who have no skill or experience at it.

The book was probably good enough for what it was, but I imagine that the target audience to be 24-year-old developers inside slow-moving companies. For anyone who has spent time consulting, this will come off as nicely organized but very basic.

[Todd Charron · Rating 1 out of 5]

Mostly fluff, hardly any real content. I'd recommend Switch over this any day.

[Nate · Rating 2 out of 5]

OK, so it was nothing more than anecdotes and common sense. But still, I thought of some arguments and lines of reasoning that might work while reading it.

[Sergey Shishkin · Rating 1 out of 5]

The book is quite boring and doesn't solve the root cause of difficulty of motivating people to change. The model of skeptics presented is way too simplistic.

[Stig Brautaset · Rating 3 out of 5]

I read this book comfortably in half a day. It contains a patterns catalogue of sceptics, an array of techniques for techniques for dealing with them, and briefly a strategy for how to effectively approach your adoption goal.

Not only have I encountered several of the sceptics in the past; I am, or have been, almost all of them. This was possibly an unintended and slightly uncomfortable realisation, but a valuable one nonetheless. It may help me avoid coming across Irrational in the future.

The book could benefit from referencing research rather than relying so heavily on the author’s own anecdotes. However, this might have been a compromise to make it more accessible.

As a Burned when it comes to ORMs I found the recurring example of Hibernate adoption grating, but I realise that it’s Irrational of me to hold this against the book itself.

Overall I enjoyed the book, and will keep it for reference.

[Anthony Ghavami · Rating 4 out of 5]

This book is really well written and easy to digest; a great example of a book written by an engineer, for an engineer, without getting overly technical.

Don't let the publishing date or dated examples scare you off. The book offers many good lessons to be learned or reminded of, still relevant in 2024. And frankly, I haven't seen another book present this type of information in a better fashion.

I think being a little more experienced made some of the lessons feel less impactful, but I still filled the pages with my pen and highlighter, reflecting on things I could do better.


I do think this book would be especially useful for mid level engineers looking for opportunities to start making a bigger impact on their teams.

[Mike · Rating 1 out of 5]

Read the book until half of it and then skimmed the rest. For me, the problem with this book is that it attempts to present a series of archetypes and a couple of common-sense patterns for attempting to persuade them.

The book felt a tad condescending at times and the regular focus on the irrational archetype and how untenable these people are did not sit well with me.

All in all, the premise of the book sounded quite well; but in the end, I did not feel I gained anything from it. I hope others fare better.

[Nathan Albright · Rating 5 out of 5]

As someone who has a personal and professional interest in managing technological change, and being involved in it a fair amount of time myself [1], I found this book to be an immensely practical and pragmatic one. The intended audience for a book like this is a fairly large one, albeit not the kind that is to be expected to read many books relating to marketing or practical psychology, namely that of a technically proficient person who is wishing to solve some sort of organizational technological problem and who is running into intense resistance to technology change. The discussion includes the need to be self-aware, and also the need to triage accurately what sort of people one is dealing with, and the nature of the objections that people have to change, so that they can be most effectively dealt with. The goal is, after all, not merely the success of a particular change initiative but also the effective collaboration of one's efforts with others and the maintenance of long-term ties that allow for long-term success in one's professional life. It should go without saying that the problems discussed here are not only problems with regards to technical change but are more widely applicable, and are not only applicable to businesses but to other institutions.


As a short book, under 150 pages including its index and supplementary material, this book does not have much of anything in the way of filler. It is a book that is focused on practical aims and getting the most out of the attention span of its readers by getting straight to business and keeping on track. The first part consists of a somewhat lengthy introduction (considering the size of the book) which looks at how this book is organized, and who the intended audience of the book is, defining the problem of resistance to the change we seek, and why change needs to be sold, and what is the right problem that needs to be solved in managing technology changed. The second of the part provides patterns of skeptics that someone who is seeking change has to deal with: the uninformed, the herd, the cynic, the burned, the time-crunched, the boss, and the irrational, what are the underlying causes of their skepticism, how they can be countered, and what is the likely prognosis of one's success in dealing with them. The third part of the book looks at the techniques one has for dealing successfully with skepticism, some of which depend only on ourselves and some of which depend on having a favorable situation that can be exploited for change: gaining expertise, delivering your message, demonstrating your technique, proposing compromise, creating trust, getting publicity, focusing on synergy, building a bridge, and creating something compelling. The fourth and final section of the book focuses on a grand strategy of technological change that is simple but not easy: ignore the irrational, target the willing, harness the converted, and sway management in one's favor, before the author gives some final thoughts and cautionary tales about how past successes can lead to future difficulties when success is siloed or when a solution is so popular that the reasons for its adoption are forgotten and it becomes a new problem in the future.


In reading a book like this, one must see not only an opportunity to manage the resistance that other people have towards change, but also to examine oneself as to one's own resistance to change and where it lies. Looking at myself, I would not see myself as a person who is irrationally opposed to change, but at times I have had moderately cynical tendencies, at times I have been burned or uninformed, and quite often I have been part of the herd or time-crunched, either generally in favor of a change but lacking the confidence or interest in pushing it, or being so overwhelmed with the matter of coping with normal tasks that I have lacked the time to give certain aspects of change a fair hearing. No doubt my issues in this regard are not uncommon, and therefore I highly recommend this book not only as a way of how to handle the change efforts that one wishes to lead but also to examine oneself into how we as readers are often barriers to potentially beneficial changes in our own worlds. For we are all creatures of habit, and this is certainly true of me and also certainly true of many other people as well. Recognizing it and dealing with it is part of what makes one a force for good in the world and in one's organizations and institutions, seeing as where we are is seldom if ever where we should be.


[1] See, for example:


https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

https://edgeinducedcohesion.wordpress...

[Javier · Rating 3 out of 5]

I have found the book to be slightly superficial and shallow. While I do find interesting how the author explains the different type of folks you can encounter, he focused the book too much in overexplaining how to ""defeat"" them. Moreover, topics which have a lot of potential to talk about, like "building trust", he just touches the surface by reducing it to "not lying". IMO, not worth the while.

[Panagiotis Atmatzidis · Rating 4 out of 5]

This book is a lot better than I expected. There are no deep, hidden advices but the structure is simple and clear. The repetition is kept to a minimum and I found the advice solid.

If you care about "driving technical change" from bottom-up, this book can help you put things into the right perspective and act on a plan instead pushing a project on all direction as "best as you can", which often is not "good enough".

The book is thin and a very easy read, which I liked!

[Adam C · Rating 2 out of 5]

like most business books, it could be said in far fewer words and your notes for the whole book could fit on a few index cards. still worth skimming! i did find a few nuggets i could leverage immediately, so it was worth it to read. but i will have to keep it as a reference for particular situations. its not a book you read once and you've mastered it. you have to keep coming back to it when you need to convince different kinds of folks.

[Juraci Vieira · Rating 5 out of 5]

Amazing book, I was surprised by the fact that the book helps to understand better if the technical changes you want to propose are feasible and really necessary more than trying to convince other people to follow your ideas. Has practical steps that helps you to achieve a good level of confidence on your ideas if they are really an improvement on the current technical ecosystem.

[James · Rating 3 out of 5]

Some good techniques for overcoming skeptics in an organization, but based a little too much on what appears to be limited experience - really, just retellings of a few anecdotes from different perspectives. Valuable for engineers who are looking for introductory steps on the path to better collaboration, but not an expert-level handbook.

[Leonardo Giorcelli · Rating 4 out of 5]

Interesante conjunto de herramientas para diagnóstico y estrategias de aplicación para llevar adelante cualquier tipo de cambio tecnológico dentro de empresas.

[Rod Hilton · Rating 3 out of 5]

A lot of reviews criticize this book for being primarily a long essay about how to convince your coworkers to use a technology you'd like to introduce. I'm not entirely sure what these people are complaining about, that's exactly how the book bills itself. Indeed, 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 relatively 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, despite appearances, 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.

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 less useful, as it contains mostly common sense advice that is generously padded out via book structure. Because of all the padding, the book is easily 30 pages longer than it needs to be. The advice is useful, and I'd recommend reading through it, but a lot of it is stuff most people in the industry already know.

The most annoying thing about the book is the repetition of anecdotes. The author constantly repurposes anecdotes from his employment, rewording and altering details in order to turn one story into two, two into three, and so on. In particular, he seems extremely proud of his accomplishments. At some point, he created a system that inspected database tables and generated entire CRUD applications based on them (he refers to this occasionally as code generation, which it is not, as "generated code" should never be hand-edited). He mentions a few other accomplishments over and over again, which makes the book better overall, but the extremely limited variability in these stories makes the author seem like he hasn't accomplished much in his career, which tarnishes the book a bit.

Overall, the book is about 2 or 3 blog posts worth of material stretched into a book, but while that makes the book somewhat a disappointment, it doesn't make it useless. Though a lot of it is common sense, it can be argued that most of the seminal The Pragmatic Programmer is also common sense. It's still good to read through. 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.

[Mark Sutherland · Rating 2 out of 5]

This book outlines a rather adversarial approach to promoting technologies and solutions in a technical workplace. It follows a 'design patterns' format split into three sections: the first outlines various stereotypes that might be encountered (e.g. cynics, the uninformed), the second looks at tactics for advancing your agenda (e.g. doing demos, gaining expertise), and the final outlines a strategy which ties these altogether.

While there are some useful insights, and some value to the patterns that have been identified, there's a complete lack of depth and nothing close to qualitative data. The material is so light that it's a worryingly quick read which is frustrating as their are the seeds of a more useful piece of work scattered throughout the text.

One of the biggest issues with the book is that it makes the assumption that you are right about the solution to your perceived problem. While there is a chapter that encourages the reader to be diligent in their research and to avoid zealotry, the framing of the book is that you are right, and everyone who doesn't immediately agree needs to be dealt with (with the alarming exception of those that are deemed 'irrational' who should simply be ignored). As a result the focus of the book is on tactics for persuading people to take your approach, where the reasons for their opposition are generally dismissed. Occasionally the authors makes allusion to the notion that they may have something valid to contribute, but it is always an afterthought.

This may seem like an odd complaint, that the book focuses too much on helping you achieve the end you have in mind as this seems to main goal of the book. However I can't help but think this book plays too neatly into the myth of the long genius super developer who is just misunderstood and needs to save the dullards who only work the hours they are contracted for from themselves. This is explicitly referred to in at least one place, and there seems to be an assumption that the reader must fit into this mold. As a result, it would seem more prudent to encourage the reader to take a more collaborative approach, listening to their colleagues concerns and critiques and synthesizing the best solution for all. There are concessions in this direction throughout the book, but they always feel like exceptions from the core message of the book.

As a result, this book probably works best as a modern day Machiavelli for the tech industry, with all of the inherent problems that brings. Ultimately it's not the book I hoped it would be, but the one I feared it would. I fear many will read this and find a system that will help them bulldoze their way to the solution that appeals most to their whims. Perhaps it's best read in order to recognize what others may be trying to do.

[Ronald · Rating 3 out of 5]

Ever come across a shiny new technique or tool but couldn't get it adopted by your organization? I know I have. This book contains some ideas on how you might get people to give your idea a try. The information contained in the book isn't likely to be used daily like some other books but when you really want to try something new and have run into a road block, the book has some interesting ideas. The essence of the book is to try and identify the different archetypes of skeptics and use specific approaches to persuade them to your way of thinking. Some archetypes include The Burned and The Ignorant. Be warned, however, the techniques described aren't going to work overnight and you will have to apply them over time. He doesn't spend much time on it but it is assumed you have done a bit of thinking to ensure that the shiny new tool makes sense for the business. As I said before, you aren't likely to use this book daily but when you really want to install a new tool or technique, this book has some good ideas to try.

[Stefan Kanev · Rating 4 out of 5]

This book has generally bad reviews and I can't understand why.

It's about convincing people to adapt a new technology or practice. I have some experience playing the evangelist, so most of the stuff is known (or common sense) to me, but it was still very useful to read the book. It describes a "few" type of skeptics and the reasons behind them (like the Burned, who have a negative experience with the technology/practice and the Time Crunched, who reject stuff because there is not time to implement it). Afterwards, it describes a number of different strategies you can employ to sell your idea and how they work on the different kinds of skeptics.

An important takeaway for me was "Ignore the Irrational". "The Irrational" is a type of skeptic, but you'll have to read the book to figure out what they're about ;)

Ultimately, it won't solve the problem within your organization, but it will give you a good starting point.

[Tom Panning · Rating 3 out of 5]

If you're new to introducing technical change, reading this book and paying particular attention to the techniques will help you present your idea to you're group. Those new to this aspect of technical teamwork should pay less attention to the description of the types of skeptics; there's too much risk that you'll start treating people as adversaries instead of not-yet-convinced.
If you've more experienced at technical change, this book may have some techniques you hadn't thought of. Additionally, the description of the skeptic types may help if you have someone who is particularly resistant but you can't figure out why.
That being said, the book has a little more of an adversarial bent than I would prefer. And while it does talk about making sure your desired change is a good fit, I would've preferred a little more of that in the discussion of the techniques.

[Eduard Sizov · Rating 1 out of 5]

I'd like to thank the author for the book and the efforts he put into writing. Unfortunately, content-wise the book oversimplifies the problem. Driving any kind of organisational change is a complex problem, so "cookbooks" and "patterns" do not really work well. Sometimes they even make the problem worse. The best parts of this book, t.i. personalities are described in Sandro Mancuso's The Software Craftsman, which I highly recommend. If you want to learn how to drive change, try Lean Change Management by Jason Little.

[Steve Whiting · Rating 4 out of 5]

Bought sight-unseen this wasn't quite what I was expecting, as it wasn't from the manager's perspective. What it actually provides is a book explaining to Techies how to "sell" techie changes to other Techies (and managers), and how to overcome resistance to the great stuff that you want to adopt - and it does a pretty good job of that, showing the notoriously marketing-averse audience how to market their ideas without sullying their hands too much with marketing.

[Edmond · Rating 2 out of 5]

If you are new to IT or just newly promoted to a semi-IT management position... this book is for you if you are looking for a few tips. But if you have been doing this for a while - to recommend new tools and methods to peers and the management, I don't think this book will offer you much that you don't already know.

[Adolfo · Rating 2 out of 5]

I have to admit that I liked this book. Yes, it is short both on size and content, and it won't offer you any deep insight into why people resist new technology, but it is entertaining and has some useful tips.

The biggest con for me is the price; it's a bit expensive for the quantity and depth of the material.

[Doug Henderson · Rating 2 out of 5]

Parts of this book are useful - the (broad) descriptions of stereotypes and the (optimistic) formulae for winning them over, but on the whole I thought this book was a 1.5 star effort.

A sub-title for this book might be "How to get your own way" as it reads more as a guide to getting your own ideas adopted, with descriptions of the political games you need to play in order to do so.

[Andrei · Rating 3 out of 5]

A useful book for those tech experts wanting to 'drive a technical change' through their organization, but limited to small groups, hence the 3 stars.
I liked the easy, 'non-technical' approach, the types and methods. Also a handful of remarkable quotes and some simple psychological facts on typologies. It debatable whether the types described cover all cases in real life, but anyhow a good read.