How to develop a development manager

When someone becomes a development manager, a huge number of new, unexpected tasks will surely fall on him, and adaptation will certainly take time. However, the adaptation period will end one day, and then the question will arise how to develop further. Equally relevant is the issue of preparing an employee for the future role of a manager. How to work with the developer to get the future leader out of it as soon as possible?

We have chosen the development paths of development managers with the theme of the next Team Leader Meetup , which will take place on the evening of November 28 in the Moscow office of Yandex. You can discuss this topic with experts from large IT companies. Registration is still open.

This time our experts are:

• Nikolay Krapivny, Head of Backend Development, Badoo
• Roman romas1982 Ivliev, CTO, mos.ru
• Alexander Polomodov, Head of Research and Development, Tinkoff.ru
• Boris Tobotras, Director of Software Solutions Center, Jet Infosystems
• Victor Lamburt, Head of Recommended Products, Yandex
• Igor Kuralenok, General Director, League of Experts

Today on Habré we ask them a series of questions to set the tone for the future discussion:

1. What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?
2. What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?
3. How much time should be given to work on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

Nikolay Krapivny , Head of Backend Development, Badoo

What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?

I would recommend to start:

• Understand what he is responsible for now and what are his main responsibilities as a team leader
• Coordinate with the leader of the main goals and objectives for him and his team
• Talk with team members, figure out how the team works now.
• View a delegation report and learn how to do it.
• Regularly allocate time to read articles, books, view reports on new areas of responsibility

What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?

For the head of development I recommend reading:

• How Google Works by Eric Schmidt
• "Work Rules" by Laszlo Bock
• "The Goal" by Eliyahu M. Goldratt

On a regular basis, I think that it is worth following the materials and performances with Teamlead Conf and other thematic meetings (for example, Badoo’s Timlide meetings )

There are also many useful links and discussions in the Telegram thematic channels: https://t.me/leadgr and https://t.me/TeamLeadTalks

How much time is worth working on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

I believe that there is no one right answer. The task of the lead is precisely in order to assess a specific situation and decide for itself how to allocate its time in order to achieve the maximum result.

In my ideal world, the less time a lead takes to manage a team (I include both technical and managerial functions in control) - the better. I believe that the key to success and further growth for the lead is to build a team that works effectively with minimal participation. In this scenario, the lead can and should invest the time freed up in the search for new useful ideas and projects outside the current area of ​​responsibility.

Roman Ivliev , CTO, mos.ru

What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?

1. It is time to download the soft-slip. Engineering is good, but now there are people with whom you have to work in a completely different manner. Engineering goes by the wayside. You can read, you can listen to lectures, you can all together. A lot of information on this topic does not happen.
2. Learn that you are no longer a developer. Coding will fade into the background. It will be breaking, but it is inevitable. Accordingly, you need to decide what technical work remains behind you, choose only the most important. Else start distributing to colleagues.
3. Urgently seek a replacement for your place. After all, once you became a lead, somewhere a hole formed instead of a good engineer, and she will remind herself in the first project :))
4. Immediately create your own mode. At first, everything is wildly not enough time, you need to devote more time to planning. And catch yourself on the fact that something is not going according to plan. The impulsiveness of decision-making will pursue the first time. Well, the desire to code everything :)
5. Immediately begin to build a map of communications and build relationships. At the lead level, the amount of communication is much greater, it would be better to immediately know what questions to contact.

What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?

There are a lot of good books, I’ll focus on the main ones, I think.

• Brooks "The mythical man-month, or How software systems are created" - it just needs to be read, because it is a classic.
• Tom DeMarco and Timothy Lister. "Human factor. Successful projects and teams ”- these guys are generally cool, they can be read in their entirety, which will come to hand. In addition to this, I would also note “Bald with adrenaline and zombie patterns. Patterns of behavior of project teams.
• Patrick Lensioni. “Five vices of the team. Proverbs about leadership. Patrick is cool, you can also read it as far as possible.
• Rainwater. "How to feed cats", but this work is an amateur. Among those with whom I happened to discuss this book, opinions were divided.

Be sure to have something about negotiations, about emotional intelligence and the ability to communicate with people. You can Gavin "You can agree on everything", Goulston "I hear you through and through," "Do not growl at the dog" from Karen Pryor.

With resources harder. I usually find interesting materials on Medium , Habré , GeekTimes , infoq.com , blogs of respected people like Joel Spolsky. I am subscribed to several management channels, where interesting links are constantly skipping, I watch them, and at the same time I study the resource where they are located. So you can find many not very well-known sites and blogs, but with very good content. You can read vc.ru , sending Megaplan sometimes throws up good materials.

How much time is worth working on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

