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?"
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?"
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?
Top comments (14)
"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!
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.
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!
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
Debugging Teams was one of my favorites!
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 (leanpub.com/becomingatechnicalleader), it's very interesting too.
That's exciting! Looks like you're off to a great start. Going to have to check that one out myself.
Sneaky referral codes in the URLs. Sly dog ;) :) :)
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.
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.
Awesome resource! Looks like I have my reading material for the new year 😊
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)
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.
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.