How to create successful teams and manage them

I welcome everyone again! As promised, I continue to write about management in IT. In the last article I talked about finding and hiring new players in the team. But no matter how cool and talented people they are, they are not yet a team. You can draw a parallel with football: you can buy superplayers and release them on the field, but they will not be a team and the match is likely to lose, since they do not have tactics and strategy.

How to solve business problems when you hired a team of intelligent specialists?

Goals, objectives and tactics

Even before hiring new employees, you must clearly define your goals. Creating a new service requires certain technologies, and they, in turn, require the competence of specialists. That is, the ability of hired engineers must meet the objectives. It makes no sense to keep a staff of specialists whose potential overlaps with the tasks, someone can simply remain idle, and this is very irrational and fundamentally contrary to the principles of business.
')
Therefore, start with analytics and make a work plan in which all functions, competencies and areas of responsibility will be described. Do not take the time to do this, sleep with ideas and act. Believe me, this time will more than pay off in the future.

Teams and why they are not effective

What is a team? We can formulate such a definition: a group of persons united by motives and interests to achieve a common goal. It sounds great, but in practice there are problems.

• The ability to understand each other and speak the same language. We are all different and we perceive everything differently, we can only accept this, so man is arranged. Everyone has their own perception of the world. You ask to write down some feature, for example, uploading to Excel from a table, and you get something different at the output. And the task seems to be simple, but some kind of nonsense at the exit. Experience and ways of thinking are different for everyone, and it’s far from a fact that the other person means the same thing as you. There is an interesting quiz on this topic, try to give it to colleagues.
• The ability to speak. The usual situation: comes across a difficult task, you need to find the optimal solution. You gather colleagues and propose to discuss the solution. Well, if someone speaks, and it happens that people have nothing to offer. They are just waiting for a specific task, as they are told, so they will write. They simply do not understand or see how they can help.
• Motivation and interests. Are you sure that they match the TL and the teams? You have the motivation to make the features work and be made on time. And the team members want to introduce a new language or try to make a cool architectural solution for all occasions when the feature is needed here and now.
• Hear and listen. Often, engineers at meetings do not understand at all why they were pulled out, and they do not even listen.
• Involvement in the process. It happens that programmers simply solve certain problems, but they do not understand their ultimate meaning for the project as a whole. For example, you need to add a button, but they don’t understand why, they just blindly write code to close the ticket.

The result is that this is a group of individuals who do not understand what they are doing and why. It seems to be moving somewhere, and so it will come down. Everyone has their own motivations and goals. Although it is called a team, but in fact it is not.

When creating a team and establishing processes within it, it is necessary first of all to deal with the problems listed above. Of course, other difficulties will be waiting for you, but these must be overcome first.

How to unite people

The main task of the leader, from team lead to CTO, is to minimize the influence of all negative and distracting factors and to achieve maximum team productivity.

I believe that the key process in a good team is communication. Below I will list the basic principles and tips for improving communication.

