How to identify a team member that can become a great team leader

Rotem Benjamin
6 min readJun 11, 2021

I’ve been working in Tipalti for almost five years. During this time period, we have grown a lot. When I joined, our engineering department had 15 people with three small teams. Today, our engineering department consists of more than 120 great people, with 16 development teams, 4 groups, and counting. That’s a big leap in less than five years.

At Tipalti, we believe in internal promotions. That means, most of our team leads and engineering managers are Tipalti employees that were promoted. That said, it becomes our job to identify the current developers that will become our future managers.

The question is then, who are the people fit to fill this challenging and important role in the organization. How do we know that a good developer will become a good team leader? What indicators can help us predict (no 100% certainty of course) if someone will help coordinate, develop, and motivate other people and make them a team, rather than a group of people?

“What makes a good team leader?”

  • Communicative: compared to a developer, that can be ok while keeping communication to a minimum, a manager has to be in constant communication with multiple roles in the organizations. Whether their direct reporters (developers, QA, etc.), the product team, their manager, and fellow team leads. Communication skills are vital for making a coordinated, motivated, and successful team. The team members can rely on the fact that tasks need to be done, but driving the team is done by explaining why. Aside from what a manager is saying, is how it is being said; A calm manager that puts things into perspective makes the work (and life) of their employees less stressful, more enjoyable, and will improve the atmosphere of the team.
  • Positivity: the team shares the same faith. The team leader, being part of the team, unsurprisingly enjoys and suffers from the same things the team members do. Hence, being positive and not complaining about unpleasant surprises along the way, will make the team follow that behavior. I’m not saying that a manager needs to pretend everything is perfect but to accept the fact the sh*t happens, understand that it’s just part of our lives, and think of it and how it can be avoided next time. A manager always leads by example so the team will follow their behavioral patterns — A positive and committed manager will lead to a positive and committed team.
  • Problem-solving: A team leader will encounter different types of challenges on the way; design problems, resource allocation problems, time-to-market constraints, personal issues with employees, etc. Not all issues have a straightforward solution, some of those issues the manager will face for the first time and some can’t get to a win-win situation. It’s up to the manager to be creative and think out-of-the-box to make the most of what he is faced with. He or she may need to negotiate their way for finding the best solution that will fit the constraints in the problem.
  • Delegating: A manager that does all the work himself can only increase its team capacity up to a certain point. Basically, a manager's job is to increase its team capacity, and it can be achieved by creating a team in which every person feels the owner of some area. This is done by giving responsibilities to every person in the team, letting them know that it’s up to them to make that area successful. It’s not being out-of-scope and throwing a person into the water, but being more of a guide on that road, rather than the owner.
  • Mentoring: As said, the number one priority of a team leader is to increase the team capacity. Why, again? 5 developers working with an increased capacity of 20%, contribute much more than a team leader that increases its own capacity by 50% (not to mention not all of their time is invested in coding). A constant improvement process of a team member accomplished by doing repeating one-on-ones, tech talks, design sessions will let one grow. Improving the ability to work independently and to solve issues on one's own, yet always being there to help the person improve by giving constructive feedback and a tip is what makes a leader.
  • Listening: The list of attributes above is here for making an employee better as a developer, a contributor of code, and as a working unit. But the employee is foremost a human being. That said, like everyone, they will have ups and downs, frustrations, celebrations, desires, and aspirations. Being there, to listen, even without saying anything, can mean the world. That is also for getting feedback about yourself without trying to defend yourself or saying something that bothers them about the company’s policy. No, I’m not saying that you should only listen and never talk, but it does say there may be times it’s preferred to do so due to two main reasons: One, nothing is perfect — not even you or your company, and that’s totally fine! Second, being smart is more important than being right, and if someone needs to unburden, not letting him will not do any good.

What indicators should we be looking for in our developers?

The above is nice but…. what does it have to do with developers in your team? How can we tell anything about them if they are not leaders?

It’s true, unfortunately not everything can be checked before someone is promoted. However, there are some key indicators we can look for and may imply on someone that would be a great fit for a future manager.

  • Problem-solvers — that’s easy, everybody is presented with issues on their day-to-day work. The scope may be different, but a problem is a problem, and a creative solution is a creative solution. Look for that in your employees.
  • Team player — there’s no reason to believe that someone who was a solo task force within a team will change ones color and behave differently as a team leader. Someone that can be part of a team and work nicely with others, someone that is always there to help and assist other team members, and do that willingly and calmly, those are a great indication to someone that will help others in a team to the same. In addition, being a team player doesn’t always mean you teach but also learn — a developer that is open-minded and willing to accept other people's opinions and follow when necessary, regardless of the seniority, is also a great attribute we should be looking for.
  • Communicative and social — This can be seen in different scopes: the team and you. Given the obvious, that we are looking for a person that has great communication skills and can express themselves, we should be seeing someone that updates progress and communicate to you, the manager, when needed and without you needing to ping him. From the team members’ perspective, you should see a person that has good social relations and is widely accepted as a role-less mentor. If someone is neither liked nor accepted by the team, there’s no reason to believe it will be different when the person gets the title to do so.
  • Positivity — A human being that doesn’t complain, looks for the positive side of things and knows how to ignore (or even laugh) the challenging and unpleasant parts of the job. Usually, someone that has a central part in a team supports the atmosphere, in some cases even more than the manager. Look for that quality.
  • Independent — A perfect employee of any manager is someone that works efficiently and independently. Someone that works on a fire-and-forget mode lets you get more time for other tasks without the need to ping him frequently. This kind of virtue is a sign for someone that will probably be able to handle tasks on their own and lead a team that works as a unit without frequent interrupts. It doesn’t mean that there’s no communication; we do expect everyone to raise flags when needed, and to give updates on critical tasks, but not for every small task that should be handled on one's scope.

All in all, choosing a team lead is a challenging task, but a successful selection may contribute to the organization for many years. The job obviously doesn’t stop there and tutoring never ends, but a nice starting point is always welcomed.

--

--