How to create and manage successful teams

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

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

Goals, objectives and tactics

Before hiring new employees, you must clearly define your goals. Creating a new service requires certain technologies, and they, in turn, require specialist competencies. That is, the abilities of hired engineers must meet the challenges. It makes no sense to keep a staff of specialists whose potential greatly overlaps tasks, someone just might be left idle, and this is very irrational and fundamentally contrary to the principles of business.

Therefore, start with analytics and draw up a work plan that will describe all the functions, competencies and areas of responsibility. Take the time to do this, get some 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? You can formulate this definition: a group of people united by motives and interests to achieve a common goal. Sounds great, but there are problems in practice.

• The ability to understand each other and speak the same language. We are all different and perceive everything differently, we can only come to terms with this, that's how a person works. Each has its own worldview. You ask to gag some feature, for example, unloading in Excel from a table, but the output is completely wrong. And it seems to be a simple task, but some kind of nonsense on the way out. Everyone’s experience and ways of thinking are different, and it’s far from the fact that the other person implies the same thing as you. There is an entertaining test on this topic, try to give it to colleagues.
• Ability to speak. Usual situation: a difficult task comes across, it is necessary to find the optimal solution. You gather colleagues and suggest discussing a solution. Well, if someone speaks out, but it happens that people have nothing to offer. They just wait for a specific task, as they are told, they will write. They simply do not understand or do not see how they can help.
• Motivation and interests. Are you sure that they coincide with TL and the team? You have motivation to make features work and be done on time. And the team members want to introduce a new language or try to make a cool architectural solution for all occasions when a feature is needed here and now.
• Hear and listen. Often, engineers at meetings completely do not understand why they were pulled out, and do not even listen.
• Involvement in the process. It happens that programmers simply solve certain tasks, 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 the code to close the ticket.

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

When creating a team and establishing processes within it, you must first deal with the problems listed above. Of course, other difficulties will await you, but these must be defeated 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 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 establishing communication.

• Sit and chat with each employee, ask about skills and experience. Try to find the strengths and weaknesses of colleagues. You need to further ensure that people complement each other, using their strengths in their work. This is the only way to achieve maximum efficiency in the end.
• Bring work goals to the team. If some kind of functionality is implemented, then everyone should understand its original meaning. For example, integration with partners is needed to expand the assortment and increase sales, and therefore the company's profits. Tell the team about the ultimate essence of the features, so people will understand the real goal and complete tasks more willingly.
• Explain everything in simple words so that everyone understands, and he has no doubts. As Einstein said: “If you can’t explain it simply, then you yourself don’t understand it to the end.”
• Get people involved in the discussion. For example, if the sales department has a problem, then you can ask the team what they think about this. At first, no one can 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 are listening 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 more. So we identified the problems, the guys were very carried away and began to solve the problem, as if it was their pain.
• Forget the word "mistake." Show that error or failure is the search for a new solution. All team members must understand that this is a normal workflow. The one who does nothing is not mistaken. Everyone learned to ride a bicycle, I don’t think that someone managed to ride without ever falling.
• Learn to criticize only in the case. You can’t say that everything is bad, and your decision is no good. Explain reasonably and without negativity why a particular solution will not work, and suggest alternatives.
• Speak the same language. Discuss tasks and ask for a summary. One of the good practices is to ask the engineer to talk about the solution to 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 discussing than later with surprise to discover the result of a completed task, which is completely inconsistent with the plan.
• Learn to preempt and teach this to 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. Report that it is important to find the best solution, not just close a specific task. In the future, this will probably affect something, it will be important from an architectural point of view. Therefore, it is better to do it right away, even if it can take more time. Each team member should have the habit of thinking ahead a few steps, and not stick a crutch, because the deadlines are on.
• Discuss tasks with the team, not with fellow executives in private. Firstly, it will involve them in the process, and secondly, they can offer really good solutions that you yourself haven’t guessed. And remember, a good programmer is not a translator of logic into code, but one who completely solves the problem. Programming is partly creativity, so give the team the freedom to do it. Such an approach will again and again give you truly elegant and competent solutions.
• Create a help room. You should have a place where you can talk with any employee and find out what problems he has in his work, what works and what doesn’t. It is important that you listen to the person, and he understands this. Thus, it is possible to identify the reasons for the lack of effectiveness of its work. For example, his tasks may be set incorrectly, or the chair may simply fall apart. Communicate with colleagues systematically, keep your finger on the pulse of the team’s life. So you can prevent conflict situations and smooth the workflow. If everyone silently codes and does not communicate with anyone, then the team has problems - there is no communication.
• Say thank you. If people are doing something well, be sure to thank them. This little thing is very important, everyone is pleased when they value you. But do not abuse, otherwise gratitude will quickly devalue.
• Talk about the achievements of the company. A 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 talk about increasing sales after the site is refined, or a manager about optimizing a service that accelerated its work. This raises the morale of the team. It’s good practice when from time to time CTO or even the CEO collects rank-and-file employees and reports on achievements.