• Sit down and chat with each employee, ask about skills and experience. Try to find the strengths and weaknesses of colleagues. You need to continue to make people complement each other, using their strengths in their work. This is the only way to achieve maximum efficiency in the end.
• Deliver to the team goals of work. If any functionality is implemented, then everyone should understand its original meaning. For example, integration with partners is needed to expand the range and increase sales, and hence the company's profits. Tell the team about the ultimate essence of the features, so people will understand the real goal and perform tasks more eagerly.
• Explain everything in simple words, so that everyone understands, and he had no doubts. As Einstein said: “If you can’t explain it simply, it means you don’t understand it to the end.”
• Get people involved in the discussion. For example, if the sales department has some kind of problem, then you can ask the team what they think about this. At first no one will speak out, but no one bothers to take the first step and start a conversation. Gradually engage the team in discussions. And it is important that every engineer understands that they listen to his opinion. Somehow we made the integration of our internal system with other logistics services. And they thought they were comfortable. But when they sat down to arrange the logistics for customers, they realized that it was inconvenient to use, send data, view statuses and so on. So we identified the problems, the guys were very enthusiastic and began to solve the problem, as if it was their pain.
• Forget the word "mistake." Show that a mistake or failure is a search for a new solution. All team members should understand that this is a normal workflow. The one who does nothing is not mistaken. Everyone learned to ride a bike, I do not think that someone managed to go without ever falling.
• Learn to criticize only in the case. You can not say that everything is bad, and your solution is no good. Argumentally and without a negative, explain why a particular solution does not work, and suggest alternatives.
• Speak the same language. Discuss tasks and ask for a summary. One of the useful practices is to ask the engineer to tell about the solution of the problem and how he understood everything. There may be many discoveries for you: sometimes what they understood is very different from what you said. It is better to spend time on discussion than to discover with surprise the result of the task performed, which is completely inconsistent with what was intended.
• Be able to anticipate and teach this to your colleagues. This refers to errors. It is necessary that people themselves come up and talk about difficulties or failures in the process, and not at the end of the sprint. Communicate that it is important to find the optimal solution, and not just close a specific task. In the future, this will probably affect something that will be important from an architectural point of view. Therefore, it is better to do it right, even if it can take more time. Each team member should have a habit of thinking forward a few steps, and not stick a crutch, because the deadlines are burning.
• Discuss tasks with the team, not with your executive colleagues alone. First, it will involve them in the process, and secondly, they can offer really good solutions that you yourself have not guessed. And remember, a good programmer is not a translator of logic into code, but one who solves a problem entirely. Programming is partly creativity, so give the team the freedom to do this. Such an approach will again and again give you really elegant and competent decisions.
• Create a bail-out room. You should have a place where you can talk to any employee and find out what problems he has in his work, what happens and what doesn't. It is important that you listen to the person, and he understood that. Thus it is possible to identify the reasons for the lack of effectiveness of its work. For example, he may have incorrectly set tasks, or just a chair falling apart. Systematically communicate with colleagues, keep abreast of the life of the team. So you can prevent conflicts and smooth the workflow. If everyone silently coded and does not communicate with anyone, then the team of the problem - there is no communication.
• Say thank you. If people do something well, be sure to thank them. This trifle is very important, everyone is pleased when you are appreciated. But do not abuse, and then thanks will quickly depreciate.
• Tell about the achievements of the company. The team or specific people should be aware of their contribution to the common cause. It's great when programmers get feedback on success from other departments. For example, a marketer can tell about the increase in sales after the site has been improved or the manager about the optimization of the service, which has accelerated his work. This raises the morale of the team. Good practice when from time to time the CTO or even the CEO gathers ordinary employees and reports on achievements.

As you can see, most of the tips are somehow related to communication. If it is not properly built in the team from the very beginning, then there will be problems. That it largely determines the effectiveness of engineers. Believe my experience, it is better not to regret time and energy for this immediately than to clear up the problems.

Management subtleties

Somehow I read entertaining theories about the optimal team size. George Miller was engaged in the study of memory and as a result of experiments he was able to conclude that in the short-term memory of a person usually 5 to 9 incoherent elements fit. That is, a person does not need to group them according to some principles and characteristics in order to make it easier to remember. Jeff Sazurland, the father of Scrum, who repeated Toyota’s success, believes that the team should have no more than 7 people, from which the “7 people for one project” rule emerged. In his opinion, only such teams achieve the effect of hyper-productivity, they can be 8 times more effective!

I was surprised, but these theories worked. I had one team of 12-13 people, I divided it into two, and, oh, a miracle, the productivity grew noticeably. With the growth of programmers, I created a third team of 6 people.

Below I will give tips on managing the team, they have nothing new in them, but they helped me a lot in their time, and I myself became convinced of their usefulness in practice.

