How to become a team leader and not explode

Two years ago, I began to secretly play the role of iOS-lead in the company Touch Instinct and the formation of stable work iOS-department. After half a year it was transformed into an official position. Due to lack of experience, I had a huge number of problems that caused a burning sensation in the upper part of the chair. This was due to a number of factors:

• Lack of management experience.
• The lack of a number of competent person who has already passed the path of becoming from a new role for himself to a person who understands the structure of processes, responsibilities and solutions to problems.
• The instability of the overall processes in the company due to its young age at that time.

If you have become a leader and the initial euphoria has been replaced by a slight burning and despondency, then a couple of tips will not be superfluous.

Where do the lead come from

Historically, there are two classical structural models of company management.

The first is a horizontal control system . It is practiced less frequently, for example, basecamp or 37 signals . The point is that you have a number of strong specialists who are able to regulate their activities independently.

The second is a hierarchical control system .

There is a developer, behind him is the platform lead, behind him is the CTO, then the CEO. Each participant oversees a specific vector of development. The lower a person is in the hierarchy, the more highly specialized area he is responsible. The developer is responsible only for the code that he produces. Lead is fully responsible for the platform and its development. Technical Director is responsible for the technical component in the company. And the CEO - for the development of the company.

The more a company becomes, the more processes and participants appear, the more complex the hierarchy becomes. Additional roles are emerging, such as Mobile Lead. He submits the leads of mobile platforms, of which there can be more than one on the platform. It depends on the number of subordinates at a particular level in the company.

The optimal number of people who can be controlled by one person varies greatly from the field of activity and from the management model . In IT in the classical literature, this number ranges from 5 to 9 people .

Fewer people leads to the fact that the additional hierarchical role is redundant and simply complicates the processes.

More leads to control, training, and other functions becoming more difficult to perform. It is necessary to add new roles.

Consider the classic situation of career growth in an IT-company. When a person reaches a certain level of qualification, he can either move to the next level of the hierarchy with certain personal qualities, or change the type of activity / field of activity / company and grow further in the technical path. The picture below shows the classic short form of development. The next stage of development of the developer is team lead or tech lead. The first implies a move towards management, the second is a deep technical growth of a specialist. Team lead goes further into platform lead. From tech lead architects of different caliber are obtained.

The role of lead in the company

To begin with, we will define what the leadership of the lead awaits. Depending on the size of the company, its role may be reduced both to the management of a specific team and the development of the direction entirely. At the same time, it is necessary to be prepared for the fact that the developers will demand high technical skills from you, and managers of a higher level - to perform managerial tasks. Most often, a team lead is to some extent a programmer, and to some extent a manager.

Technical role

It is said that with time team lead begins to lose the skills of a programmer over time. In reality, most programming fundamentals were formulated more than 40 years ago. Sometimes this knowledge is more valuable than knowledge of a specific sdk. But more often, mentoring besides helping with the simplest software issues comes down to the following:

Ecosystem building. Now in the IT business wins the company that provides not just a product, but is trying to build an ecosystem. Which can solve many problems of business and allows you to use the various functions that the company provides. This applies to both Apple and Google and Facebook. Over time, any business starts to turn into a platform. A similar situation is observed in the development. You need to build an entire ecosystem for a developer so that there are as many less questions. This applies to process things, and architecture. You need to create a documented system of guides that will allow new developers to quickly integrate into the process, and team members do not forget the accepted norms.

Building a learning system. Adequate lead should competently build the learning process of all team members, correctly matching their own interests with the company's business objectives. If a person wants to learn a complex custom UI, then the task of the lead is to figure out how this can be used for good. This also applies to other areas, whether it is technical knowledge or managerial background. It is important to monitor the implementation of these tasks, usually the developers in their head put a lower priority on this task. Try to help in the development of even those areas in which you have less knowledge. Take the necessary specialist or give time to figure it out for yourself, and then let him tell others. So a person will strengthen their knowledge. The situation when the developer or you do not have knowledge in any area is normal. Awareness and acceptance of this contributes to learning.

Instilling the principles of attitude to the code. It is very important to convey to the developer the idea that the code itself is not worth a penny. Only the functionality that is executed by this code makes sense. Hence the whole ecosystem that needs to be built grows. It is important to understand that business dictates the rules for writing code, and not vice versa. If you have a banking system with extremely high reliability, then you need TDD. If you are writing MVP applications, then there is no point in building a complex system and architecture at the first stage.

Psychological role

Argued that most developers are introverts. In fact, it is very close to the truth. Thanks to this knowledge, there are several techniques that can be applied in the work.

Organize monthly meetings with developers. The scenario of such meetings is repeated every month. At first, the developer says that everything is OK, everything is fine, there are no problems. But the main strength of the psychologist in matters. The conversation reveals that the evaluation system on the project last month can be improved, and the relationship between the departments can be tightened, and an original solution was invented, which can be rendered as basic and can be written according to it. After all, on another project, the same problems arose and solved them longer than necessary. Conversation must be outlined, because it can be great thoughts. They can and should be implemented. After such conversations, some of the problems are leveled. Since the process is iterative, it helps fix problems and does not take much time. Such meetings do not need to be turned into departmental meetings. It should be just one-on-one conversations in a relaxed atmosphere. So you can solve even complex personal problems.

