DEV Community

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

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

Danny Perez
DevOps Engineer & Engineering Manager at an ed-tech company helping our teams ship software quickly and reliably.
Originally published at Updated on ・6 min read

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.

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


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.

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:

These books cover teams in general:

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 😄

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

Discussion (14)

carlosaabud profile image
Carlos • Edited

"When am i supposed to code if I'm stuck in meetings and dealing with people all the time?" I feel you man... this part sucks hard time. Lately I find myself investing time outside normal working hours just to do some catch up but at the end of the day feels useless and frustration won’t stop. There’s always more to do.
I will take a look at those books! Thank you!

intricatecloud profile image
Danny Perez Author

Been there. Done that. And seen manager managers burn out after being there and doing just that. Sneaking a few hours at night or on the weekends just to get that feeling of being productive.

All too often it might feel like time spent managing isn't time well spent at all - despite that being our job. There's a balance to strike though, and hopefully you figure it out sooner rather than later.

teachingtls profile image

Hey Carlos, I fell down that hole at my last company. 70 hour weeks became the norm and my family took the brunt of it. It's not worth it.

The biggest thing that I had to learn how to do was to say 'no' to meetings that weren't absolutely necessary. It's a tough lesson, but it saves you in the long run.

And then there's finding the time to code inside the usual 40 hour work week that we should strive to keep. Well, I just put together a post on that topic. Hopefully you can take something away from it!

steelwolf180 profile image
Max Ong Zong Bao

This is really a nice collection of books will be my goto books to read :) I came across this 1 which is really awesome that talks about building a culture and communication

Debugging Teams by Brian Fitzpatrick, Ben Collins-Sussman

intricatecloud profile image
Danny Perez Author

Debugging Teams was one of my favorites!

schreiber_chris profile image
SCHREIBER Christophe

Thanks for the reading list ! I'm gonna have the role of tech lead for the first time soon, it will surely help me.
I'm currently reading "Becoming a Technical Leader" from Gerald M. Weinberg (, it's very interesting too.

intricatecloud profile image
Danny Perez Author

That's exciting! Looks like you're off to a great start. Going to have to check that one out myself.

ky1e_s profile image
Kyle Stephens

Sneaky referral codes in the URLs. Sly dog ;) :) :)

intricatecloud profile image
Danny Perez Author

Thanks for commenting! I had meant to leave all the links to Amazon as plain links. I've updated the article to remove the referral codes and added a disclaimer as well.

sandordargo profile image
Sandor Dargo

To me it's fine. I won't pay more if you put here a referral link and at least you receive something back for your efforts.

ashwinv11 profile image
Ashwin Vaswani

Awesome resource! Looks like I have my reading material for the new year 😊

ohpea profile image

If you could only recommend 2 or 1 which would you choose?
(I'm not going to add 9 non-fiction books to my queue all at once)

intricatecloud profile image
Danny Perez Author

If you're already facing some issues on your team, read Debugging Teams.

If you're struggling with giving useful feedback to your team, read Radical Candor.

If you just want to know how other people deal with their job as Tech Leads, then read Talking with Tech Leads by Patrick Kua (or just watch one of his talks like What I Wish I Knew as a First Time Tech Lead) for a low commitment alternative.

teachingtls profile image

Danny, this is a great list! I've only read a few of the titles on here but definitely am going to start up an amazon wishlist to start writing expense reports against after this one.