We thought that before the discussion we should “synchronize” in terms. All at least roughly represent what vertical growth is. With horizontal, everything is more complicated: good examples of horizontally grown people are not so visible from outside the company. What is their job? Do they write code or are they just doing code reviews, compiling methodologies, etc.? And returning to vertical growth - what are the main problems facing the (future) team lead? We asked these questions to the discussion participants and today we publish their answers on Habré. Those developers who chose a horizontal branch of development will be called experts - bearing in mind that they manage not people, but technologies.
Eugene Rossinsky, CTO ivi
Indifferent developers
In addition to vertical growth, on an administrative line, developers can grow horizontally - in technology experts. Then more important than hard skills. These are very strong, not indifferent developers who develop the concept of product architecture. They do not need management - they independently find “holes” in the products and close them. If necessary, they write the code themselves, assemble and parse the commands. On such people we hold most of the architectural solutions. Our company has 26 teams, each of them has about 10 people, of which 2-3 are experts. Moreover, sometimes we create teams only from such superstars. An expert’s growth depends on the level and number of projects that he oversees.
When a developer understands that he is growing “wrong way”, the main thing is to uncover the need for change before the team and work out a migration plan. Once a quarter, we hold meetings in which each member of the team alone with a team leader or scrum-master discusses where to grow further. We also have a guild of scrum-masters and special chat rooms with discussions of similar topics. Then we look for where you can attach the person, and make a roadmap with milestones that he should go through. If a person wants to change something, he needs to do it so that it is beneficial for the company.
One of our JavaScript developers wanted to take the lead in automated testing. After some time, he stopped writing code for applications and began to oversee the strategic development of autotests in all of our structural divisions. Another case: an employee wanted to become a leader, but was not ready. At the 1 + 1 meeting, he received a detailed feedback about what level he is now and what he should work on before leading the team. After that, the employee had two options: either believe in feedback and follow the development plan, or go to another company, where he has enough skills. He left. It was also so that the expert wanted to become a leader, he became him, but in the process of work he realized that management was not suitable for him. He went back to the experts - and happy.
Stop doing everything with your hands
Suppose you occupy a leading position in a natural way, without conflict - that is, you first gain credibility in the team, your colleagues listen to you. Then everything is fine, there will be no offense. If in one team several people claim the role of team lead, then there are already variations. Either they agree to team lead together, distributing tasks among themselves, or one of them selects another team for himself. The Timlids know who is stronger in what - and try to complement each other. There are enough tasks for everyone.
Being a good programmer and managing programmers is not the same thing. You need to stop doing everything with your hands, you need to learn to trust people. And this is difficult. Instead of immersing yourself in micromanagement and trying to drag everything through yourself, you should lay down processes close to you in the team, and the team should accept them. For example, it is important to set up a review with your minimum inclusion, set up linters, organize the processes of setting and accepting tasks and autotests. You need to own different tools and methodologies for team development.
Now the market has many directions, both vertical and horizontal growth. Salaries are about the same. You can develop in any direction. Both technical and humanitarian skills are important. As a pistol without cartridges does not make sense, so ammunition without a pistol. But those people who are rushing both that and another are especially valuable. Which are at the junction.
Andrey Plakhov, Head of Search Functionality
What is important for growth from a developer to a leader
Three things are important:
- the basic level of sanity and consciousness (which almost everyone has in the industry),
- do not consider yourself exceptional (but with this, many are much worse),
- and not to consider any of the colleagues radically worse than themselves - people intuitively feel this.
The main rule is: to believe that everyone has strengths that can be learned. Your interlocutor is a living person, and not just an accessory from whom you need to knock something out or get it by deception.
Suppose a developer is worthy of improvement in his hard skills, but he is not promoted. The reason is usually because he considers himself so much cooler that he doesn't even hide it. And then he needs to change this attitude before developing flexible skills.
I disagree with the Buddhists that change can only come from within. It is easiest for a person to change if he sees a vivid example when he was wrong and feels pain from it. It is easy to see other people's shortcomings, it is much more difficult to realize your own. It’s like the difference between glamorous selfies and photographs in which you look like in reality.
Which growth is easier
Programming is a meditative activity, well suited for introverts, and most programmers dream of growing deeper, not wider. Which is better - to become a guru, around whom they tiptoe and who sometimes does something great, or a leader who, on the contrary, runs around everyone? The second option is easier simply by the law of supply and demand. To grow in breadth and engage in communication is not so risky, nothing unique is required of you. But the guru is competing with the whole world.
You cannot be a person without subordinates and not write code. The fact that you became an expert does not mean that you will come somewhere, change the world with a few changes in a couple of lines, and everyone starts whispering - “Oh great!” The experts I know write a lot of good code. He is not always supernatural, although he also comes across things that I just do not fully understand, and I perceive this normally. It's like reading chess games of Magnus Carlsen. Each specific move is probably understandable, but at the same time it is clear that in general the champion understands something much better than the others.
The most important activity of an expert, not related to writing specific artifacts, is a code review. With many concrete examples, you can teach a whole school of people who will know what writing is like pg . If a person tries to formulate general rules, he will convey his wisdom not as well as in concrete examples.
Who does not need to go to the leaders? There is such a phrase - if you can’t write poetry, don’t write. Everything is not so tough with the leadership, but if you don’t feel in yourself a desire to tell people something, teach them something, if you don’t have your own vision, how everything should really be arranged in your team, you’ll probably you will not enjoy the leadership. It’s difficult to manage, dreary and often unpleasant. And the only compensation for this, in addition to money (and the difference in money at the level of top programmers is not so important) - the ability to do everything not as usual, but as it seems right to you. If this burning desire is not, it is better not to lead.
Olga Megorskaya, Head of Crowdsourcing and Platforming at Yandex
Not a task, but a startup
It seems to me that the basis of professional growth is how you perceive and conduct the tasks assigned to you. Any received task can simply be taken and done, or you can take it as your small product, microstart. And to develop it as it should be for a startup: to increase the area of its influence on the world.
With this approach, people get many opportunities - you yourself form a field in which you will continue to grow. If you have a large-scale history, the company will not be sorry to invest more resources in it.
From this point of view, there is no big difference between the development of you as a leader and as an expert: in one case, you develop the sphere of influence of your service, in the other, your expertise. But the development path of a pure expert is more complicated. The impact of your expertise on the world will not dramatically increase only because you put the next unit of knowledge in your head: you need to make your expertise become generally accepted practices. And in this regard, it is harder for an expert, because if you are a leader, it means that you have some additional resources. If you are an expert, then you have only your own authority. To grow only in that capacity, you need to have powerful personal charisma. Perhaps that is why there are fewer such people than leaders. But those who are and are successfully following their path are outstanding people.
In my unit, no one categorically refused leadership - sooner or later many receive his portion. Some resist a little longer. In fact, this is surprising: in Yandex there are much more offers for executive positions than the demand for them. We have to persuade people, they break down, answer that they are not sure. But in general, such a path seems more direct to me.
Ways to grow gradually
For the gradual growth of a person, we have an effective institution of virtual teams, v-teams. It can be agreed that the promotion candidate will first lead a virtual team, and then become - or will not - a formal leader. In addition, we have many interns, you can take and mentor at any time. This is likely to serve as another intermediate step to managing the team.
If you, as a leader, do not enjoy something in your work, do not be afraid to delegate it. Together with the team, you have additional strength, in contrast to the situation when you are alone. Just find what you don't like, someone who likes it, and give him the opportunity to grow by delegating these tasks to him. Global rule: the leader should only deal with what his subordinate cannot do. You gradually lower tasks to a lower level, your guys study, lower even lower if you have several levels of hierarchy. In my practice, this is the only approach that allows you to support a scalable system.
The task of the leader who nominates you for promotion is to conduct it competently. There should definitely not be situations where a promotion is unexpected for a person and / or for a team. As a rule, they are promoted at a time when everyone, including the team, understands who needs to be promoted and why. If there is a risk of conflict, you can go a more delicate way like v-team. On the other hand, after the increase, it’s better not to drive that “Yesterday we were colleagues, and now I’m the leader.” You need to accept yourself in a new role. It will be easier both for the team and for you.