9

I've received a promotion to Team Lead, what are some traps I should avoid?

Profile picture
Senior DevOps Engineer at Taro Community5 months ago

Hi Taro,

I've just been lucky enough to receive an official promotion to Team Lead for my current team. It's a small company (~100 total headcount) and a small team, and I feel like my manager and I have very tight alignment as do I and the rest of the team, and thankfully there's no obvious/major problems (i.e. interpersonal problems, poor performers, etc). However this is the first time I've ever had direct reports or really been in any form of an official leadership role, and I'm concerned I'm going to instantly run into obvious traps/issues as a result.

I've read "Engineering Management for the rest of us" by Sarah Drasner, which has been really helpful in thinking about the role, but I'm really interested in hearing any advice people can provide to help me avoid fanning any hidden flames.

256
5

Discussion

(5 comments)
  • 14
    Profile picture
    Tenured Staff Software engineer
    5 months ago

    First, congrats on your promotion!

    It sounds like you are off to a good start, so I'd relax a bit and not constantly scan the horizons anticipating something bad :). This will conserve your energy toward more productive work, trust me.

    Now, to your actual question. Here is my top 3 pieces of advice:

    1. Trust the engineers who are following you. Let them know that you're there to help, but give them autonomy so that they can have a purpose and are motivated to achieve mastery. This will also help you scale yourself as you'll be able to pick up work they are not picking up. Be open to wear multiple hats in addition to your TL duties given that you're at a small place.
    2. Do what only you can. Very soon, you will have many competing priorities and you might be inclined to do it all by working longer hours and trying to stay on top of everything. This is not scalable. Delegate the work others in your team can handle so that you can focus on impactful work for yourself and differentiate yourself. See my LinkedIn posts on delegation at the end of my response.
    3. Keep learning technically and show your team that you, too, are learning with them. TL activities and the the resulting glue work can become all-consuming. But cultivating technical depth and breadth are essential in this line of work. So, schedule 2-4 hours every week to learn something new or dive deep into the technical work that your team did for the week. Internalize your learnings. Try to make some active time in the team to learn & teach/share; maybe a lunch & learn or some such forum every 2 to 4 weeks.

    Some more reading resources for you down the line:

    1. Camille Fournier's Manager's Path has a chapter dedicated to TLs.
    2. Will Larson's book on the Elegant Puzzle of Engineering Management. The cliff notes on Github are a great resource.
    3. Influence Without Authority by Cohen and Bradford

    My LinkedIn posts on delegation:

    1. Superficial beliefs that keep us from delegating
    2. Deeper beliefs that keep us from delegating

    Hope this helps! Feel free to ask follow-up questions.

    • 0
      Profile picture
      Senior DevOps Engineer [OP]
      Taro Community
      5 months ago

      Thank you! This is really helpful advice

  • 10
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    5 months ago

    Congratulations on the promotion! Being a good tech lead is a huge topic (which is why we're working on a course for it literally right now), so here's my Top 5 high-level pointers:

    1. Act proactively - Make thorough design docs and set up 1 on 1s with core stakeholders.
    2. Overcommunicate - Don't be afraid to say the same thing multiple times. Try to share a weekly project update every week.
    3. Grow others and delegate - Mentor the engineers around you so they trust you and can take easier scope off your plate.
    4. Be honest - Don't hide problems. If something goes wrong, let people know as early as possible and take ownership of the issue.
    5. Add buffer - For budding leads, 95% of them underestimate how long something will take (it's a mix of trying to look good and not thinking through team-related edge cases). If you have a big project, just assume 1-2 people will get sick during that time and factor it into estimates. Factor in oncall rotations too.

    You can find more great advice here: [Taro Top 10] Tech Leadership

    • 2
      Profile picture
      Mentor Coach for SWEs | Former Staff Software engineer
      5 months ago

      Ah, Alex made some great tactical points.

      On the point of buffer, I recommend adding at least a 20% more buffer for relatively well-defined projects, and more for the nebulous ones.

      It's also better for the on-call to not be expected to do very much feature work during their on-call week. This reduces their context switch, and they can apply any free time toward improving the on-call resources like alerts and documentation. A clean hand-off to the next on-call is also highly valuable.

    • 1
      Profile picture
      Senior DevOps Engineer [OP]
      Taro Community
      5 months ago

      Thanks, I really appreciate the advice! I can't wait for the course.