These books help with the “lead” part: they help with things ranging from organizing better meetings to getting buy-in for a significant change. I assume most technical leads are already technically competent, so only one of these books could be called “technical”.
This is not the first list of books to be published on the topic. There are many others like it, but this one is mine. I found these books to be useful after I was first promoted to the Technical Lead role, and even more helpful when I tried to improve the rest of the organization around me.
Lean Software Development
You are already familiar with Scrum, Kanban, etc. Now you can learn how to take the scalpel to them to get your team’s or organization’s productivity to the next level. Lean Software Development by Mary and Tom Poppendieck explains how to deliver software that solves the right problems, and how to do it efficiently while maintaining quality.
The key concepts that stayed with me were:
Eliminating waste: questioning the value of all activities, and eliminating any that do not contribute to better or faster delivery. The book also highlights more subtle sources of waste, such as handoffs, or code sitting in a repository waiting for deployment. Avoiding handoffs (which can add weeks or months to delivery) was high on my mind when I started advocating for teams going into each others’ codebases instead of placing work items on each others’ backlogs.
Delaying commitment until you really need to commit. In particular, for me this translated into avoiding having meetings to make decisions when there is zero chance of these decisions being implemented in the near future. Too often, either (1) the reality changes and the decision is no longer relevant, or (2) different people end up implementing the decision, and, since they have their own opinion, they start the decision-making process from the beginning again.
Keeping the feedback cycles short. On the shortest scales, I could clearly see the improvement when we started using continuous deployments, and the business analysts could give feedback to the developers within minutes of the developers committing their partially completed changes. On larger scales, I’ve benefited several times from rolling out a partially completed feature to figure out how to develop that feature further.
Continuous Delivery
Written by Jex Humble and David Farley, Continuous Delivery is the technical counterpart to Lean Software Development above. It lays out specific techniques and practices that help improve delivery and lays out some arguments and case studies for why it’s a good idea to do so.
If you’re working for a company with modern development practices, most of this book should not be a surprise. Some suggestions may be controversial, like encouraging all developers to work on one central branch. If you find yourself shaking your head in disagreement, I suggest avoiding the knee-jerk reaction of slamming the book shut and instead reading to see where the authors are coming from, because they usually have solid reasoning.
The Leadership Pipeline
The Leadership Pipeline by Ram Charan is a simple explainer of what the expectations are from people at different levels in a corporate hierarchy, from an individual contributor to the CEO, with focus on internally building leaders who can move through these levels.
The book is focused on a hierarchical structure in a large enterprise, but is still relevant in smaller or flatter organizations, with some adjustments. For example, a manager ultimately responsible for work of several teams would ideally be making sure that (1) there is the right set of teams, (2) they have the right key individuals, and (3) that the teams are succeeding, generally by setting expectations, providing support/resources, and holding the teams or the key people accountable. But normally such manager should not be giving direct instructions to the team members or deciding the work at the team level.
One of the directly actionable takeaways for me (and a lesson after I left the first team where I was a tech lead) was always to be preparing someone to replace me.
The First 90 Days
The premise of the book is: “the President of the United States gets 100 days to prove himself; you get 90” when you get a new role. That may be a bit over-dramatic, but the book does present a good set of strategies that can help get started in a new position, whether at the same company or a different one.
What I liked more about it, however, was the emphasis on human interactions to get things done in an organization:
- Ensuring that you understand the lay of the land in your organization, what motivates your peers/superiors/reports.
- Building the right team, and making sure that the team has bought into what you’re trying to do.
- Setting the right expectations with the superiors.
These are useful even if you have not moved into a new role anytime recently. Come to think of it, I probably should pay more attention to these than I do now.
Death by Meeting
There are two books from Patrick M. Lencioni on this list, each one deserving its own mention.
Once you get past the tacky case study that comprises the majority of Death by Meeting, the general gist is this:
- Most meetings are done wrong. They’re boring, unproductive, and often don’t get to the real matter.
- This can be fixed by structuring the meetings right, and ensuring that in-depth, candid discussions occur before making a decision.
The suggested meeting structure is:
- Daily status updates. Should be quick. Basically, the daily scrum.
- Weekly tactical: about 1 hour long. Should have a short status update, plus in-depth discussion on 1-2 topics selected on the spot.
- Monthly strategic (or ad-hoc): 2-4 hours. Discuss, decide on the 1-2 top critical issues. Should do some homework in advance.
- Quarterly off-site: 1-2 days. Focus on the overall strategy, general trends, organizational design, etc.
Sales EQ
I mentioned the emphasis on human interactions to get things done in an organization, right? If you want to crank that up a notch, it’s worth reading books on sales. Out of the four that I liked, I picked Sales EQ by Jeb Blount because it serves as a good entry point, presents the general principles well, and is not overly focused on a specific aspect of the sales pipeline, like prospecting.
If I get the general gist of it right — and I’m not a salesperson, so I may be wrong — the three main points to making a large sale (e.g. your idea) are:
- Make the people feel like you understand them and can relate to them;
- Figure out what the people’s problems are and link those to what you’re selling, e.g. how your idea will help your boss(es) achieve their strategic goals;
- Just push through the fear of objections, because they won’t buy if you don’t ask.
There are more points in the book, but they’re a bit more sales-specific, like “don’t waste time on people who aren’t moving forward through the sales pipeline”.
Aside from Sales EQ, Rainmaking Conversations and SPIN Selling also have elements and techniques that can be useful in a non-sales leadership position.
The Five Dysfunctions of a Team
The last book on this list, The Five Dysfunctions of a Team, also by Patrick Lencioni, focuses on making a group of people work well as a team.
Similar to Death by Meeting above, most of the book is a single large case study (what he calls “a fable”). This case study presents a dysfunctional executive team and shows how to make them work together and perform well. The conclusions of the book are similar to Google’s five keys to a successful team (which is also a good read if you’re responsible for team performance), except this book makes it a bit more tangible.