Technical Leader Reading List

Over the years I have read countless management and technical books and of those books there are a select few that had a profound impact on how I view the world and my capabilities as a leader. I have put together this list of books to share so that others can benefit from their knowledge and so I can remind myself of some books I should periodically read.

If you are a technical leader or hope to become a technical leader you will benefit greatly from reading each of these books.

Managing Humans

Being a technical leader is especially challenging. Everyone you provide leadership to is extremely intelligent, analytical and they all work with their intellects. Directives are universally destructive with this cohort and will likely cause you to miss your objectives. On the other hand to be a technical leader you need to be good with computers where directives are the key to success. This is the basis of the book Managing Humans.

Michael Lopp provides real world stories of experiences and mistakes he has encountered as a Software Engineering Manager. He also provides detailed instructions on how to facilitate an effective 1:1, how to run a meeting and even how to handle a reorg.

This was the first and only book I have found with practical, specific and effective advice on being an effective manager/leader in my profession.

This should be required reading for anyone who manages Software Engineers or aspires to manage them.

The Mythical Man Month

The Mythical Man-Month is refereed to as the "Bible of Software Engineering" and provides insights on estimating, managing software projects and is the source of a number of the 'Laws' of software development.

While some of the technical details are a bit dated, it is easy to see where some of the concepts commonly reference today come from this book.

Examples of common references:

• Brook's Law; Adding additional resource to a project that is already late will make it later.

• Conway's Law; Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

• No Silver Bullet; "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."

• Second-system effect; "...when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it."

The Goal

I remember 'The Goal' being referenced in my business classes, but it didn't really resonate with me. The concepts of Theory of Constraint, abolishing local efficiencies and the evils of cost accounting did not seem to align with everything else I was being taught.

The fun part of The Goal is that it is written in the format of a novel, so it is an easy read that holds the reader's interest.

After reading The Phoenix Project, I sought this book out and finally read it. It was a pivotal moment for me and I have gone on to read most of the books Eli Goldratt published. The concept of drum-buffer-rope and the idea that making sure all resources were 100% utilized at all times is potentially destructive to the overall goal (make money) was an eye opener.

I list this book before The Phoenix Project because I believe it is more important, but if you are in IT or software development you might want to read The Phoenix Project first as it is based on the concepts in The Goal and will more easily hold your interest.

The Phoenix Project

The Phoenix Project is modeled after The Goal and held my interest like no other business book. It reintroduced the concept of Theory Of Constraint to me and helped me understand the concepts behind the DevOps movement.

At the time I read The Phoenix Project I was trying to understand how to leverage Kanban boards with the team I was managing. I understood how Kanban Boards were utilized in manufacturing, but did not understand how they could be leveraged for software development.

Enterprise Integration Patterns

This is another classic book for software engineering. It is often a source of inspiration for me when dealing with an integration challenge.

If you are a software architect or aspire to be one, I highly recommend you acquire this book for reference.

Working Effectively with Legacy Code

Every company I have ever worked for has at least some challenging code that was written long long ago, by a developer that is long gone or has ascended into a leadership role. This book provides inspiration and effective patterns for refactoring and modifying legacy code.

Everyone who is a software engineer should have access to this book for reference.

Becoming a Technical Leader

Gerald Weinberg was a prolific writer and published over 100 books, based on his account. When I started down the path of consulting years ago, my mentor at the time suggested that I read Weinberg's book The Secrets of Consulting.

Becoming a Technical Leader is a book that will challenge you to step out of your comfort zone. I will be honest and say that I have not made it all the way through this short but power packed book yet.

The two things I have taken away from this book are that learning and applying a new skill will mean your overall success will temporarily dip and that being a leader does not mean you have to be an outgoing person to be successful.