Everything is very dependent on how the project is organized, the team, the company. I have met completely different proportions, but more often it’s something like 100% of the time for technical tasks and 46% of the time for management :))) It always ends equally badly. IMHO, in reality, the most correct proportion looks like this. Time for technical tasks is 100% minus time for team management. 100% is not 8 hours, if that. Everyone has their own 100%. In other words, the figure is floating.

It is imperative to spend time on self-education, expanding horizons in related areas (product and project management; if you are backend - poke the front, test, operate, well, and vice versa, of course), maintaining the technical form - new frameworks, libraries, all that one way or another concerns work. Otherwise there is a risk of losing credibility among engineers. You need to attend meetings and conferences in order to broaden your horizons and look for answers to your questions.

Alexander Polomodov , Head of Research and Development, Tinkoff.ru

What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?

Stop and answer the following questions:

• What is expected of me in the new post.
• Who and what roles now plays in the team:
  
  • Who is on the list of customers of the team (he is one or many)
  • Who will have to report
  • What employees are already in the team
  • Who will have to communicate horizontally (other development leads, infrastructure leads, testing, ...)
• What are the goals for the team and what are the expectations from the results of its activities

Further, taking into account the results of the answers to these questions, it is necessary to draw up a plan for whom to hand over old duties and how to accept new ones. It should be borne in mind that after the transition to the position of the communication team will be more, but the time to develop - less. It is very important to consider the success criteria, according to which you yourself and your manager will understand that you successfully cope with a new position.

If you go to the second question about concrete and understandable actions, I can say that there is no such list of understandable actions that universally fits all situations, which means you have to make such a list yourself, based on your situation.

What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?

I would single out the book Mythic Man-Month by Frederick Brooks. This is a classic about the problems of the team in large projects, in which the IBM project on the development of OS 360 was analyzed in detail. I also find books from Tom DeMarco very useful, especially the Human Factor and the Patterns of Conduct for Project Teams. And for a snack, I would advise the book "How to feed cats" by J. Hank Rainwater.

Among online resources, I read the flow Management on Habré and get acquainted with performances in management flows at major conferences such as RIT, Highload ++, Codefest and others.

One of my hobbies is developing in a broad sense of the word, including managing development teams. And I post my thoughts, impressions from the books I have read, the conferences I have attended, and my meetings on my Facebook page . Perhaps this page will be useful to you.

How much time is worth working on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

It is impossible to clearly say in what proportion to distribute the time between the technical tasks and the team, because This is highly dependent on the specific team and its tasks. In general, we can say that the solution of technical problems becomes secondary to the fact that the team worked effectively. In my opinion, a team should spend time on:

• work with external customers and act as a team interface for the outside world
• organization of the development process and rhythmic code delivery
• increasing the efficiency of team members - training and consulting colleagues
• interview of new guys with the growth of the team
• solving technical problems (writing code, review, ...)

Boris Tobotras , Director of Software Solutions Center, Jet Infosystems

What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?

I would say to him: Dear friend, you have a terrible interesting task: to include in your picture of the world not only technology, but also people, projects, and their complex relationships. This will allow you to solve qualitatively more complex tasks that the lead developer alone cannot solve. To do this, you need to learn to see not only what we do in our daily project work, but also why we do it, how and why.

Suppose that freshly baked timlide falls in this quality in a new project. You can start by getting answers to specific questions:

• How is the project on which the team works? What goal should it achieve, who and how will judge its achievement?
• Who is part of the team? What kind of people, what is their experience, specialization, features of their work?
• Who does the team interact with? What does the project expect from development, and what does it, in turn, expect from adjacent teams (analysts, QA, architects, sales force, engineering support)?
• Who does the team leader interact with? What does the project manager expect from him, what does the team expect from him, what do the adjacent teams wait for from him? What problems do they see in development?
• What is the status of the project? Where are we now, what has been done and what is left? Are we great or not, and why? What are the currently known problems in the project - technical, organizational, human?

What to do first?

• Get acquainted in detail with who is doing what and where.
• Disassemble the backlog, read the entire project tracker, look at the latest commits and reviews.
• Understand the project management methodology (code style, VCS / branches, builds, tracker workflow, supported versions, issued artifacts).
• Detailed understanding of the architecture of the developed system with its history (what decisions were made and why).

What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?

Brooks, The Mythical Man-Month. Nothing has changed over the past half century.
Alan, Colston, The Programmers' Stone.

How much time is worth working on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

There are hardly any recipes here. Well, let's take the lantern: 70% for equipment, 30% for people. But this proportion varies with the size of the team. If there are 15 people in a team (a monstrously many IMHO per one lead), the proportion is 5% / 95%.

Timlid, in addition to “internal” tasks (equipment + people), also decides “external”: managing the speed of development and the purchase of the project, together with the management plans to work in the project, predicts the employment of developers

Victor Lamburt , Head of Recommended Products, Yandex

What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?

