7 Misconceptions of a Beginner Team Lead

This text is a translation of an article originally published on DOU.ua.

Hello! I'm Igor Stepanov, Senior Team Lead at Plarium. I’m currently managing a group of other team and technical leads, and I’m responsible for all things technical on the client-side of the company’s flagship title RAID: Shadow Legends.

In this article, I will share my personal experience as I transitioned from developer to Team Lead, and give examples of seven misconceptions I had to overcome at the beginning of this journey. The truth is that when I became a Team Lead three years ago, I had only a vague idea of the kinds of difficulties awaiting me in my new position.

This should be useful both for experienced developers who are thinking about a career change, and for novice Team Leads who would like to bypass the pitfalls I faced!

Misconception #1: The Team Lead must be the most tech-savvy member of the team

As a Team Lead, you need to understand how each area of the project works, and you must be able to assess the quality of completed tasks. But you also need to accept that, in many instances, members of your team will be stronger than you in terms of technical know-how.

As soon as I took the Team Lead position, I was overwhelmed with fear about my lack of experience. Among my team members and other colleagues, there were many specialists with more technical experience than me. The department had a Team Lead, thirteen developers, and two architects. I had no idea where to start — how would I begin interacting with the team? How would I even begin to build credibility?

But despite the fact that, at that time, I didn’t know my way around the project that well, my skills were enough to provide the team with a sense of direction. There were several technical problems, but at the time all I needed to do was ensure we had an organized team.

Indeed, attention to detail and self-discipline can help you take into account the interests of each developer, and the project as a whole. Keep in mind that if you don’t have the expertise to make a complex technical decision, you can always turn to a Tech Lead, an architect, or a specialist in a specific field.

However, you shouldn’t stop there. Learning is an ongoing process: pay attention to what your team members say and do, because your own technical knowledge will improve, and the team's respect for your decisions will grow. You might be forgiven for gaps in your knowledge in the beginning, but in the long run, not developing your technical skills further will only prove to be a wasted opportunity.

But even as your own technical expertise grows, as the Team Lead you should remain aware of the strengths and weaknesses of each of the specialists on your team. That way, when it comes to a technical challenge, you’ll know exactly who can be trusted to deal with it most efficiently. With any luck, problems will get fixed, team members will be happy, and the overall atmosphere will be positive. Remember, the key performance indicator of a Team Lead is not only just how well individual employees are getting on, it’s also about how well the team functions as a whole.

Misconception #2: Rivalries are good for the team

A Team Lead should never foster rivalries between team members, nor should they imply that such behavior is acceptable. Competitiveness in a work environment is very common. But when it turns into open rivalry, team members could end up stressed, and their motivation and productivity might well collapse. If left unresolved, rivalries can lead to departmental disunity and conflicts between employees.

Instead of filling everybody in on some new or useful discovery, team members keep that knowledge to themselves in hopes they’ll earn kudos at the expense of others.

To avoid rivalries developing between individuals, Team Leads should remember that each employee is unique, each team member contributes to projects in accordance with their knowledge and capabilities. Try to equally praise specialists for equivalent achievements. Compare the performance of a team member with their past selves, not with their colleagues.

Rivalry between teams may be more critical. Let’s say, for example, that one of the Team Leads wants to change the code review format. Instead of discussing it with a fellow Team Lead and coming up with the best solution together, the rivalry-minded Team Lead will most likely share it with their own team and then go straight to presenting it to the Head of the Department. Meanwhile, a ‘rival’ Team Lead will feel excluded from the decision-making. Worse still, they might attempt to sabotage the implementation of that idea. You run the risk of team members witnessing such behavior between Team Leads, learning from that example, and following suit.

I saw this happen myself: when several Team Leads were simultaneously appointed in our department, rivalry between the teams began to emerge. The solution was a clear division of areas of responsibility between Team Leads and their teams. Specialists began to build up their unique expertise, and take responsibility for the development of the project. Ultimately, the team members ended up complementing each other.

