gpollice

Book Review: Driving Technical Change by Terrence Ryan

In Book Reviews, Software Engineering, Uncategorized on December 31, 2012 at 3:43 pm

I’ve been going through several books lately on technical leadership. I’m interested in this for my software engineering course as well as a course on software project management that I’m putting together with a colleague. I was hoping that this book would have some real gems that I could use for material for these courses.

When I started the book, I was pretty excited. The table of contents started out with the right topics, in my opinion—Defining the Problem, Solve the Right Problem. But that was about the extend of the usefulness for my purposes. After this, the author goes into identifying various archetypes that one might encounter in software projects. These are the Uninformed, Herd, Cynic, Burned, Time Crunched, Boss, and Irrational. In order to give his choices credibility he applies the “Pattern” buzzword to them. I think he definitely identifies many of the characteristics that software developers encounter, but they just didn’t form a unified picture for me. It might be the fact that he keeps using adopting version control as one of his main examples. I don’t think this is a major issue today, but I could be wrong.

Ryan then goes into techniques for helping sway the opinions of the types he defined. The descriptions are not overly detailed, nor do they need to be. Scanning through the techniques to get a basic understanding of what they are and how to use them is worth the reader’s time. These will add to your toolbox of soft skills that you can use to be a more effective member of the team. These are not leadership techniques, but ones that any engineer can use to help introduce change to a project team or organization. The ones I found most relevant to my career are Gain Expertise (I just think of this as continuous learning), Demonstrate Your Technique, and Create Something Compelling.

The final section is a set of strategies one can adopt to systematically get changes adopted. After reading the first two sections, this should be almost self-evident to a smart reader.

If I were grading this book, I’d give it a B-. It’s somewhere in the middle of the pack for me as far s books that would help software engineers become leaders and effective team members. I think that even though the book is relatively short (213 pages), it could have been presented just as effectively as a series of a few blog posts—maybe that’s how it started.

The bottom line, from my viewpoint is: if you have some extra money for books on soft skills, it won’t be wasted on this book, but if your budget is more limited, look for a book that has more bang for the buck.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: