I always enjoy books published by the Pragmatic Programmers and Driving Technical Change by Terrence Ryan was no exception. The premise of the book is that people don’t always adopt good ideas simply because they are a good idea instead we need to put some thought into how to sell the idea in order to increase the chance of it being adopted. People need to feel the investment of their time/effort/money is going to reap reward.
The book is split into two sections. The first section helps you identify the types of sceptics who you will need to win over. These include the uninformed, the herd, the cynic, the burned, the timecrunched, the boss and the irrational (who are a lost cause). Some might complain that people don’t fit neatly into boxes but I think that misses the point which is it makes you stop and really think about the people on your team. What is their personality? Do they have a glass half full or empty mentality? What is their experience? Are they a nine to fiver or someone who IT is more than a job? Beyond driving change, the scope of this book, it is a useful exercise to try to understand others views and feelings and be sympathetic to them. I think it helps you find a way to get the most out of people and shows a level of respect for them. Each type of sceptic is examined with an explanation of why they behave this way. I particularly like the way Ryan emphasised for the burned that a change doesn’t have to have gone wrong, a change which brings no benefit also leads to a negative view of change.
Once you’ve identified the types of sceptics you need to persuade the second half of the book shows you the different techniques you can use to build traction for your idea. The techniques are nothing new for a seasoned developer but it is a good reminder and the book goes further showing you which technique will help you most with each type of sceptic. Techniques covered include gaining expertise, delivering your message, demonstrating your technique, creating trust, proposing compromise, getting publicity (externally e.g. open sourcing your code), focusing on synergy (are there other industry specific concerns the tool can help address like security, waste, environmentalism), building a bridge (interim step(s) to adoption) and creating something compelling (sample project).
The book does a good job of making you examine your motives when pushing a technical change to make sure it is for the right reasons and that you’ve looked for and thought about alternate approaches. Don’t just be a fanboy.
The book wraps up with helping you come up with a strategy, identifying who to target first, who to not waste energy on and how to use the converted to gain momentum to get others on board. Finally Ryan covers convincing management by solving their problems. This involves speaking in business terms rather than technical gains e.g. reducing ongoing project costs instead of more maintainable code and giving meaningful figures such as man days saved etc.
I think the book is a good read, reminding you of the need to recognise your team as individuals who will react differently. It makes you aware of the range of tools you have to help get a technical change adopted (which are also beneficial for building your profile) and it hits home the fact that business drives business. The people who hold the power care about making choices that bring business benefit and you need to care too.