How I was a developer, and now Timlid

Now you will read the fascinating story of my transformation from a developer to a tmlid. It was a long journey with many steps back, which nevertheless ended with a confident step forward. Get comfortable, take popcorn ... Let's go!

First, a few words about me

My name is Vitaly Sharovatov. Now I am a team leader of 12 developers in the mobile web division in Badoo. I have been living in London for a year and a half. But in this position I ended up as a result of a rather long journey, the story of which I will describe further.

I am 32 years old, the general experience in the industry is almost 15 years. I started, like many, with freelancing. A lot and productively engaged in server programming, a little - system administration.

• I started programming with PHP 4, then there was PHP 5, wrote in C # for ASP.NET MVC and ASP.NET Web Forms, wrote in VBScript in ASP.
• He built several systems with IE ActiveX components that integrate client code with various devices (passport scanners, barcode scanners, label printers, and so on).
• He built a network uniting three geographically separated offices on D-Link's DFL with duplication of the channel and VPN.
• Administered by Exchange, Windows 2003 AD.

But most of all I loved client development.

RealRussia. 2007–2012

For the first time I became a team leader in RealRussia. This is a British company engaged in inbound tourism in Russia. At first, she was engaged only in organizing the receipt of Russian tourist and business visas for the British, but during my work, a ticket booking service for trains integrated with Express-3 and Russian Railways, a hotel booking service, and full-featured integrated Workflow backends were created. for maintenance of all processes.

In terms of my development, everything was happening quite standardly: I was the first developer hired by the company, and when the workload increased and I didn’t have enough time for everything, we began to hire people whom I interviewed and trained. As a result, I became a team leader.

I was lucky that the developer’s labor market at that time was filled with offers, and we were able to hire people who were very similar to me: they had the same attitude to work (responsibility and pro-activity), they were almost the same personal type ( I am quite energetic, and with heavy to lift colleagues I would be difficult to work together). Working in such a team was very simple, I did not see any kind of challenge in this.

Moreover, at that time I was not yet sure that I wanted to take up leadership. I was young enough and wanted to focus on working with JavaScript, so after a few years of working as a team leader in RealRussia, I moved from the city of Volzhsky (Volgograd region) to Moscow and got a job in Mail.Ru Group as a front-end developer.

Mail.Ru Group. 2012–2015

After leaving RealRussia, I wanted to find some highload project that would have enough technical and organizational challenges. As a result, I became a front-end developer in the project “My World”, where I was engaged in the usual product development, and after a while I was offered to work on the mobile version of the project.

Knowing that the growth trend of mobile content consumption has long been evident throughout the world, I, of course, agreed. My responsibilities were in the same classic product development. From an interesting technical point of view, at that time I conducted a study and implemented a full-fledged support of the site’s work in Opera Mini.

Gradually, the food load became more and more, and I was “overgrown” with two subordinates. However, I didn’t see any further growth opportunities in the project, and the atmosphere and management style did not quite fit me, the time for technical tasks was less, and there were no noticeable results in management.

It has always been important for me to see growth opportunities, take more responsibility and achieve results. Therefore, having passed the interview in Badoo, I again decided to give up management and go back a step - to the position of developer. I saw that in this company I could go further.

Badoo 2015 – our days

In Badoo, a culture of growth of employees within the company is very developed: Head of product grew from Paralegal over several years, CTO - from a developer, most Heads of departments also grew from developers. What to say about timblidov! I, like many other developers coming to the company, motivated by growth prospects and challenges, cannot but be inspired by an atmosphere where taking on more responsibility and productive work are encouraged.

As you can see, I have a rather extensive experience of growth from an ordinary developer to a tmlid, as well as a conscious rejection of this role.

And now I will share with you the unusual knowledge, feelings and experiences that I have received and experienced over the years. After all, I am not alone in my path: many developers at a certain stage of their career have to answer the question: “Should I become a team leader?”

I'll tell you what awaits you, if you decide. We start with the main features of the post timbl.

Special features

Feature number 1. You and one and not one

