Four books every team lead should read

adminguy's picture
Posted September 30th, 2015 by adminguy

                

 

 
 
 

Going from developer to senior developer to team lead is a fairly common career progression. However, interestingly, much of the skills a team lead needs have to be developed through observation, self learning and reading. There aren't too many college or online courses that will teach the skills required to be effective. Maybe it's because being an effective team lead does not require much of a theoretical foundation; it's more about practical skills, common sense, and getting stuff done. 

 
Even though the school of hard knocks is one of the best teacher, a lot of learning can also come from other people's experiences. And well written books which draw from practical, real world situations, are one of the best sources. Last week I wrote about traits which every team lead should have. This week I'd like to recommend four books which every team lead should read.
 
 
It's amazing how a book that was first published in 1975 is still not only popular but also very relevant. Perhaps because even though technology has changed a lot, the nature of problems faced by teams have not. We still face the same type of problems. That's why this book still shines - because it describes problems faced in the trenches by development teams, their causes and possible solutions. The book discusses several issues ranging from communication, system requirements, system freezing, design bloats, and many more; but my favorite thesis which gives the book it's name is - Assigning more programmers to a project running behind schedule, may make it even more late. Common sense isn't it? Yet, you'll be surprised how many managers just don't get it. Understanding the principles outlined in this book will ensure you don't become one of them.
 
I really like this excerpt from a user review on Amazon:
 
There are few must reads in this industry. This is one. First published in 1975, this work is as applicable to software engineering today as it was then. Why? Because building things, including software, has always been as much about people as it has been about materials or technology--and people don't change much in only 25 years.
 
This book too, like the previous one, is based on personal, real world, experiences, and it's an even more people focused book than The Mythical Man Month. The author speaks strongly in favor of removing obstacles that get in the way of performance. It gives advise on how to create an environment that is respectful and not oppressive. The major premise being that people can work very well on their own if they are given the right environment. The book stresses a lot on the office and work space environment among other things that affect the team. It's an important read for anyone connected with software development, but irreplaceable for a team lead or a prospective one. As a reader on Amazon comments:
 
This book offers so many great ideas for managing teams with relevant and practical examples to help drive the point home. As a project manager, I have been responsible for motivating teams for many years. Some days are better than others! But this book has provided a fresh look at how and why people are motivated, how to hire and get the most from your teams, and how to NOT waste their precious time.
 
 
A development schedule which defies all attempts at controlling it is the subject of this wonderful book by Steve McConnell, the author of Code Complete 2, a masterpiece in it's own right. The book discusses topics such as estimation, rapid development languages, working overtime, motivation, teamwork, requirements creep, quality, and much more. It outlines many of it's arguments with real world case studies and offers ample advise on how to tell whether your project is going north or south. 
 
The advice offered in this book is steeped in real world fire fighting, as reviewed by this reader:
As a developer, you have been on that project.  The one that seems that it will never end. Requirements change daily, testing seems to discover new bugs faster than you can fix them, release dates come and go and noone seems to know when the project will be completed. If you're like me, maybe you thought that was just the way software projects were.
And then I read this book. Chapter 3 contains a case study of classic mistakes.  It sounded like every project I had ever worked on. Steve McConnell shows you how to avoid those mistakes, and how to leverage best practices in planning and development to achieve maximum predictability and control over your software schedule.  This should be required reading for all software project managers, technical leads and top management.
 
 
This book by Mickey W. Mantle and Ron Lichty has been received very favorably by the industry. This book, like Peopleware, focuses on managing people and teams. While Peopleware is a classic in it's own right, this book is more contemporary, discussing many issues that are unique to this age. The book stresses on and gives ample examples of how to better manage as well as motivate people and teams. A well managed project according to the authors begins with understanding and motivating the team to perform at their peak. This review says it best:
 
Technology is easy. People are hard. But Mickey Mantle and Ron Lichty's fantastic book can make the people part of your technology operation significantly less hard. Mantle and Lichty understand that it's typically not technology that determines successful projects: it's human beings that make the difference. Instead of focusing on technical solutions, they explore and reveal the human side of technology projects: who your developers are, what makes them tick, what they care about.