9 books that helped me navigate my first time being a tech lead

The tech lead was moving to another team for a long-term assignment, and I took over as the engineering manager/team lead. From the outside, the tech lead's job seemed doable, but I quickly realized I was getting in over my head. Unfortunately, my team was responsible for a lot of centralized infrastructure as well as day-to-day technical operations. I had no tech lead training, and how could there be? I was certain that the tech lead role was so different across companies, how could there be guidelines to it? In my previous role as the senior engineer on my team, I felt capable of tackling larger projects, but I only ever had 1 project to tackle. Now, I needed to manage 3-5 projects for my small team of 5 engineers.

The best I could do was do as the last person did which only gets you far enough to keep your head above water. I realized that the only way for me to get past this would be to hit the books, and learn all the management that I never learned in college. I read a lot that year. More than the past 3 years combined. The most helpful books I read all boiled down to 3 areas of the job that I (like many others) struggled with: dealing with team & individual performance, delegating, and making my team a great team to work on.

*Disclaimer: I've tried to link to the authors website where I could. Otherwise, the links go to Amazon (not referral links) if you want to get the book. I have no association with any of the below authors, just a fan of their writing.

Dealing with performance

One thing I felt affected the team was an under-performing team member. Surely like many others, I hadn't ever seen an effective performance review myself, or seen how other leads dealt with performance on their team (Thats probably a good thing, but unhelpful for me). While I know at a high level what you're supposed to do, like talk about and deal with the problem, I struggled to actually do it - how could I, a new lead, give feedback to someone who was previously a peer on my team? It's definitely awkward the first few times! Fortunately, in this area, there are people much smarter than I who have shared their experiences in great deal to help you get past these types of problems.

• Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott
  • If you want to focus on giving great feedback - this provides a pretty powerful mental model for giving and receiving feedback without feeling like an asshole. It's focused on being upfront with people, lest you be plotting against them or humiliating them.
• Leading Teams: 10 challenges and solutions by Mandy Flint, Elisabet Vinberg Hearn and Debugging Teams: Better Productivity through Collaboration by Brian W. Fitzpatrick, Ben Collins-Sussman
  • If you want to focus on getting yourself un-stuck from some problems on your team - these 2 books go in-depth on common issues that teams might have, and some step-by-step guidelines for how to deal with them.
  • This was an area I didn't feel comfortable asking any of the other managers about. We had many small teams, and we were all very friendly so it was hard to find people you can talk to. The next best thing was seeing what other more successful leaders had done in these scenarios.
• Manager Conversation with Low Performers at UMCB on Youtube
  • It's very rare you'll ever get to shadow someone else's performance review - they're private and personal by nature (or you're HR). If you've ever wondered what a "good" conversation about poor performance could look like, this video helped me a TON! There's some other related videos there that will show you what NOT to do, but it is great to see how you can quickly diffuse an awkward situation.

Lesson #1 summary: Be incredibly explicit about your expectations with their job so that they can never say, "How was I supposed to know?"

Delegating

Another awkward part about my job was telling people what to do - our team had a mission that we were mostly aligned on, but we don't always get to work on cool stuff and the work still has to get done on time. I had seen other people do it well, I had seen others do it poorly - but I wouldn't have been able to explain to you why. I felt awkward the first few times saying, "hey roger, can you take a look at this issue?" only to have that developer come back with something that I wasn't expecting (see Lesson #1).

When I was a fellow engineer on the team, I felt capable of working on bigger projects and making sure that we shipped the right things, but now, I was also accountable for all the projects the team was working on, not just mine. I had about twice as many things to do now, and the typical-engineer-turned-manager in a bout of frustration might ask, "When am i supposed to code if I'm stuck in meetings and dealing with people all the time?" It was difficult to juggle all the projects that I was now responsible for, as well as do the work on critical projects, and plan cross-team initiatives, and insert 20 more things here.

• How to Delegate (Essential Managers Series) by Robert Heller
• The Busy Manager's Guide to Delegation (Worksmart Series) by Richard Luecke, Perry McIntosh

To summarize these books: Be incredibly explicit about your expectations with projects/tasks so that they can never say, "How was I supposed to know?"

While these two books sound a little cheesy, they gave me a great framework and process for delegating. After reading them, I started blocking out time on my calendar for going through our projects and trying to match people's goals and motivations with the work we had to do. A bunch of us got AWS certificates, one engineer earned with a promotion, and an intern joined us full-time. And we built great stuff too.

Making a good team

One way to build a better team is to see more teams and how they operate, and use them as guiding examples for building your own teams. The catch is, barring you leaving your job and working elsewhere, you won't get to see that many teams and so you might not even know what your team would look like at its best! I absolutely loved reading these books because they provided case studies of real teams with real stories across some high-profile companies. Some people had really crappy times at their job, others didn't and they explain why in-depth.

These books are more focused on software engineering teams:

• Talking with Tech Leads: From Novices to Practitioners by Patrick Kua
  • Patrick Kua is a great speaker with some of his talks available on Youtube about technical leadership covering things like What I wish I knew as a first time Tech Lead and Geek's Guide to Leading Teams
• Building Software Teams: Ten Best Practices for Effective Software Development by Joost Visser, Sylvan Rigal, Gijs Wijnholds, Zeeger Lubsen

These books cover teams in general:

• Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders by Andrew Stellman, Jennifer Greene
• Extreme Teams: Why Pixar, Netflix, Airbnb, and Other Cutting-Edge Companies Succeed Where Most Fail by Robert Bruce Shaw
• Scaling Teams: Strategies for Building Successful Teams and Organizations by David Loftesness, Alexander Grosse

To summarize these in one sentence: Be incredibly explicit about your expectations with the team's culture so that they can never say, "How as I supposed to know?"

Wrapping up

I had a great time leading my team for over a year. While at times, it was incredibly daunting to think how I would get through a particularly problematic week, my team would stay on track and over time, we were able to move to more proactive work. There's many different areas in management where you could spend days and day learning, but if you do 1 thing and nothing else...

Tell your team to be incredibly explicit about their expectations from you as their lead so that you can never say, "How was I supposed to know?"

If you found this helpful, you can ❤️ 🦄 it and follow me here on dev.to 😄

Lastly to fellow tech leads on dev.to - what was the hardest part of being a first-time tech lead?