Become a "big brother." Lead is responsible for the work of his unit. He should be aware of the tasks, deadlines and quality of output functionality for each developer. However, in the process of work you should not go to extremes. The proverb “Everything is good in moderation” works perfectly here. Try not to interfere if everything goes well. At the same time, always keep your finger on the pulse and prevent crises. The employee works most comfortably when he is not under pressure from above, but at the same time he feels the influence of an invisible “big brother” who is not a controller, but an adviser.

Implement the "faceless code." The longest and most difficult process is to bring the code of your department to a “faceless code”, when it is impossible to determine by style who wrote it. This direction is correct and difficult. If solution variability is possible, you will meet several camps. So that in the event of a crisis situation you don’t fall for "they decided then so, but it turned out badly, and now all the disadvantages have surfaced," every issue should be diplomatically addressed. Remember that other people will work with the basic solutions that you develop and coordinate. Make it comfortable for them.

How to make the chair not burned before

Classic - when the most productive developer becomes a lead. The management often thinks that since you make features faster, you can do as much as the average developer, plus take on the lead responsibilities. You can ask to register directly in the contract what percentage of working time you will program. The area of ​​responsibility becomes completely different, your responsibilities change. There are two scenarios.

• You start to work a lot more in order to be both as a developer and as a team lead. This usually leads to burnout.
• Work as much as before. As a result, you will not have time to do both the features and the tasks of the lead.

At the stage of coordination of a new role, think in advance about the list of questions, expectations from a new role. Ask what is expected of you. Understand what you specifically need to do and state it. Only then get to work. Otherwise, you will not meet the deadlines for development, do not adjust the processes, the training system and all other tasks. Relationships with managers, developers and other people in the company will deteriorate one way or another. You will think that you are a hero who humped over the weekend for the good of the company. And in fact, they became a person who cannot be relied on. After all, it is not known whether the task will be done and how well it will be.

That is why you need to clearly regulate, why you need to program, how much time and what it will give the department and the company as a whole. If it’s about 30% of the time, during which you will be designing an architecture for common solutions, libraries, or standards, this is one thing. This will help not to engage in routine tasks, not to forget the code and look at it more globally. But if they tell you about 70% or 90% of the time, then people just don’t understand why they need a team lead. Or plan in advance that you will work more than 40 hours. You can either explain reasonably how to do better, or simply refuse. It is best to talk about expectations.

Make a development plan. It is necessary to make a clear plan for the development of yourself and the department at least for the next year. This may be the development of common processes, the creation of basic common solutions, conducting a course of lectures or the creation of a school. All based on the needs that the company has now. If the goal is to learn how to write code, then go to the side of architecture and meta-principles. If you declare yourself on the market - participation in conferences and publications. If there is no such plan, then a series of problems begins:

• people don't understand what you do;
• you yourself do not understand what you are doing and what you need to do. Be in utterly uncontrollable chaos.

Find a mentor. It's great when there is a person who has already passed this way. If he can frankly answer your questions - this is a huge plus and not use this big mistake. Ideally, if this is the leader of your platform, which you personally know and respect as a specialist.

Do not think much. Take the habit of direct dialogue in case of misunderstanding. A huge pile of problems will be solved, and at the same time they will not turn into something more, including personal conflicts.

Track performance. It is necessary to immediately begin to direct and control the process of implementation. What does this give us? The fact that we stop doing seemingly important routine tasks through simple delegation and can perform the tasks that are included in our plan.

Automate. Plus, various kinds of optimization in the form of CI / CD / static analyzers, code generators, basic libs, and so on. All this saves us time in the future.

Time Management and Delegation

Someone from the developers goes into the software binge for a week and comes back with a ready feature, but someone needs daily monitoring. Observation, analysis and logical thinking will help you figure out who is who.

Delegate. The main thing is the understanding that most tasks can and should be delegated. At the first stage it may seem that things have become more. Especially if you were a developer with key responsibilities like writing architectural solutions. It may well be that there will not be a person with the necessary competencies. It means that competencies need to be grown. It may be difficult to accept at the first stage, but this is the only correct way in your position.

Control time. Keep track of the time allotted for the task. It's about tactical and strategic objectives. I am not talking about daily work, although it will be a major success factor. Tactical tasks mean the execution of specific large tasks in the form of creating basic libraries, documented processes or a learning process. Under strategic - the definition of the vector of development. At what moment to leave with objective-C? How to create an ecosystem so that it works more efficiently? What should be done to increase the efficiency of solving business problems? These are examples of strategic issues. They are the most difficult and most durable, but your tomorrow depends on them.

The important point will be, as you understand, what is interesting to people. This can be used as an additional factor in the growth of the developer and the development of a separate component of your ecosystem. Developers tend to like to do interesting things and in their free time. You can help them with this. It is only important to understand what is really interesting to man.

Mistakes, negative and cons

