Hello. My name is Aleksandr Guzenko, I am the team leader of three front-end development teams in a large company. Recently, one of the employees came up to me and said: “I want to grow to team lead. Where do I begin?" This is how the idea for this article was born, which I promised to send to him later as a guide.
In this article, I’ll tell you how I became a team lead, what skills you can’t do without in this position, and how to improve your team management skills if you’re an “ordinary” developer.
Who is a team lead and what is he responsible for?
Let's start with the theory, without which it will be difficult to understand why you went to manage the development, but instead counted the project budget.
In the classical sense, a team lead is the head of a development team. This is true but with some reservations.
In today's landscape, team leads extend beyond programmers to include designers, analysts, testers, SEO specialists, and various IT and non-IT professionals. Therefore, it's more precise to define a team lead as the leader of a group of employees sharing the same role, although I'll focus specifically on developers.
Secondly, the team leader is not just a team leader, but the main link between employees and management. This is an important addition, and I will try to explain why below.
Thirdly, to understand what the team lead is responsible for, it is important to distinguish between the role and position.
The role of the team lead involves mainly managerial tasks:
- convey management's position on important issues;
- carry out organizational changes;
- distribute tasks among employees and monitor implementation;
- answer current team questions;
- resolve disputes;
- create a comfortable atmosphere in the team;
- consider the characteristics of each team member;
In its pure form, the role is rarely found, even if the list of responsibilities on the recruiting site says otherwise.
The position of team lead can combine several roles at once: team lead, technical lead, and lead developer. In this position, a specialist often writes the code himself, manages the work of the team, and is responsible for the technical part:
- creates a project development strategy;
- designs architecture;
- defines a technology stack for specific tasks and projects;
- monitors the versions of the libraries involved;
- responsible for code quality;
- controls the level of technical debt so that it does not become critical for the project.
It is much more convenient for business when the team lead and technical lead are one person. In practice, even in large companies, the position of team lead involves a combination of all three roles in different proportions. Therefore, ideas about what a team lead does often differ.
If you ask developers from different companies what the responsibilities of a team lead are, the answers will most likely be different. There will be a similar range of opinions among the team leads themselves. To verify this, just go to any job search site and look at the list of responsibilities in different vacancies.
Who can become a team leader?
To lead a development team, you need serious competencies and experience. Therefore, the most common and correct way to become a team leader is to first rise to the senior level and only then aim for a leadership position. But this doesn't always happen.
If the team consists only of middle programmers and among them there is an initiative employee who is aware of all matters and supports the project, he will be an excellent team lead. Yes, he has less technical skills than the senior, but if there is no one higher in the team, his competencies will be quite sufficient.
At the same time, not all seniors will find the position of team lead a suitable career path. Working in a leadership position should be truly interesting, otherwise you can wither away from the amount of managerial workload.
How to understand that you can handle the workload?
Short answer: try it. Tell your manager that you want to take on additional responsibilities for free and see what happens. This is a win-win scheme, so management is usually willing to cooperate.
The team leader wins: someone does his work for him.
The business wins: the work gets done, but you don’t have to pay money for it.
The team lead trainee also has an advantage: after working in this mode for several months to a year, he can understand for himself whether he succeeds and whether he likes to lead. And if the answer to each point is “yes,” you can seriously think about growing in this direction.
How to become a team lead: growth strategies
There are only two options. The first is to sit out all the other developers in the company and become a team lead as the “oldest” employee. However, there is a risk that the word “old” will not have to be put in quotation marks. The second option is to take the initiative yourself.
I'll tell you how it was for me. According to my diploma, my profession is manager, and I studied programming on my own in parallel with my studies at the university. So I decided to become a development team leader even before I got my first job as a programmer.
At first, I worked in small companies. It took me two years to get the hang of it and grow from a junior to a strong middle player. Without experience in programming, you won’t be able to become a good team lead: you need to understand how the development process works, and what mistakes and pitfalls there are.
A few years later, I came to work for a large company and immediately indicated that I wanted to be a team leader. In large companies, once every six months or a year, they usually conduct a performance review, when the manager meets with the employee and together they build an individual development plan for the near future. At each such meeting, I said that I wanted to become a team lead. The first time they told me: “Everything is great, but first gain experience.” We created a development plan so that I could gain leadership experience.
For about six months, together with my team leader, I assessed and decomposed the tasks and tried to distribute them among the employees. When the quality of our work was equal, more or less, the company just formed a new front-end development team, which I headed. In large companies, you don’t have to wait too long.
They say that there are two important milestones in the development of a team leader: the first is from two to six employees, and the second is 7 or more. At first, I had only one employee, and now I lead three front-end development teams - 12 employees.
I simply showed initiative, showed up in front of management, and as soon as the opportunity arose, I was appointed team leader.
Wait for growth or leave for another company?
Team leads are often raised within the company, and this is important to take into account. If there are prospects for growth at your current job, you should take the initiative and try yourself in the role of a manager. But if the whole team is front-end and back-end and everyone is their own team leader, you shouldn’t expect a miracle. It is better to move to a larger company and indicate that in the future you want to take a leadership position. You will need time to study the processes and understand the business logic of the project. But when a suitable position opens up in the company, they will most likely choose you over an outsider.
What skills will help you become a good team leader?
In the position of team lead, both hard and soft skills are equally important. Developers usually know what is lacking in hard skills. Moreover, these requirements are strongly tied to specialization and technology stack, so there is no universal list. I will talk about soft skills that I consider critical for the product and the company.
Ability to find problems in processes
The speed and quality of development, and therefore the cost, depend on the processes in the company, but they are rarely ideal.
For example, you fixed a bug and are ready to bring the build to the stand, business is waiting. But to do this, you need to go through five pipelines and collect approvals from everyone involved. You write to those in charge - silence. You start tugging at them, but formal messages arrive just to respond - everyone has no time. It can take up to six hours before the corrected version reaches the stand. And all this time you spend trying to reach your colleagues, and the business loses money.
Another example is the exorbitant number of accesses to different systems, programs, stands, and repositories. Banks usually suffer from this. A person comes to work, he needs to understand the project, but for the first month and a half he cannot do anything at all, because - that's right - there is no access. Another problem with accesses is that there are many of them, and their names are impossible to remember. For example, instead of “access to the repository” in the directory there will be A32B18KZ - try to find it.
I know real cases where a developer was unable to start work for a month or two. All this time he received a salary, but became disillusioned and quit. That is, the company spent six months looking for an employee, paid him a salary for two months, and then had to start the recruiting process all over again.
Such problems in processes complicate and slow down work. The team leader’s task is to see them and understand what exactly is working poorly and where the failure occurs.
Ability to solve problems or communicate them correctly to the business
It is important not just to see problems in processes, but to offer solutions. You can deal with some difficulties yourself without involving management. For example, a team is struggling with an inconvenient state manager. If the project is small or just at the very beginning, you can arrange a call, find the best option, and outline how to gradually introduce a new state manager without losses. A solution was found, and the business did not even know about the existence of the problem.
But most problems can only be solved with the help of senior management. For example, to speed up the release of builds to the stand, you can identify a person who has good connections in all departments and has access to decision-makers, and involve him in the approval process. If there is no feedback from colleagues from other departments, he knows who to write to and can set up the process manually. But such work requires a separate position, so you need to get approval from the company's management.
The access problem is solved similarly. Most developers need the same systems and programs. For example, for front-end developers - a repository, stand, Jira, etc. So why not make a standard access package for them and hire a person who will request them for a small salary? But this also requires the will of the company’s top management.
Therefore, one of the main skills of a team leader is to be able to correctly convey the essence of the problem to the business. There are some secrets here.
-
Once is not enough. Problems are rarely resolved after the first contact, so you need to go to management at certain intervals and remind them of the problem: “this is demoralizing the team,” “we are losing productivity.”
-
If you see how the team’s problems and business interests are connected, hit this spot. For example, there was a critical bug that took two days to fix, even though there was only a few hours of work involved, and as a result the business lost money. You go to management and talk about the problem of coordinating builds. At such moments, businesses are as open as possible to suggestions. But the solution must already be ready.
Speak the same language as the business
The surest way is to calculate how much the problem is costing the company before taking it to management.
As a front-end team lead, I regularly collect feedback from employees. For example, developers constantly complain that tasks are poorly described. Because of this, it takes a long time to find out what the author of the problem wanted from them. Then the testers come to the developers and try to understand what has been done and what exactly they need to test, and further along the chain. As a result, everyone still understands the essence in their own way, and bugs appear.
I calculated that on average the team spends 40% of their working time fixing bugs. Together with the team, we conducted a retrospective analysis and found out that half of these bugs arose only because they misunderstood the essence of the problem. That is, 20% of developers' working time is wasted because tasks are poorly described. This is the number you should go to management with. It is easy to convert it into money - the same language that business understands.
Create a favorable environment within the team
When people enjoy working with each other, any interaction goes smoother. Why is Scrum so popular? This is not about documentation but about people. Sometimes it is more effective to call a colleague for two minutes than to wait two days for him to document his answer and describe everything in detail. So, when there is an atmosphere of mutual understanding and mutual assistance within the team, it is easier for people to contact each other. For example, you found a piece of code and you don’t understand what it does. If the situation in the team is not good, you’ll simply be afraid to call and ask - “he’ll think I’m stupid.”
To maintain good relationships within the team, I hold hour-long calls once a week. We divide this time into three parts. The first is “relaxed”. We share memes and jokes. The second part is a discussion of problems. Sometimes we throw cards together in Miro, which is not to everyone’s liking. This is how I get a picture of what exactly is slowing the guys down. Then we can come up with options for solutions, which I will then lobby with management. And we finish “relaxed” again: we can discuss movies or something else. Such meetings create a positive atmosphere and make me, as a leader, understand what pains there are in the team.
Delegate
A common mistake of new team leads is to focus work processes on themselves. In this case, if the team lead suddenly gets sick or goes on vacation, the work will begin to stall, and he will be constantly pulled. To prevent this from happening, you can teach someone from the team to perform part of the team lead’s responsibilities. For example, trust others to distribute tasks once a month. This way, someone else on the team will have this skill, and the team lead will be able to go on vacation calmly, knowing that nothing will break without him.
Perhaps this is a good criterion for assessing the work of a team lead: if you are removed from the team, the safety margin should be enough for a month.
Properly distribute areas of responsibility within the team
In development, a metric such as the bus factor is used to manage risks on a project. It shows how many team members must be hit by a fictitious bus to bring down the entire project. If the bus factor = 1, you have serious problems.
For example, we are developing a complex project. It has a sophisticated module, and only one developer knows how it works and knows how to handle it. If this person gets sick, quits or goes on vacation, changing this module will turn into a very long and expensive procedure, which will negatively affect the entire project. To prevent this from happening, you need to gradually teach other employees to work with complex modules or libraries.
The team leader must be able to correctly distribute responsibility within the team, without confining processes to one person, without making him critical to the project.
Strategic vision of the project
The team leader must understand where the project is going, what problems it has, and how to solve them. For example, the team’s total workload is 100 working hours per week. And the business throws in its wishes for all 100 hours. At this time, technical debt is accumulating on the project, which is also time to deal with. The team leader’s task is to track the moment before the technical debt becomes critical and lobby management so that the team spends a certain percentage of its time on solving current problems.
What problems might you encounter as a team leader?
It’s better to know at the start why team leads are burning out to recognize alarm bells.
Misunderstanding on the part of the business
This is the most common problem when, month after month, you try to reach management, you come up with your problems and a ready-made solution, but at the top, they just put the problem in the backlog and nothing happens. There may be several reasons. The first is that you are speaking the wrong language to business, and you should change your approach. The second is that your boss “knows everything best” and continues to do everything his way. In this case, the best solution would be to change the company.
Lack of resources
A simple example: your team is constantly overwhelmed with tasks, and there are no longer enough hands. Small and medium-sized businesses may simply not have the money to hire new employees. In this case, you can take on an additional role, such as the role of a systems analyst, and start describing tasks so that the work moves faster. In large companies, most likely, there is money, but the decision-making chain is too long, and there is no guarantee that a cat has not passed between the third and fourth-level bosses and the process will not stall because of this. Here you can only try to win someone from the top management to your side or just wait.
The results of the work are not visible
It happens that you come to a company, develop a strategy, make plans, and are passionate about work, but time passes and nothing changes. It doesn’t take long to become despondent here: “Who needs all this?” In this case, you can conduct a retrospective analysis to understand why the project is not progressing. Ask yourself: “Maybe I’m hitting the wrong target, solving the wrong problems?”
Lack of tools to achieve the goal
This happens when you are put in a leadership position, awarded responsibility, but not given any control levers. For example, there is no way to independently conduct interviews and recruit developers to join your team. There are only two options here: either try to reach out to the business and indicate your position, or change the company.
Direct access to senior management
To develop the product and solve the team’s current problems, the team lead must be in constant contact with decision-makers. If access to the “top” is closed, problems will remain unresolved, promising development strategies will remain unspoken, and motivation to work will be lost. In order not to burn out, it is better to change companies if you cannot establish relationships with management.
Permanent emergency mode
Sometimes there are too many tasks, and the team can no longer cope with the incoming flow. In a situation of constant emergency, regular calls fade into the background - who needs memes and empty chatter when this hour can be spent eliminating bugs? As a result, the whole team turns into a driven horse, which sooner or later will run out of steam and people will start leaving. All the team lead can do is try to force staff expansion or put tasks in a queue.
The bad atmosphere in the team
This can happen if you join an already established team where everyone hates each other. A toxic style of communication has already taken root in the team, and there is no talk of any mutual assistance. Then the only thing that can be done is to disband the entire team and recruit again.
Whatever the problem, there is always a chance for a favorable outcome. Don't give up after the first failure. It may be worth waiting a little or changing your approach. But if you’ve tried everything, and it feels like you’re knocking on a blank wall, then the decision to leave will be the only right one.
Conclusion
The ability to solve problems is an important quality of a team leader. But, alas, it doesn’t always work out. But if you feel that you’ve been marking time for a year or two and you can’t influence it in any way, but you want to grow, changing companies is not a bad idea. Don't be afraid of change. Changing jobs is normal.