• Mix and match teams to grow. One of my early mistakes was to distribute my colleagues into two teams by level: in one I gathered strong programmers, and in the other less experienced ones. After shuffling, productivity increased. And everyone began to develop more intensively: newcomers gained technical experience, and strong engineers tried themselves as mentors.
• Learn to correctly distribute tasks. A programmer is an employee dear to a company. There must always be a challenge before him. Let's get the task a little harder than it can solve at once. This will help him grow. An experienced senior should not sit on light tasks, even if he makes them faster than a novice specialist. Do not hammer nails with a microscope! Of course, tasks of the required level of difficulty are difficult to select, so keep balance and combine with routine ones.
• Correctly motivate employees. Here an individual approach is needed: for one it is money, for the other - career growth, the third wants to become a super-professional so that everyone comes to him for advice. That is, give them what you really need. It will work longer and more efficiently than some sort of distribution list, which is lowered from above to the authorities. In addition, it is easier to keep a balance between what the company and the employee need.
• Comfortable work schedule. I have long struggled with the bosses for a flexible schedule, but in the end I proved its advantage in numbers. We agreed with the team about the hours of presence, while everyone could come at a convenient time for themselves, leave on business, when it was necessary.
• Do not try to control every step. People need to be aware of their responsibility. The person who understands this is much more efficient and independent.
• Do not save on training. Send colleagues to conferences, workshops and other events. Expensive? Arrange them yourself in an informal setting with a cup of tea and pizza. Let people share experiences, talk about new approaches, or solve some tricky tasks together.
• Driving without driving. In my opinion - this is aerobatics. It is easy to give out direct instructions, but will the team lead for long enough to control each step of the team? In a good team, a manager is the same person in the department as the others. Only he does not think about specific tasks, but about the development of the company. From time to time he reports problems or new areas of work, and the rest lash onto them and decide. In my opinion, this is the most effective approach to management, only for this, a good team should already be built and all processes in it should be debugged.

Amazing fact

At some point, the cart you are pushing should go by itself. In a good team, when problems arise or when designing new features, people should sit down themselves and discuss possible solutions, suggest their own options. Ideally, they generally can cope without you.



In a real team, employees become more responsible, they well understand goals and objectives and the general direction of development. It's like rowers in a boat, they make synchronous movements, pushing the boat to victory. And then they themselves will start coming to you with their ideas on how to improve or optimize something. They will begin to see the problems themselves, and moreover, they will have a desire to solve them themselves. In such an atmosphere, attitudes towards routine tasks that nobody previously wanted to take will change; they will be solved with enthusiasm and quality.

Once I went on vacation and from there I wrote to my colleagues and asked about work, while they waved off and advised me to rest and not think about work. The biggest discovery awaited me after my arrival: the work was in full swing, as before, the tasks were surrendered on time, all the problems that arose were solved by colleagues without my participation. It was then that I realized that this is already a real team.

findings

A high-performance team is a team that learns from mistakes, grows, and can quickly correct or predict these mistakes. In it, everyone hears and listens to each other and always comes to the rescue. A team is like a living organism that develops. There are good decisions, there are not very good ones, but if the whole team moves towards them and constantly improves something, everyone individually will also strive towards this.

People who understand the purpose of the features they write are more motivated and can offer solutions to problems that others will not see.

Be sure to engage in building development processes in a team and pay maximum attention to communication. I believe that a team lead is enough to code 10–20% of the time, everything else is processes and people.

People are your most important resource, treat them the way you want them to be relevant. Create the conditions for them to develop and grow.

I left the company I was building from scratch; for more than half a year everything is moving and developing, and the profit is growing. I left with a clear conscience, at that time I already understood that everything was done and built correctly at the company. That is, a handful of engineers could grow into a full-fledged and independent team, each grew as a specialist. Work is boiling, business is developing, is this not the best proof of the effectiveness of the approach? And the question may arise: “Why, then, is a manager needed at all?” It is to build such an effective team.

Thanks for attention! In the next article I will talk about the nuances of entering a new employee into the team.

My other IT management articles:
What is to be a Team Leader
Dream team from nothing: hiring IT specialists