http://www.amazon.co.uk/Driving-Technical-Change-People-Convince/dp/1934356603
Author: Terrence Ryan
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:
- Reference - useful for a particular technology when actively using it.
- Tutorial/teach - useful for learning about a technology, easy to read even if not currently using it. For
example beginners guides for technologies.
- 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:
- Describing the type of people that typically oppose change. These are:
- 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.
- The burned: don't want change because they have previously been burned by the technology/process in
question.
- 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.
- 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.
- 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.
- 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?