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).
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
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.
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.
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.
If you want to hear about any of these in particular first or just want to chat shoot me an email: joey@lyon.lol
.