If you are an ordinary developer, then you are responsible only for your own actions and their consequences. But, becoming a team leader, you suddenly cease to be by itself. You are no longer a separate functional unit, but an integral one. But at the same time, only you alone represent your team in front of the leadership and other teams. You are the person in charge in all situations, from solving salary problems to technical issues.

Suddenly, the results of the work of the whole team become your own results. I felt very strange the first time, filling out my report on the results of the month and putting something like “made so many food features” into it, as if I personally did all this.

The same applies to problems. You can no longer say: “Oh, this is Sanya (Lech, Andryukha) made a bug!” No, now you are responsible for this bug, regardless of who wrote the code.

Is it a heavy burden, a challenge, or something that you would be able to take easily and naturally? Can you trust the people you work with?

Feature # 2. Uncertainty

When you are just a developer, you get used to several predictable sources of uncertainty. For example, bugs in the browser, strange behavior of the device. You usually know how to work with them, or at least you can somehow predict the risks. But, having become a timblid, you find yourself face to face with a new source of uncertainty: with people.

People are not robots, they can be sick, tired, lose motivation, be happy, angry, sad, they can conflict, forget something, can be very productive or vice versa. And since you are responsible for the team, you should at least maintain its performance. It is necessary to accept the fact that everything is simply impossible to control. It is especially difficult for a technician to recognize and accept this. It turns out that you are responsible for the result and problems, but you cannot control all the factors.

Feature number 3. All different

In RealRussia, all the members of my team were so similar to me that it seemed to me that in general everyone should be on the same wavelength with me in terms of approaches, motivation, psycho, attitude and willpower. I worked with each developer as if I were working with myself.

But in the conditions of the modern labor market, it is incredibly difficult to find developers who will be copies of the team leader, and interacting with different people in the same way is unproductive.

A trivial example: you can constantly pretty hard pushing towards the goal of one person (you can even set an unachievable goal in front of him), he will regard it as a challenge and will demonstrate maximum efficiency. However, applying this approach to a person of a different psychotype, you can lose a developer - he will be seriously demotivated by the fact that time is ticking and he cannot even come close to achieving the goal.

In general, I had to realize the need for an individual approach to each team member, depending not only on his psychological type, but also on the situation. Indeed, in conditions of uncertainty, people work in very different ways even within the framework of one project. By the way, this concept needs to be conveyed to each member of the team - at the horizontal level, communication also should not bring discomfort.

It is quite difficult to achieve goals together with people who are very different from each other, as you always have to find a balance between different motivations of people in order to move forward and be productive.

Another example as an illustration. The programmer always conducts a very thorough review of the code, sincerely loves to do the review “correctly”, spending several hours on analyzing the code in order to go into all the details. But as a team leader you know that for many tasks such thorough review is simply redundant. Will you try to change the approach of your employee, try to force him to stop doing his favorite work and thereby strike a blow to his motivation? Or would it be better to direct his efforts to review tickets, where his passion for such work will bring maximum benefit?

Feature №4. Lack of knowledge and experience

Having worked for some time with people, you realize that you need to develop empathy in yourself in order to understand their feelings, reaction to your words, to the words of others - to what is happening in and around the team. At a minimum, you need to filter a lot of what is happening to notice things that can harm the psychological atmosphere in a team.

Then you need to learn how to create this atmosphere, create a team spirit.

Congenital leaders, who have been gathering around and leading people since childhood, often form the team atmosphere intuitively, at the level of unconscious competence. Such a person, becoming a team leader, almost immediately will feel in his place. The rest will have to develop and develop leadership qualities, which is called, in the process: you will have to perform the functions of a team leader even in conditions of a clear lack of knowledge about management, no one will wait until you get an MBA.

When you start to read management literature, you are amazed at how “deep the rabbit hole” is: how little you know and how acute the problem is of mastering the necessary skills. And, given the huge amount of information on this topic, it is very difficult to understand where to start self-education.

