3 Book Recommendations For Tech Leads (And Those Aspiring To Be)

Books are the best resource for sharing knowledge in a not-assisted way. They go deep into a topic, or more briefly over a bunch of them. Although, as a Software Engineer, I learned a lot from blog posts, tweets, and conference talks, it was books that prepared me for the Tech Lead role.

For this article, I created a list of 3 classic books I consider essential for whose transitioning — or desires to transition — to a leadership position in technology.

Books can teach us many things. It’s familiar to us to feel like there’re too many things to learn and too little time to absorb it. We tend to get anxious and overloaded with the content easily. Relax.

Take your time on reading, and take your time practicing it. Theory and practice converge at some point, and you realize you’ve been a leader for quite some time.

It’s been quite a while since their publication. So, you may notice some old stories during your reading. However, I think they are classic, and as any other book in this category, they aged very well.

That said, let’s go to the list.

1. Peopleware: Productive Projects and Teams

The book was first published in 1987. The authors, Tom DeMarco and Timothy R. Lister talk about managing people through lots of stories. The stories may sound outdated and unlikely to happen nowadays, but their essence is still valid.

Many things stated by the two authors are kind of obvious, like how expensive the turnover is, that we should include the team in the hiring process and that methodologies are restrictive.

It’s a fantastic opportunity to recapitulate those topics; some were written more than 30 years ago.

Peopleware was the first book that I recall to mention the need for a sociological view, not only a technical one over projects and teams. As such, Tom and Timothy’s theories are still valid.

Among the theories, I how they state the importance of peer view (or Code Review, in our case), and that knowledge workers, like software engineers, are continuously working their soft and hard skills.

The theories go through the traps of software engineering productivity, how office influences how we work, the impact of quality in our work, and much more.

2. Driving technical change: Why People on Your Team Don’t Act on Good Ideas, and How to Convince Them They Should

If you’re new on persuasion and influence, the Driving Technical Change book is an excellent start. It’s full of anecdotes that surface how to gain skeptics buy-in for your ideas. It was published in 2010 and written by Terrence Ryan.

The content works pretty well for an introductory approach on how to expose your ideas, find allies, and, most importantly, check whether your proposals are plausible.

The book also lists some categories of skepticism, which was very valuable to me. I could better understand how the team responded to my inclinations and how I responded to others. This awareness is an excellent start for those wanting to manage large teams.

I confess the book is not very practical, and that may be a disadvantage against it. However, it was very relevant when I read it for the first time, and I strongly suggest you read this short (~200 pages) book even though it won’t answer all your questions or tell you exactly what to do.

3. The Mythical Man-Month: Essays on Software Engineering

If you thought Peopleware was old because it was published in the late 80s, well, my next recommendation is 15 years earlier.

The Mythical Man-Month by Fred Brooks was first published in 1975 (almost 50 years ago!) and covers software engineering and management topics.

The author creates the concept of man-month. It’s the unit for the amount of work of a person in a month. Then, he defends that adding more people to a late project makes it later. It’s known as Brook’s law.

It relates to the latest and hottest discussions in the agile world about “coordination costs”: when you increase the number of people in a group, organizing work gets harder. Thus, it requires more meetings and management efforts to align everybody, which delays the software development even more.

It’s an inspiring book, a classic one, which, in a certain way, is still modern and worth the reading.