Driving Technical Change
Last week I read the book Driving Technical Change by Terrence Ryan. This is a small book. I took me only 4 days to read it. Here’s what I thought of it.
The book is divided into four parts. The first part is an introduction, the second part describes the types of skeptics, the third part the techniques and the last part describe strategies to put it all together.
The Introduction
In the introduction the author explain why the book is necessary. There are also two chapters on defining the problem with try to solve and making sure that the solution we try to push is really relevant to the problem we face. This is probably one of the most important part of the book. Programmers love to learn new things and play with new toys. So we have to make sure that we are not trying to push one of those new toy just for the fun of it. If the solution is not appropriate to the problem we face, it could be bad for the project. It can also damage our reputation and get our team to believe the tool is bad because it was use in the wrong project.
The Skeptics
In the second part of the book, the author describes the different types of skeptics we might encounter when trying to get our team to use a new technique. For each type, he gives an example of how they manifest themselves. The examples are little exaggerations, but they are meant to help us recognize the skeptics when facing them. He also says that someone can fit multiple patterns, he can also change type from a project to another one.
The Techniques
This part is the reason why I bought the book. These are the actual techniques to convinced others to accept the new technology. For each techniques, the author explain how to use it and gives examples of the technique applied. He explains why the technique works and on which type of skeptics it is efficient. He also list the pitfalls of using the techniques and how to avoid them. Then he ends the chapter with tips on how to put the technique in practice.
The strategy
This is where the author puts it all together. Because in any team you might encounter many type of skeptics, and the techniques do not work on all types, you need to focus your actions. Here the author describes which skeptics you should try to persuade first. He then explain how you can use them to help you convince the others and get your changes accepted.
My Take On The Book
I really enjoyed this book. The author uses a lot of story telling. The stories are entertaining and they illustrate the point he is making in the chapter. They help visualize the skeptics and the techniques to counter them.
As someone who tried many time to bring innovations at works, and failed most of the time, I believe this book might help me improve. After all, when I fail to convince my teammates and my boss to use something that will help us deliver a better product, I fail at doing my job. As a developer it’s my job to produce the best possible product in a timely manner. And if I know of a new way that will help my team make a better job but I can’t get it adopt, I don’t do a good job.
Knowing the skeptic types will also help me avoid being one of them. I can use this knowledge to see if I oppose an idea for good reasons or if I am just someone else skeptic.