I was lucky - Badoo helped me navigate among hundreds of thousands of sources of information about management and organized good training in the course of the theory of situational management. It is simple and extremely practical, I recommend to everyone - in the shortest possible time you will receive a minimum set of tools ready for use in the chaos of the first months of management experience.

Feature №5. Lack of time

You need to be prepared for the fact that there will never be enough time to do everything - there will always be something that needs to be done.

A new level of uncertainty always entails many new problems that need to be urgently addressed. Requests from other teams when something goes wrong, escalation of problems from developers, administrative issues, and so on.
Only the support of current development processes takes a lot of time. And the more people in the team - the more time: once in two weeks, individual meetings with each employee, kick-off-meetings and VQA, scheduling, retrospectives, monthly assessments.

I have 12 people in my team today, and if our developers were not so self-sufficient and responsible, I would not be able to support the work on the project, eat and sleep.

At some point, it comes to the realization that it is simply physically impossible to independently perform a significant part of the work, and the only way to survive is to delegate tasks. But with delegation two features are connected:

• Trust . You understand that your task for some reason may not be completed on time (or not at all). All of us are living people, developers may get sick, their productivity may decline, something else may happen. There is always a risk.

  
  
• Technical expertise . It is likely that in some matter you are stronger (or have more experience) than the developer to whom you set the task. But you can not do everything yourself, not only because of lack of time - delegating complex tasks to developers is necessary for their growth and development.

Can you accept the likelihood of failure due to human or technical factors? And if this happens, will you be demotivated, depressed, because someone let you down, or will you keep a positive attitude and try to find a way to improve the situation?

Feature №6. Distractions

Timlide is distracted all day - messengers, telephone, mail, people. Gradually, your brain becomes accustomed to this format of work, when you need to keep in mind a lot of things at the same time and, if necessary, quickly switch between them. This skill develops in the same way as all the other daily trained skills - comparing plans for the day of any day of this winter and the same day a year ago, I am amazed at the difference: now there are much more “heavy” tasks that can be managed during the day .

However, this skill in itself sometimes becomes a problem. Having become accustomed to frequent switching between cases, it becomes very difficult for the brain to focus on one thing when it is needed. Almost physical discomfort starts to be felt due to the fact that there is no need to switch attention, and you unconsciously begin to look for “interference” - social networks, news sites, instant messengers. When I have to focus on something for a long time, I use the Pomodoro technique - I focus completely for a while, and then allow myself to be distracted by something. In this way, psychological discomfort is removed from the fact that it was not possible to keep attention, distraction is in fact legitimized.

Due to distractions, at first it is even harder to plan your time, which can lead to work without rest and sleep. You think: “I'm just starting, so I have to be as productive as possible. I work for 11–14 hours a day to reach my goal faster, ”you work in this mode for a month, two, three, burn out, you fall ill for a few days, and then you re-enter this vicious cycle. I went through this and after several cycles of “processing -“ burnout ”- restoration - processing” noted that my productivity is decreasing more and more.

Therefore, it is necessary to realize that time is an irreplaceable resource, but permanent, but health is not only an irreplaceable resource, but also constantly decreasing. Accordingly, the priority is obvious - health.

You can start using time more productively by improving processes, delegating, working out the skills of switching between tasks, improving the quality of planning. If you set yourself the task of working for a reasonable amount of hours per day, then the only option would be to focus on competent time planning and prioritization. In this case, as a result of improved processes and productivity will inevitably improve.

Feature №7. Compromises

Because of the lack of time, one constantly has to make compromises, choose priorities and problems. There is a well-known method: sort tasks by urgency, importance and urgency + importance and act in accordance with the resulting lists. But what to do if even the “urgent + important” list is so large that it is impossible to deal with it within a reasonable time?

As you work on a project, prioritization becomes an almost intuitive action. But when you start, the pattern determination skills are not so developed yet, and you constantly consult with your colleagues about the choice of priorities. It takes a lot of time and effort, and sometimes it is difficult to find someone who can help with the prioritization of processes.

