by Danny Perez

These books 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, so 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 that 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?”

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.

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?”

Fellow tech leads on Medium: What was the hardest part of becoming a tech lead for the first time?

If you enjoyed the article, give it some ? and follow me here on Medium.

Originally published at www.intricatecloud.io on December 11, 2018.