As a Team Lead, if you treat everyone on your team equally, that will make it much easier for them to stop comparing themselves with each other. Form a single goal and give everyone the opportunity to concentrate on their own contribution. That’s how you can cooperatively build a common cause.

What’s more, with this approach, employees will be more willing to share knowledge with each other. The expertise of the team will grow as individuals develop, and that expertise will not be limited to one person.

Misconception #3: Team Leads will be programming as often as they ever did

As a Team Lead, you will no longer have the opportunity to devote as much time to programming as you used to when you were a developer. New responsibilities can keep you from programming for a day, two days, sometimes even a whole week.

At first, this was unacceptable to me. To keep my technical skills sharp, and to show by example what kind of work I expected from others, I began (or rather, continued) to do lots of programming. In addition, I constantly introduced new rules, standards, and ideas, added processes, and optimized existing ones.

This led to me coordinating the work of the team all day — and programming all evening. I was totally exhausted, I looked at pull requests in the hope of offering optimal solutions for all areas of the project. Trying to have my cake and eat it ended in failure: I soon realized that such a workload was simply impossible to maintain on a permanent basis.

What I learned was that a Team Lead’s duties should be flexible, and it should be based on situations that arise from specific projects. I had to keep in mind, too, that any vertical career growth involves additional administrative responsibilities: to a lesser extent for a Tech Lead, but certainly for a Team Lead. If you don't want that, horizontal growth strategies are probably better for you.

But don’t despair! A leadership position allows you to implement more of your own ideas, which means you get to produce more code that meets your personal standards.

Misconception #4: Working overtime is efficient

All Team Leads know that working overtime can solve short-term problems. But what they also know is that it's not an effective tool in the long run: overtime can take away the fun of work, and can even harm your health.

Overtime also suggests that you’ve failed to plan. If you find yourself often working overtime, you should take a step back, assess the situation, and try to understand why it’s necessary. If circumstances allow, reschedule the work before you decide overtime is the right call.

I didn’t fully appreciate this at first. Instead, as I mentioned above, I tried to spend the same amount of time programming as I did before I became Team Lead. I sincerely believed that I was invulnerable, that I was fully able to endure such a workload for many years to come. I even tried to respond instantly to every message in the online chats. But after a couple of weeks, I realized I had to rethink the system, prioritize chats, and draw up a schedule. For example: maybe I could just check new messages every half hour? I understood that I didn’t have time to do everything at once, and had to learn to prioritize.

The same applies to your team members: be sure to monitor their working hours, and regularly discuss their workloads and plans. In an effort to impress, team members may bite off more than they can chew. A sense of responsibility, and the desire to keep one's word, can prevent employees from admitting they’re finding it difficult to keep up. If it ever becomes clear this is the case for any of your team members, it just means that the scope of tasks and/or deadlines need to be reviewed.

Sometimes, it might appear to you that the people around you aren’t as conscientious, and perhaps they make mistakes that you’ll end up having to deal with. You may begin to ask yourself: “Why should I correct these little things if Oleg was too lazy to spend 5 minutes making changes to his own work?”

In reality, high-quality, productive work output from you and all your team members requires everyone to be in good condition both mentally and physically. Without resting and looking after your health, this condition will rapidly deteriorate. Take breaks, do sports, get creative — doing so will actually make you more interested in your work. Sometimes, something is worth doubling down on to get results on time, but you can't live in constant stress.

Misconception #5: No one can do things as well as I can

When I first became Team Lead, tasks would come up and I would think, “I’d rather do that myself”. After all, why waste my own and others' time on clarifications and follow-up checks? Clearly, I found it difficult to distribute the workload between myself and the team. The problem was, I was still thinking like a developer.

It shouldn’t be confused with routine task distribution: delegation is the transfer to another team member of a task, along with the responsibility and the authority that comes with it. A responsible approach to this process will help free your time and let you fully concentrate on priority tasks, and it’ll also provide subordinates with opportunities for development. Such a transfer of responsibility can take an employee out of their comfort zone, but at the same time, it can positively affect their growth. It will also help you, as a Team Lead, develop relationships with team members that are based on trust and mutual respect.

