A common career path for software developers is into a “team lead” role. On the surface it’s a very attractive role for the organization: a transition for dev’s interested in management, retaining some of that key senior-dev contribution, and avoiding a hire for a more traditional Manager role.
But its pitfalls are serious: TL’s generally struggle balancing individual contributor commitments vs. management responsibilities, and the perceived importance of each.
From personal experience, and from managing Team Leads, some tips!
Guard Your Time
Being a Team Lead requires you to be really aware of how you spend your time. For example, time spent on lofty, heroic senior achievements can be less important than more predictable output, especially if others depend on you for their next steps.
Ask yourself these questions:
- How much time can I set aside for individual work. (2-4 hours per day is normal).
- How much time can I dedicate to organizing or unblocking work, alignment, reporting, client calls, etc. (4-6 hrs/day)
- Do I have direct reports? How much time will I dedicate to 1:1’s, mentorship, onboarding, etc. (1-2 hrs/week/person)
This split will impact team activities like pair/mob programming, whiteboarding sessions, etc. because you may not have long stretches of dedicated time available anymore.
The simplest way to visualize this challenge is to set up your calendar.
- Block off dedicated slots for certain types of work (then guard them with your life).
- Pro-actively book time with your team for work that you need to do together.
- Identify things you have to do well, give yourself time to prepare (weekly demo’s to the CEO, client meetings, etc.)
.. knowing that it’ll change week-to-week, but have these rough proportions.
Most importantly, run this setup by your manager. Maybe they have a different vision about how to spend your time?
Focus on More Constructive Efforts
The “individual contributor” time Team Leads have needs to be used very constructively.
There’s a few ways to play this … some thoughts:
Taking high value, undesirable work (difficult-to-reproduce bugs, client escalations, etc.). Those issues keep you connected with details, and identifies difficult things to mentor the team on.
Architecture and high-level software design for the team. Something I found works well is scaffolding new capabilities, and being involved in that first week .. but letting the team fill in the blanks and iterate.
Technical documentation becomes more important as you’re more exposed to stakeholders, other teams, etc. Docs can influence more of the organization than your dev work does.
Code reviews can get overwhelming for any lead. Good practice is to defer to the rest of the dev team, and focus your review attention on very important or risky deliverables.
Understand Perceptions of Your Contributions
Regardless of other duties, Team Leads are often perceived as “developers first”. That can be positive or negative, depending on how you really want to contribute.
Navigating this perception of the role can be really challenging.
Personal story: I was leading a team of four on a new product. The plan was ambitious and unlikely to succeed, so we had designed a better solution that would move the timeline, but more likely to succeed.
I went to my executive asking that we re-evaluate the promised timeline so we can deliver this better thing. They started asking me about some current implementation detail that I wasn’t aware of. Then mentioned that I should know those details, and ignored questions about the plan. It was frustrating; I felt under-appreciated. Later I realised the mismatch with what the company expected from a Lead role, vs. what I was focusing my energy on day-to-day.
Building resiliency for those times, and being flexible enough to contribute on the many sides of the role, is tough .. but good for professional growth.
Hopefully you found this helpful, and good luck with your Team Lead future.