Not so long ago I read an interesting article on how to become a team lead and what to do in this role. And I wanted to tell you about the next stage of development - as a manager and head of the IT department or IT director in a small company.
It is worth noting that there are several development vectors for a developer, which are well described in the article Three roads for a programmer: expert, manager, founder . I will focus on the second area - the leader.
During my career, I have worked as a team lead for over 5 years and a little less than a year as a front-end leader. Yes, I don't have much leadership experience, but as a team leader I closely watched the work of my superiors. Based on these observations, I will try to tell you what these restless managers are doing.
In this article I want to talk about some of the tasks and areas of responsibility of the leader and how they differ from the tasks of the team lead.
In order not to write the long "head of department" further, I will write simply "head". In the text, I will operate mainly in two roles: "leader" and "team lead". By "leader" I mean the boss of the "team lead". There can be many hierarchical levels between these roles, depending on the size of the company.
The leader and the team lead have many similar tasks - the differences are only in scale. Many articles have been written about how to become a team lead and what to do in this role (for example, the one I mentioned above ).
In fact, the list of tasks for the leader is almost endless, but let's try to choose those that are most different from the tasks of the team lead:
- Strategy.
- Organizational structure.
- Goal setting rules.
- Wage fund.
- Hiring.
Strategy
Mature team leaders also have to think about strategy, but only on a smaller scale - within the team. The team lead should think about how to increase test coverage on the project, how to pump June, how to speed up the code review, and so on.
On a departmental / company scale, you have to think more abstractly. And the higher the leader, the more abstract he has to think.
Compared to the team lead's task, for example, increasing the test coverage. Then for the manager it should be a different goal - improving the quality of the product. Tests are already a tactic, one of the tools for achieving a goal.
The level of abstractness can vary depending on the scale and objectives. In a large company, the leader can simply set a goal and criteria for achieving it. For example, the goal is to halve the number of failures, the criterion for achieving it will be to reduce the number of bad reviews on "Bank-ru" to 10 per month.
Also, in a small company, a leader can set a goal in the form of specific tasks: implement e2e tests, set up monitoring and alerts. But this is a very thin line. Quite often it goes sideways when a manager tries to decide for leads or developers what tools to work with and how. For an executive with a developer background, this is a great temptation because it is an interesting job to choose tools and implement them.
In general, growing into a leader, you need to learn to break away from realizations and do more goal-setting, delegating the rest.
Organizational structure
Each company or department is a small state, and, as in any state, there must be a certain management system.
The task of the manager is to formalize this system: to describe by what criteria employees should be grouped, how career growth should take place, and so on.
As a company grows, this system always changes. For example, when there were 50 people in a company, the system was a hierarchy: manager → team leads → developers. But when the staff grows to 200 people, team leads alone are not enough. Heads of departments, curators, mentors and so on appear. Instead of a flat structure of teams, pyramids of units, departments, departments are built.
If on a scale of 50 employees, a manager can, on an ad-hoc basis or upon request, revise positions, then on a larger scale this has to be done on a schedule - for example, once every six months.
Generally speaking, changing the structure as you grow is necessary in order to be able to delegate and control. Yes, this is a familiar system for everyone, it looks simple and natural. But the main job here falls on the leader: he must decide at what point and how to change the organizational structure.
The same applies to general processes that allow you to reduce costs through unification. As an example - the process of creating and monitoring an individual employee development plan. Without a clear structure, it will be difficult to launch and develop this process. But if you have built an organizational structure in advance, identified team leads, established communication with them and regular synchronization meetings, then it will be quite easy.
There are many other common processes that a manager must create and delegate. If you start listing them all, it will result in a separate article.
Goal setting rules
The leader needs to develop rules by which team leaders can set their own goals and delegate them below. It is also important to control intermediate results - without this, employees may be working in completely the wrong direction.
There are several specific tools for this task:
- plan - in the sense of a planned economy;
- job duties - the same ones that are prescribed in the employment contract;
- OKR (Objectives and Key Results).
We will not go into a comparison of the effectiveness of these tools: it is important to understand that the task they solve is to describe the format of goals and the way they are delegated. This is often necessary when the organizational structure is ramified and it is necessary to compare these branches.
If you have five departments and they live in different goal-setting systems, it will be very difficult to objectively compare them with each other or delegate typical tasks to them.
Wage fund
Initially, I wanted to consider the task of assessing employee performance. But both team leaders and leaders are engaged in this task - each in their own planes. The only difference is that the decision to revise wages is made by the manager, who, to one degree or another, manages the payroll payroll).
Handing out to everyone fairly is a rather difficult task, especially if you do not work directly with those to whom you are reviewing salaries.
There are several restrictions for revisions:
- the size of the payoff, which usually descends from above;
- balance of salary between employees on equal positions;
- gradual and planned growth of salary.
At first glance, everything seems simple with the size of the payroll: you change the salary of employees and see if they fit into the payroll or not. But the difficulty is to adjust these changes exactly to the size of the payroll, especially if you don't know it.
For example, I am the head of the front-end department, the payroll department for the entire company. The CTO asks me to review my staff and send him the odds list. Since I do not know the size of the payroll, I will rely only on the merits of employees and their positions (it seems to me even more correct than if I knew the size of the payroll and was guided by it). Then I send the result to the CTO, it adds it up with the results of other departments, and it turns out that we have gone beyond the scope of the payroll. Some department is bigger, some is smaller. And then we start to "fit", it can take several iterations.
Maintaining the balance of salary between employees is not always a priority task, since often the salary amount is not disclosed and this is regulated by the relevant agreements. But if you allow for a large imbalance, this can result in difficulties in hiring new and retaining current employees.
Also, maintaining a balance can help with the issue of job revisions. For example, the salary of a senior in a company varies from 180 to 220 parrots. The time has come to revise the salary of senor Ivanov: now he already receives 220, but wants 250. Knowing the boundaries of the salary for seniors, this moment should raise a question in you, is Ivanov occupying that position? Maybe it's time to upgrade him to an architect?
Salary growth should mainly correspond to the market and the company's capabilities. Therefore, it is important to make revisions gradually and in a timely manner. For example, salary growth may depend on the position. Now junes grow to middle very quickly, so they need to be reviewed more often. Since the competition in the labor market is quite high, there is a great chance of losing an employee if you do not make a revision in time.
Even if the employee himself does not ask for the revision of the salary, it is better to do this with a certain frequency, changing the salary gradually. Otherwise, a situation may arise that you have not reviewed the employee for two years and now he asks for +150 thousand rubles. At best, this will raise questions from your management, at worst, you cannot afford it and you will lose an employee.
Hiring
The recruitment process is very extensive and requires careful monitoring. In small companies, the manager may be directly responsible for hiring; in large companies, this is done by entire HR departments. One way or another, the manager must be involved in the hiring process: HR alone cannot do this.
To understand why a leader is needed in this process, consider the tasks related to hiring:
- forming a group of experts you can trust;
- management of priorities between departments;
- analysis and forecasting.
Finding a good tech technician is easy - it’s hard to find and train an expert you can trust. After all, the portrait of a candidate is not limited to hard skills, the interviewer must be able to understand the candidate's motivation, his ambitions, character, etc. This topic is well covered in the CV through the eyes of the interviewer - I advise you to familiarize yourself.
All this should be taught to interviewers by the manager. Not necessarily directly, more often this is delegated from top to bottom. Ultimately, the most important thing is trust in interviewers, as hiring mistakes can be expensive.
In my opinion, difficulties begin when several consumers appear from one source of candidates. At this point, the leader has to deal with the management of priorities for these very consumers. Working with priorities requires a lot of attention, analysis and information about current affairs in the company. You cannot once set the rules according to which the hiring will work for a long time.
This process is lively and depends on many indicators that change frequently: staff turnover, business priorities, market changes, employee growth, and so on. Our company has an excellent solution for dividing the flow of candidates for different departments - market segregation by technology stack. For example, we hire React developers for products for servicing individuals, and Angular for legal entities. This avoids conflicts of hiring priorities between different departments.
Hiring requires continuous analysis and forecasting, as hiring delays can have a significant impact on the development of the business and the company as a whole, especially in a highly competitive environment. Therefore, it is a good skill to be able to predict when the volume of tasks will grow, and to be ready for this.
Keep in mind that new hires need an onboarding period that can last several weeks. Also, candidates may not pass the probationary period, not work well with the team and many, many other risk factors.
Unfortunately, having up-to-date information about employee needs does not always help. Hiring strongly depends on the market: the flow of candidates may stop at a moment and you will not be able to influence it in any way. Outsourcing is one of the good examples of dealing with such situations (not always). We have been rescued more than once by contractors who brought developers to our projects in a matter of days.
There is also an example of a more mature and forward-thinking solution to hiring problems - the opening of development centers. As the company grew, Tinkoff decided to open development centers in different parts of Russia, now there are about 12 of them. Moscow is not rubber and not everyone wants to move here, so the decision has fully justified itself, and now I can't even imagine how we would have survived without it.
Of course, the example is quite specific and true for large companies, but it should be taken from it that even for problems that seem temporary, it is worth looking for long-term solutions.
Output
The above examples are not strongly related to each other, I used them to show what exactly the leader does and how his tasks differ from the tasks of the team lead.
As you can see, the difference is that the team lead is directly involved in managing people and projects most of the time. And the leader is mainly focused on creating environments, structures and rules. There are many more interesting and important tasks for a leader: research, employee training, development of team leads, rotation in teams, presentation of work, etc. But more about this some other time :-)
Now I'm wondering what is there after the leader ? But so far I do not know the answer to this question.