Bear in mind that delegation means allowing employees to make mistakes, and there’s nothing wrong with that. If you allow an employee to make a mistake, and then correct it together with them, chances are they won’t make it again. The main thing is not to throw a person into the middle of the ocean, in the hope that they’ll magically learn how to swim. Take into account the capabilities and desires of the employee and control the execution of the task in accordance with their skill level. In other words, avoid the ocean, and start with the swimming pool :)

Ideally, you’ll mix tasks of moderate complexity with tasks that challenge team members and allow them to learn something new. Of course, this option isn’t always available, but it’s precisely what helps the systematic growth and development of both the team and its individual members.

The thought that no one will do something as well as you could do it might, in some situations, be true. But eventually, it won’t be, if you give others the opportunity and space to develop themselves. Someone might end up doing a task even better than you could!

Misconception #6: "Duct taping" is always bad

Say there’s a technical problem that needs to be solved as soon as possible. Unfortunately, if you were to solve this issue as you normally would, there wouldn’t be enough time to release new content. An excellent option would be to add some kind of "duct tape" — a quick, temporary solution — to reduce the severity of the issue and give yourself time to release an update. Then, you’d create a proper fix for the next update.

At first, it seemed to me that “duct-taping” was unacceptable. This misconception isn’t inherent to me: the developer's brain typically prefers to systematize, arrange, and generalize. Therefore, as soon as some decision doesn’t match up to usual standards, it is disparagingly called a “duct tape”.

But the reality is that you just need to get your tasks completed on time, you don’t need to please the Gods of Programming.

It’s important to know when to use "duct tape", and to remain aware of how it will affect a project in the short- and long-term. Technical "debt" tends to accumulate and reach critical mass at the most inopportune moment, so it’s essential that you pay those debts systematically. If you allow yourself or the team to undertake a quick fix, immediately start a refactoring task, and schedule a proper fix for the next iteration of development.

If the task you’re working on is critical, and the problem with the task is significant (and your other deadlines aren’t pressing), be sure to convey the issue to management. Allocate additional time for a qualitative analysis of the problem and put all your efforts into developing a solution. And how best to convey the importance of this issue to management? Demonstrate the ways in which this problem will affect the main KPIs. Numbers can help to prove the importance of any task or issue.

Misconception #7: A good Team Lead should be able to handle everything on their own

Many problems I experienced at the beginning of my journey came about through a personal unwillingness to show ‘weakness’. Sometimes, I’d take on tasks that I knew I’d never complete within working hours. I programmed, worked on the team and its development, reviewed processes, and tried to improve everything that I could.

This approach didn’t end well. I couldn’t discuss my experiences or problems with colleagues, because I feared they’d see weakness and doubt my capability. And, in the end, were my efforts worth it? To the project, maybe. But personally, it was something of a disaster. If I had only been more aware of the misconceptions above — especially 4 and 5 — I could have done just as well without getting exhausted and having my nerves ripped to shreds.

When you are a Team Lead, you, just like everyone else, will face problems and difficulties. There’s no need to be ashamed of them, and nor should you ignore them or keep them under wraps. If problems are afraid of anything, it’s publicity! Talk publicly about your problems, and a solution will always present itself. You’ll probably discover that you’re far from the first to encounter such issues.

Be sure to share your experiences and difficulties with your manager, other Team Leads, and the HR rep for your team. Strong employees — Team Leads included — aren’t the ones who don't encounter problems, but the ones who know how to identify them, solve them, and avoid them in the future.

Conclusion

Three years and counting as a Team Lead has made me realize: success comes when you’re willing to get up more times than you fall. And don’t be afraid: the more you fall, the easier it is to get back up again.

Of course, you won’t fully understand all this until you live it for yourself. But hopefully, this article will help you to avoid falling into the traps that I encountered.

Good luck to each and every Team Lead out there!