Joseph Lyon

Engineering Manager

<- Home

What Makes an Effective Team Lead

2023-03-07

I (re)started at Wolfjaw Studios in August 2022 after a stint as a Software Engineer at Bloomberg. Tasked with leading a team of 2 engineers I was excited to dip my toes into Engineering Management as this had been a goal of mine for some time. Transitioning into this role has been an ongoing learning experience as it differs somewhat from my experience as an Individual Contributor.

Writing on this blog keeps me accountable and straightens out my thoughts. Disclaimer: every situation is different so your mileage may vary. I will do my best to document this journey here.

Since my first day as a Team Lead, one of my driving questions has been: "What does a good engineering team lead actually do?". I'd imagine many people who are just stepping into this role have the same question. I have found this to be a surprisingly difficult question to answer, and I probably don't have a perfect answer. Given this I try to keep the following at the forefront of my mind in an effort to achieve the goal of being a "good" team lead.

There is much more that goes into it but keeping the above in mind with everything you do will provide a good guiding light to keep you focused on improving yourself and your team.

Note things like "write jira tickets" and "prescribe tasks to engineers" are missing. These are something you will likely need to do at points however it is outside the scope of this post. I do feel it's important to highlight that those are collaborative processes and not something you should be dictating, (although one person doing 80% of the work creating tickets before that process goes a long way).

Provide consistent communication and feedback to your direct reports

One of the most important things a team lead does, if the people that report to you don't feel seen or communicated with, things can fall apart really quickly. This point is deceptively simple and is one of the biggest challenges to being a team lead in my opinion. Achieving this is challenging. Without going into specific cadences, my strategy is as follows

  1. Go into every meeting with a list of topics to cover, write them down, keep on track and take notes. Write down everything, even the most simple things, you will forget.
  2. Always deliver feedback as constructively as possible, there is generally no reason to negatively refer to someone's work, rather highlight what can be improved by framing it as a constructive process towards building something great.
  3. Always slow down when addressing your responsibilities. If you are context switching frequently or working on some code task, put it down and prioritize this. It's better to keep communication consistent and if you are overwhelmed or burned out it's likely noticeable by your team and will rub off on them before long.

Highlight and Broadcast direct reports (and team's) achievements and blockers.

Another hugely important facet of leading a team, this point is crucial. In my opinion it's always worth it to highlight your team member's achievements over your own and over the teams. Be as humble as possible for yourself and make sure they are getting the credit they deserve. Their achievements will speak for you.

  1. Reflect your team's successes up the ladder, highlighting their accomplishments to your manager makes you look good, and gives your team the credit they deserve. Keep in mind the culture of the company when communicating outside of your team, a big part of your Job is navigating the org structure for the benefit of your team.
  2. Immediately raise blockers and try your best to remove them. No one likes to be blocked and if it reaches you it's probably something you need to help handle. Removing them may be as simple as making yourself available for a quick Q/A with the engineer to rubber duck it out or provide a new perspective.

Communicate the progress of your team to stakeholders.

This is simpler but critically important. Take in the information you gather from your reports and distill it into a digestible format (either a document, email or meeting). This goes hand in hand with highlighting accomplishments but also keeps stakeholders in the loop on what you are doing.

Taking clear and concise notes throughout the week is a very good way to do this and they can be used for writing this document. Admittedly I am occasionally worse in this department than I'd like but I get around it by looking at the artifacts (Jira tickets, Code Reviews, commits, 1:1s) that are produced through the week.

Give feedback and make contributions to the technical product of your team (review and write some code).

Last but not least this is probably closest to what you did as an IC, but you are doing it at a slower pace as it is no longer your only priority. Accepting this decrease in velocity is crucial and something that is very difficult to reconcile as you are likely used to seeing a concrete output (code & documentation) every week. Trust me, you are still delivering value and providing feedback through design discussions, setting priorities, and the communication you are providing. The work you are doing on the project should be distributed and intentional to give you context that can be used to provide feedback in technical discussions.

These are just four points that come to mind as I'm on this journey. I intend to write a few more articles in this series on some other lessons learned and goals I wish to achieve on my team to serve as a repo for myself and others to learn from and iterate on.

I also want to write about:

If you want to hear about any of these in particular first or just want to chat shoot me an email: joey@lyon.lol.