Before my intuition worked, I adhered to the simple criterion of the least of evils. Choosing from two tasks, I asked myself: what will the company / team lose if one of them is not fulfilled?

Finding a balance when setting priorities is a difficult task, an approach to which must be constantly reviewed. For example, there is one hour and two tasks: to talk heart to heart with a developer who is demotivated due to some kind of conflict, or help another employee fix a bug arising from millions of users. What can help in determining the priority? Many questions immediately arise: what is the atmosphere in the team? How resilient is a specific developer to conflict situations? how long can a solution to a problem with a developer's motivation wait? Is it possible for five minutes of conversation to postpone a heart-to-heart talk for tomorrow? What is the scale of the bug? Is there an expert in the field of such problems who could be delegated to assist the developer? Answers help to compare the importance of completely different tasks. And with management experience, the number of questions is growing, and for many of them, the answers are almost intuitive.

At the same time, it is very important to be mentally prepared for failures, take for granted that compromises will always have to be, and if something went wrong, you only need to analyze the failure and learn a lesson, constantly increasing the effectiveness of your system of intuitive recognition of priorities: wrong choice, just record the failure as a negative result. The main thing is not to be disheartened from the series “Oh, I screwed up, I am not doing well”. The one who does nothing is not mistaken.

Feature number 8. Company policy

The main goal of prioritization is to remain as efficient as possible in all conditions.

And one of the conditions with which the team leaders constantly face is the observance of the balance of interests of the company as a whole and of its team in particular. One has to constantly be an “umbrella”, a “filter”, an intermediary, be under pressure from all sides, but at the same time act exclusively in accordance with priorities.

In my practice, there was a situation: a very qualified and experienced QA engineer demanded that developers have too high quality code, but they did not argue with it, but implicitly corrected all the bugs, even those that could be fixed after deploying the features (or which were not it was necessary to touch). In this case, I needed to notice the problem, discuss and fix the quality standard with product managers and technical experts (developers of our team and other departments), work out rules for prioritizing bugs, fix the process of fixing bugs in accordance with priorities within the accepted quality standard, and continue to follow, so that “manifestations of character” (the QA-engineer was very persistent) did not interfere with the functioning of the designed process.

“Included” with the position of a timblid receives a very high level of responsibility for exercising control over the implementation of the strategy, over the course of processes and motivation. And acting in accordance with the chosen strategy, one must be ready to receive feedback, both positive and negative.

Feature number 9. You are responsible for everything

If the developer left the team, it is the fault of the team leader. If productivity in a team leaves much to be desired, this is the fault of the team leader. If one employee is rude to others, it is the Timlid fault. And if the team succeeds and everyone is happy, then it is success including team lead.

All this again leads us to the issue of taking risks and working in conditions of uncertainty. Difficult questions and problems will arise all the time. What if a company needs to cut costs? How to support the motivation and comfortable atmosphere in the team, if you have to dismiss several people who did not do anything wrong, were good team members and productive specialists?

Fortunately, I did not come across a reduction in expenses, but I had to lay off people. And it was hard, even if the person understood that he was not productive enough and did not want or could not learn what was necessary.

I think the only way to maintain a comfortable atmosphere and motivation in such situations is to maintain maximum transparency in everything, in all aspects of team management. If people trust the team leader as the only source of all important information, if they know that problems will always be solved rather than silenced, then it will be easier for them to accept even bad news.

results

Result number 1. Demotivation and motivation

I have encountered several types of demotivation, and you can also face them.

Due to lack of time, even managing a team will probably not be enough time to write code. Even if the command is quite small, the processes are debugged, and everything works like a clock, anyway, the team leader will not have as much programming time as before. There will be no time to experiment with new technologies. In general, I mean that developer skills will inevitably be lost.

For me, the key factor in making the final decision to become a team leader was a clear vision that the company does not have a ceiling of growth, and I will be given as much responsibility as I can and I want to take on (and be sure to achieve results). In such conditions, I want to work more and more productively, and demotivational factors do not in any way shift the scales in their favor.
Another demotivational thing that I encountered: all the processes are going so gradually that it will never be possible to improve everything in one sitting.

