What I Learned During My First Year as a Team Lead

Crucial lessons to be a successful technical team lead.

Alexandr Ursu
JavaScript in Plain English

--

Photo by Quino Al on Unsplash

Of course, the title sounds serious and I will try to not disappoint you. I’m not considering myself an ideal technical team lead, but I would like to share with you the main takeaways and challenges after my first year in the role of a team lead.

Just before jumping into the role I was googling and trying to find some basic principles and rules for being a good leadership either you’re a manager or team lead, but everything I found was too abstract and without too many insights. I was looking for something more practical. This is what I will try to do in this post. That’s being said let’s jump into details.

  1. Task delegation.

Probably most difficult task so far for any programmer, lead, manager. As a programmer it was extremely difficult for me to share a task with someone on my team, I was considering it a waste of time to explain to someone what should be done since I already knew all the details — I was worried delegating will take longer than just doing the work. I guess to some degree we all think delegation is a sign of weakness but I realized the opposite, it’s a sign of a strong leader.

As a team lead, I started getting a lot of information and tasks, from different sources, meetings, different departments, managers, etc. I quickly ended up being overloaded with work while seeing my teammates running out of tasks very quickly. At this point I realized that I should do something about that, one of the main roles of team lead is task delegation, only this way you can make workloads manageable. But how? What would be the best approach?

In order to delegate, you have to fully understand the task and only then let it go, yes, it might sound strange but this is the biggest secret behind it. Delegation is like teaching — you explain someone how something works and at the end, you have the exam, in our case, it is a completed task, you have to make sure it works like expected. At the beginning I started delegating everything I didn’t clearly understood or didn’t like to work on, thinking that they should take time understanding it, but It quickly fell back on me. Lot’s of questions started flowing into my direction, or vice versa during standup calls I could not understand what team members are talking about. Sometimes I had the feeling that the task is taking a wrong direction but not owning all the details I was lying to myself thinking — ‘they know what they’re doing”.

Don’t lie to yourself. Understand the task then delegate, this way you’ll have full control of the situation.

Additionally, you may need to consider delegating tasks you love doing but are no longer part of your job.

2. Credits and failures

I never ever assumed someone else credits. I’m so proud of myself when in the daily meetings I can express my positive thoughts about some extraordinary job done by the team or some specific team member. They deserve it, it’s their glory time and it should never be taken from them. Always praise the person for a good job.

On the other side be responsible for the entire team. If something didn’t go well, take responsibility. Be a good advocate for the team and always defend it.

If someone did something wrong, never speak up in public, discuss it in a one-on-one meeting.

3. Know your team.

You can have different people in your team, junior devs, senior devs, frontend guy, or someone who knows DBs very well. Your goal should be to know everyone and understand what they are good at.

In order to efficiently use most important resource ‘time’, you should try to delegate tasks to the most appropriate person. If it is a Front-end task don’t delegate it to a person who is better at the Back-end and vice versa. But, always leave some room for new opportunities, if the person demonstrates some interest allow them to take it, this will help them keep motivated.

And of course, don’t miss an opportunity to have a beer with your team, you’ll discover other good parts about them :).

4. Stress and Impostor syndrome.

Very often the working day is almost done but I have a feeling that I haven’t done anything today, at the same time I was busy with something the entire day.

As a programmer your work is measured in tasks, you almost always can see a result at the end of the day either it is a new UI, a new table in DB, or an endpoint, but as a team lead, your task could be hard to be measured sometimes. You could have 5 meetings that day, or you ended up testing lots of staff on the new project, spending half a day looking at the pull requests or some deployments.

Impostor syndrome is a common problem in the digital era — make sure you track everything you’ve worked on during the day, so you can refer to it later and make some conclusions.

Being a team lead is stressful. You’ll get a lot of new tasks and responsibilities. You’ll be responsible for any crashes or wrong system design, it could be overwhelming sometimes. Make sure you’re not running into burnout — take some time for the family and don’t forget about vacations — you deserve them.

5. Keep the team informed.

Set expectations early. When a team works well together, it’s because its members are operating from the same mindset and are clear about their goals, deadlines and standards set from the very beginning.

You’ll be involved in different management meetings, you’ll be given different roadmaps and deadlines. Make sure to share the highlights from the meetings and all the deadlines with the team, decide together how you’re going to achieve them, only this way you’ll be able to be on the same page.

6. Feedback.

One of your goals as a team lead is to develop your team’s capacity to give and receive feedback and help people get used to articulating how they feel the team is doing.

Here are some baby steps to be able to achieve it:

  1. Retrospective sessions. At the end of every sprint (2 weeks usually), we gather for about an hour to share the feedback on this particular working cycle. The main questions are what went well, what went wrong, and what could be improved.
  2. Structured reviews. Every once in a while set some review meeting where everyone should say one thing they like about the other members and one thing that would be helpful if they did differently. When you hear the same feedback from multiple members it will make you aware something is wrong and chances are higher that you’ll improve on this part. You want to give everyone the opportunity to say his piece, I’m also sure you’ll get some feedback as well :).
  3. If you see that someone is doing something wrong repeatedly, that afterward end up in a waste of time of multiple people, please make sure to let him/her know asap. It could be hard or unpleasant but later it will be appreciated by that person.

This is what I learned during my first year as a team lead. I know this is just the beginning and there are many other important things to be discovered and discussed in the feature. Please share your thoughts and experience below.

More content at plainenglish.io

--

--