Book Review: Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should

http://www.amazon.co.uk/Driving-Technical-Change-People-Convince/dp/1934356603

Author: Terrence Ryan

http://terrenceryan.com/about/

Before reading a technical book I tend to look at what the author is about. Terrence works for Adobe, has an active github account where it looks like he works primarily with front end technologies: CSS, JavaScript.

Review

I categorise books as follows:

1. Reference - useful for a particular technology when actively using it.
2. Tutorial/teach - useful for learning about a technology, easy to read even if not currently using it. For example beginners guides for technologies. 
3. General technical books - describing methodologies, practices and general feel good technical books. Books like Clean Code by Uncle Bob fall into this category.

Driving technical change definitely falls into category number three. I read it while commuting and got through it in a couple of hours. It is split into the following sections:

1. Describing the type of people that typically oppose change. These are: 
1. The unaware: don't want the change because they are ignorant of the new technology/process. These people are easy to get on your side if you help them.
2. The burned: don't want change because they have previously been burned by the technology/process in question.
3. The cynic: prefer to look clever by rejecting change. These people tend to have a superficial knowledge that if you are well prepared you can get them on your side.
4. The irrational: people who don't want change for an irrational reason e.g they have a personal problem with you. Best to avoid trying to convince these people.
2. Techniques for driving technical change. This section gives various techniques and indicates which type of person they are effective against. I found this section of the book eventually become quite repetitive. 
3. Finally strategies, how to use the techniques and in which order to actual drive the technical change you want.

Overall I think this book is worth a read as it is very quick to get through and can make you think about whether your colleagues fit into any of the stereotypes. Or perhaps more importantly do you yourself fall into one of them when other people are trying to drive change?

After reading the book it made me realise that if I think a team needs to adopt a new technology or process then it is up to me to put in the work to prove why. Too often people in the work place are trying to introduce new technologies without being able to answer the simple question: What problem is it solving? Or how is it going to improve the software we're producing?