Motivation, trust and atmosphere in the team are built in stages, a lot of time is spent on obtaining personal technical expertise in a rapidly changing conditions and priorities. Developing processes that help a team develop a product faster also takes time. In my case, all the processes changed in parallel with my development as a team leader. But even if I had a clear idea in advance of the processes to which we came after a year of work, still these changes could not be applied right away - people find it difficult to accept the new, and phasing in such restructuring is sometimes simply necessary.

When you are a developer, your productivity is usually fairly easy to evaluate in the short term (even epic projects are broken down into assessed achievable milestones). But, having become a timblid, you have to think much more about the strategy and wait a long time for some noticeable results. This can be a problem if you are used to immediately see the fruits of your labor.

There are enough demotivating factors in the work of the team leader. But it is unlikely that people would become timlid if there was not something good.

The work of the team leader is ideal for people whose main motivation is to cope with challenges (to work on projects that require the interaction of many people, to cope with a large load, etc.). There are a lot of things in which you lack knowledge and experience that are impossible to control, but at the same time you need to maintain high productivity. In general, this job is the biggest challenge I have come across.

Full acceptance of the call, the willingness to take on more and more responsibility, to change yourself and help change subordinates, the desire to move forward large strategic projects. If this appeals to you, then the work of the Timlid is for you.

Finally, the last motivation that is not related to the challenge and development is the desire to be a role model for their colleagues. Developing, you inevitably choose for yourself a role model - in the family, at work, anywhere. If you have children, you know what a pleasure it is to encourage someone to grow, improve, and self-educate. It is difficult to describe in words the pleasure of being able to help someone become better and realize the results of their growth.

Result number 2. Victory

Despite the uncertainty and lack of everything and everything, thanks to motivation and its support with feedback, I want to achieve more and more victories in the role of team leader. For me, the main victory is to make the team happy and achieve a good result with it.

Sometimes timblids are too soft - and the team relaxes: everyone is happy, but for the company the result is almost zero. The other extreme is a totalitarian timblid, squeezing all the juice out of people and not thinking that such an approach destroys long-term motivation and that sooner or later people will start leaving the team because of this. In my opinion, the main task of the team leader is to find a balance between achieving results and maintaining a positive atmosphere in the team. Help people grow, tell them how to achieve better results in their work. Help them create something they will be proud of. Help them understand their value to the company. Help them enjoy their work and cover everything you think you need to cover up. Perhaps it all sounds a bit pompous, but without sincere concern for people it will not be possible to build a fully trusting relationship with subordinates.

Believe me, it is incredibly pleasant in response to such concern to receive positive feedback from all levels.

Conclusion and current achievements

More than a year has passed since I became a Badoo team leader. And here are the results of the mobile web team.

• The team has grown from four to 12 developers (only one developer left us for family reasons during this time), they all have a clear plan for growth and development within the team and the company.
• A year ago, we delivered on average one feature per week (sometimes less), now - up to ten features per week. In addition, we fix a bunch of bugs, began to be released once a day and more often (and earlier they were released once in one or two weeks), caught up with 200 product features, every day we release something without QA (and no, this does not mean poor quality features).
• The goal was to become an experimental platform - we quickly conduct important A / V testing, based on the results of which other teams choose which version of product manager ideas to implement.

We focus on people and transparency, help each other grow and increase productivity. We work a lot and have a lot of fun.

If you, despite all “but”, choose management and start with the role of team leader, I sincerely wish you good luck! Learn, develop, ask yourself every day: what could have been done better? what goes wrong? Be prepared for negative feedback and see it as a growth tool; be honest with yourself and co-workers, help them grow and grow; learn to find pleasure in building islands of order in a sea of ​​chaos and uncertainty - and everything will turn out. I hope my experience will be useful to you and, of course, I will be happy to answer any questions.

PS I can not take this opportunity to tell you about our vacancies! Come (move) to work in our London office.

iOS developer: [description]
Android developer: [description]