As you can see, most of the tips are somehow related to communication. If it is not competently built in a team from the very beginning, then there will be problems. It is she who largely determines the effectiveness of engineers. Believe my experience, it’s better not to take the time and effort to do this right away than to dissolve the problems later.

Subtleties of control

Somehow I read entertaining theories about the optimal team size. George Miller was engaged in memory research and, as a result of experiments, was able to conclude that from 5 to 9 incoherent elements usually fit in short-term human memory. 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 the success of Toyota, believes that the team should have no more than 7 people, which resulted in the rule "7 people for one project." In his opinion, only such teams achieve the effect of hyperproductivity, 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, lo and behold, productivity increased markedly. With the growing staff of programmers, I created a third team of 6 people.

Below I will give advice on managing the team, they are nothing new, but they helped me a lot at the time, and I myself was convinced of their usefulness in practice.

• Combine teams so that they have where to grow. One of my early mistakes was to divide my colleagues into two teams by level: in one I gathered strong programmers, and in the other less experienced. 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 the company. Before him there must always be a challenge. Let's get things a little more complicated than he can solve right away. This will help him grow. An experienced senior should not sit over easy tasks, even if he makes them faster than a novice specialist. Do not hammer in nails with a microscope! Of course, tasks of the required level of difficulty are difficult to select, so keep a balance and combine with routine ones.
• Motivate employees correctly. An individual approach is needed here: 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 they really need. This will work longer and more efficiently than some kind of order issued from above from the authorities. In addition, it is easier to strike a balance between what the company and the employee need.
• Comfortable work schedule. For a long time I struggled with the authorities for a flexible schedule, but in the end I proved his advantage in numbers. We agreed with the team about the hours of presence, while everyone could come at a convenient time for themselves, to go away on business when necessary.
• Do not try to control every step. People must be aware of their responsibility. A 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 problems together.
• Driving without driving. In my opinion, this is aerobatics. It’s easy to give direct directions, but for how long will the lead team that controls every step of the team last? In a good team, the head is the same employee of the department as the rest. Only he thinks not about specific tasks, but about the development of the company. From time to time, he reports problems or new directions of work, and the rest pounce on them and decide. In my opinion, this is the most effective management approach, only for this a good team should already be built and all processes in it should be debugged.

Surprising but true

At some point, the cart you are pushing must go on its own. In a good team, when problems arise or when designing new features, people should sit down and discuss possible solutions, propose their own options. Ideally, they can do without you.



In a real team, employees become more responsible, they well understand the 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 begin to come 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, the attitude to routine tasks that no one wanted to take before will change, they will be solved with enthusiasm and quality.

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

conclusions

A highly effective team is a team that learns from mistakes, grows, and knows how to quickly correct or predict these errors. In it, everyone hears and listens to each other and always comes to the rescue. A team is like a living organism that is developing. There are good solutions, there are not very good ones, but if the whole team moves towards them and constantly improves something, each individually will also strive for this.

People who understand the purpose of the features that they write are more motivated and may 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 team lead is enough to encode 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 conditions for them to develop and grow.

I left the company that I built from scratch, for more than six months everything has been moving and developing there, and profit is growing. He left with a clear conscience, at that time I already realized that everything was done and built correctly in the company. That is, a handful of engineers were able to grow into a full-fledged and independent team, each grew up as a specialist. Work is in full swing, business is developing, is this not the best evidence of the effectiveness of the approach? And the question may arise: “Why then do you need a manager?” It was in order to build such an effective team.

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

My other IT management articles:
What is it like to be a Team Leader
Dream team from nothing: hiring IT professionals
A new employee - dead or alive
Grow, Team Leader, big and small