First of all, I would advise you to find out what happened to the previous team leader and what your new leader expects from you. After that, talk to each member of the team, find out about their expectations and problems, and also try to understand their fears.

What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?

There are many of us in this interview and, for sure, my colleagues will name important books relating directly to development management. Therefore, I will seize the moment and mention three important books from completely seemingly other areas.

Ed Catmell. Corporation Geniuses. How to manage a team of creative people

The book is written by the founder of Pixar. Reading, one is amazed how wise, tactful and at the same time the author was. As he and a small team of like-minded people managed to reinvent the genre of animation, creating masterpieces that touch millions of children and adults around the world. As Ed Catmell established a dialogue with Steve Jobs, defending the team and using Steve's experience to the benefit of the growth of Pixar.

Telling the story of the birth of masterpieces, the author recalls that they were all at first extremely clumsy, like newborns. It cost nothing to crush them immediately after birth. And only patience, love and a huge number of iterations allowed ideas to get stronger and turn into Oscar-winning films.

And Ed tells how to create an atmosphere in which people openly express critical opinions, and those who are criticized are happy to use this opportunity to improve their creations.

That would be us so, right?

David Keirsey Please Understand Me II: Temperament, Character, Intelligence

In the second edition of David Keirsey systematically and visually tells about why people often do not act the way you expect. It turns out that people of the same profession, who are in the same socio-cultural context, can make decisions in completely different ways, appreciating completely different things. And this happens all the time, with the beloved, with the children, with the parents and, of course, in the development teams.

Despite some criticism, the MBTI typology helps to better understand people, streamline their actions, and build more balanced teams.

Daniel Kahneman. Think slowly ... Decide quickly

The founder of psychological economic theory is fascinating to talk about the cognitive distortions with which we live, without noticing them. The book is full of examples demonstrating that you and I are not damn rational and can be easily manipulated.

The book not only teaches to recognize such manipulations, but also makes one seriously think about whether it is worth doing this or that seemingly very rational redistribution of duties.

How much time is worth working on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

I must confess that I have not worked on truly technical tasks for a long time.

Igor Kuralenok , General Director, League of Experts

What advice would you give to your colleague - a strong developer who recently, just yesterday, became a team leader? From what specific, understandable actions should he begin his work in a new position?

• Start looking around. Notice what the people in the group do, how they do it, what makes them happy, what upsets them. Pay attention to all the nuances that make up the microclimate in the team, for which you are now responsible. Your knowledge of your boys and girls allows you to create synergy, and not interfere with each other.
• Stop writing code. In addition to two exceptions: when it determines the development vector or sets the fashion. The first is architectural solutions that set the tone for the design and allow it to keep its vector in the right direction. The second is those things that will stop doing everything if you stop doing: tests, branches, correct practices and other trifles that make everyone lazy, but without which everything falls apart.
• Do not try to correct all visible errors, starting life from scratch or introducing the process from the book. The views of the developer and the team leader are significantly different, and what appears to be harmful to you as a developer may turn out to be the nail on which everything hangs. Make changes slowly and consistently. Do not hurry, all have time.
• Give and delegate. Your task is not to do everything yourself, but to make the task done. Moreover, one of the very important motivators is responsibility. Having given her a piece in good hands, you will not only be less busy, but also motivate a member of your team. But, if you’ve already given, remember that you gave not only responsibility, but also delegated some decision-making powers.

What books or articles would you recommend to read to the development manager? And what resources does it make sense to study on a regular basis?

I once liked the work of Alistair Cockburn "Agile software development". I strongly recommend it. I strongly advise the practice of working with students: you prepare yourself cadres + you have to keep yourself in good shape, as toothy students do not allow to relax by asking tricky questions :)

How much time is worth working on technical tasks, and how much - on tasks related to team management? What else can or should the team lead their time?

As much as it is necessary for the group to cope with the tasks. If after a week of release, it is strange to be engaged in management, and if in a month one of the girls goes on maternity leave, it is strange to deal with technical tasks. Did everything happen at the same time? So you did little control :) Seriously, it all depends on the group and the tasks that are put before it, IMHO is not a universal recipe.

What else can or should the team lead their time?

• To advertise your people. The more your guys know other teams, the higher the group’s authority and understanding of what you are doing. The less people know what you do, the more they think that you are not doing anything :))
• Interaction with subcontractors (neighboring groups, for example). It seems to me that much more time is spent here than on technical tasks and management combined, but this essentially depends on the size of the company and the role of the group.
• On the planning of the development trajectory: both the whole group and individual people. If you cannot answer the classic question about “how do you imagine your role in 3 years” - this is not only your problem.
• On the search frames. Never stop searching for personnel, always keep 1-2 people in mind, even if you do not have an open position today.

The next meeting, which you can still register , will be held on November 28, 2018 in the Moscow office of Yandex. There you can ask questions to the speakers and share their experiences.