This week I’ve just finished reading “Driving Technical Change”, a book about why it’s so difficult to implement techniques or tools in our work environment, and how to have a better impact. It’s a small, 130 pages long book, so it can be read on a quiet weekend.
The book is divided in four parts:
The first part encourages us to solve the right problem, and for that explains how to specify the problem we want to solve, and how to find a solution, not pushing a tool or technique by itself. We must do some research to find if is there any better solution that works better for our team that the one we are promoting.
The second part lists the most common stereotypes, called “sceptics”, those that may (and will) reject our solution, from the uninformed, to the cynic, the irrational, the boss (management) and more. In this section, for every sceptic we can find a list of possible techniques that can help us to fight that rejection.
The third part is about those techniques, things like having a deep knowledge of the tool or technique we are pushing, know the possible flaws and solutions for them, show a working demo on how it can help your team at day 1, or even prepare an intermediate solution as a bridge between the current status and the status we want to be in, can be very useful to convert the rejection into support. It talks about trust, It’s very important to be honest and create trust, above everything don’t lie to your team.
Finally, the fourth and last part is about strategy, how to approach the easiest to convince members of your team, and with their support, jump into the more challenging ones. It states that sometimes after all the work we may not drive that technical change, but we will always put the first blocks for someone that in a future may finnish it.
Personally, I’ve found it very interesting. If you are trying to push a solution internally and you feel lost, this book may be a starting point.