You can talk long and beautifully about what a wonderful person and specialist you are. But the fact remains that only the one who does nothing is not mistaken. And the more a person starts to move away from his comfort zone, the higher the probability of error. The specific departure from the full-time developer to a more managerial role implies a strong interaction with the team and other departments in the company. It is logical that there are new situations that are not standard for a person. And he does not always know how to solve them.

When meeting an unpleasant situation, the first thing to do is to understand that only you can fix it and no one else. And the longer you drag it down, the stronger the gun of time will shoot at the end. And now let's move on from abstractions to concrete examples.

Making decisions. It happens that people in the team down from the top. You need to immediately clearly state the rules here: either you have the right to veto absolutely all decisions to build a team, or you need to explain to management how it will work that way. Ideally, the most common practice is when a team lead itself forms a team. Moral responsibility increases as decisions are made by the lead itself.

Personal qualities. There is a person in the team who for some reason does not suit you. At the same time, it does not matter at all whether you hired him, or he already had it, or gave it from the side. All people are wrong and you are no exception. Especially in the first stage, when all your interview is not based on understanding how much a person fits into a team, but does he know how to solve an algorithmic problem of finding an element in a binary tree. You should understand that any algorithm can be learned in one day, any framework with due diligence from the initial application on the first day before a deep dive within a month. And personal qualities, a certain “abstract sense of code” for a day, a week, a month or a year cannot be corrected. In this matter, it is all the more unnecessary to focus on hr and assume that it is their job. Because in the end, a person will work most of his time with you while working in the company, and not with hr.

The disadvantages can also be attributed to the fact that over time your technical skills will fall. This is both a myth and a truth at the same time. The role of the lead allows you to take a broader look at some technical aspects, on the meta-principles of programming. And the fact that you won’t know how to program a new CallKit framework in iOS 10 and what interface methods it has is going to be hard, but overall it’s possible.

Coming out

For a long time I felt a sense of pride in the fact that none of the members of my team quit, and even more so he was not fired for poor performance / large shoals at work. He considered it a duty to help a person, even if it took a certain amount of my free time on the weekend. But it is necessary to understand once and for all that all that a manager of any level has to do is to guide and help a person, and not to do for him. Conduct a few face-to-face conversations to identify the problem. So that there is no conflict of expectations and that both of you understand, the problem must be solved. Build a problem solving strategy and tightly control it. It may not work. To make sure that the problem is not with you, then ask another developer in the team to act as an independent expert in evaluating performance / qualifications or just moral teamwork. If your opinions agree, then leave without a shadow of a doubt. So you will save your nerves and the nerves of your team members. And even the person himself will be grateful after a while that this is how it ended. The more time passes and the more experience I get, the less time I need to understand whether I made a mistake or not.

You need to understand in advance that there are conflict situations. But most often this is solved through a personal conversation. Just speak straight, although it is extremely difficult.

Building a scalable scheme. A departure from the role of the "absolute ring"

One of the most frequent negative stories that I hear from developers about lead'ov - all the interesting pieces of the lead takes itself. I get another feedback from the leads, that the most frequent problem is a task and it can never be delegated to ANYTHING !!! 111. From here a number of problems follow.

• Time is a limited resource. If the lead does interesting tasks, and not its work, then the work will simply not be done.
• Concluding most of the competences within one person, you get a completely unscaled system. And what is most interesting, you get the bus factor. Of course, you can operate on this when discussing wages, but in fact you are not getting better as a leader, but only usurping power.
• Your team is not growing. No one understands the established processes, because there are none.

Your entire guideline or HIP word KPI is only in your team. If there is a cool team that cohesively, quickly makes a product and follows the processes - you are a good lead. Try to gradually increase the different kinds of competencies in other people. It is extremely important that this be a conscious choice of the person himself, and not a practice imposed from above.

Options for future growth

Once you have already had the question “what's next?” When he was a developer, then you will have it at the team lead stage. And here you can also follow the previously disassembled scheme. The only question is whether to develop as a manager or still go deeper into the direction of development in
the role of the architect. Try it, and you can clearly answer this question. But as I said earlier, do not ask it yourself in the first few months. Because being outside the usual comfort zone, a person by default is inclined to react negatively to any incentives. Understand at least the basic things, then make a decision.

What to do if you become a lead

The role of the team lead, as well as the role of the manager, has a number of specific features depending on the external and internal factors of the business, time, technology and vision of the company itself. If you become a lead, the first thing:

• Set up departmental work processes. At the same time, document them as much as possible.
• Think over the employee training system.
• Set up the correct delegation system for various tasks and only direct and monitor their implementation.
• Join the dialogue in any incomprehensible situation. Truth is born in controversy. This is the only way you will understand people and receive confirmation that they understand you.

What worked in my case might work in yours. The main doctrine is that everything comes with experience. If you work in this direction, of course. Problems with time will not disappear, you just learn how to solve them.

Remember that you can learn not only from your own experience, but also from others' mistakes. Teamlead is awesome.

List of sources

S. McConnell. How much does a software project cost?
J. Hank Rainwater How to graze cats
David Heinemeyer Hansson and Jason Fried. Rework