Work in teams or not?

The idea that it is better to work in a team, from the point of view of an ordinary developer, with teams, from the point of view of a project manager and operate with teams, from the point of view of organization arises quite often, but there is little adequate practical argumentation for these statements. Therefore, I want to fill this gap and try to prove the benefits of teams with reason.

I divide this article into four main advantages, which are clearly visible and indisputable, based on which you can begin a reasoned introduction of team work in the organization. In fact, the advantages are much greater and the work of describing them can help to create a whole series of books.

And one moment. An alternative model for building an organization, I will call the model of “lonely programmer”.

Team Cohesion

Let's start precisely with this advantage of teamwork, since any organization is primarily people, and how much they will feel part of something more and how much they will help each other depends on how much they will feel comfortable. overall organization performance.

Together - we are strength, alone - we are nobody. Working as a team, tasks of any complexity are completed faster, better and more fun than alone. And even if the question arises “is it not more expensive to use the team for the end customer?” I will answer with confidence - no. It was experimentally found that if you count the man-hours of a team and one programmer when working on the same task, the team will spend less. If you do not believe it, you can check it.

Working day after day with the same people, the employee gets closer to the team, thus gaining a sense of permanence in the workplace, which is so lacking in the model of “lonely programmer”, and which causes unnecessary stress at work. Of course, it will take some time to “grind” the characters, but it is not significant by comparison with the period after the “grind”.

In a team, a developer can always count on the support and help of a friend, while in the model of a “lonely programmer” you can never do this, because your friend can be frustrated at any time for additional tasks, a new project, etc.

A new employee joins the team easier, since he does not need to choose what tasks to start his work with and how to carry them out, the team will do it for him, so such a person will not have the opportunity to relax at the very start of his career and such an employee will be able to develop much faster .

Unity of thinking

It's no secret that different developers can solve the same problem in different ways, and probably each of the developers faced a situation where disputes over the solution scheme of the task take much more time than the implementation of such a solution. This situation easily excludes itself from the workflow when developers work for a long time with each other, in this case they will choose a single solution and will use it constantly, without wasting time on unnecessary disputes. And one more remark: the team’s decision is always more objective and optimal, therefore the product developed by the team works better.

And here is another situation that is quite common in the daily life of a developer: you urgently need to fix a part of the project that another developer was doing and you have no idea how to fix it. And what happens in the “lonely programmer” model? In the best case scenario, they explain to you on the fingers how to do it and where, in the worst case scenario, you yourself are looking for, losing a lot of time. This task is again self-excluded if the team uses common approaches in solving problems. The developer does not search or ask - he just does.

And the last one is a matter of communication. Having worked with the same people for a long period of time, the developer can convey his opinion in a nutshell and understand his colleagues with half a word, and this is so important in conditions of extreme reading on the project.

Unified Coding Standards

And how many disputes and resentments in your organization are devoted to poorly written code?
In the process of teamwork, developers begin not only to think the same way, but to write the same code, and even if you do not have common well-described coding standards, and there is no way to describe them in view of the large load, or the lack of initiator, the team will develop such standards in the process of "grinding", and will implicitly follow them and supplement them, because in vain no one wants to argue - this is a fact.

New employees will also be able to quickly understand and use these standards, in view of the presence of code with uniform formatting on all team projects and old employees actively training new ones, in view of the reluctance to rewrite someone else's code.

Resistance to external factors

Have you ever had such a thing that you need to finish something very urgently, but without a coder it is simply impossible to do, but it is not? I think that you understand this embarrassing feeling when the administrator of the web server is not in place at the most inopportune moment, but you need to fix htaccess. Or the frontend programmer got sick after an inappropriately updated application.
So, if you use the cross-functional team approach, then the above situations will not be able to stop the development and support of the application, but only slow it down a little. Indeed, in a closed society, which is a team, employees more actively share their knowledge and experience, developing each member of the team in their area of ​​specialization. As a result, after a while we get a team in which each of the employees can play different roles, and if necessary, replace a sick or absent colleague. Thus, the questions about highlighting the frontend of the developer or layout designer do not disappear on their own.
It is necessary to mention that the cross-functional team easily copes with several projects at the same time, and with a sufficient number of employees it easily develops and supports up to five projects. This is taken from personal experience, and you can check it if you want.

Centralized management

It is not difficult to keep track of the achievements and shortcomings in the employee’s work, while there are fewer than ten such employees, but when there are more of them, there are frequent cases that “a feat at work” or “a clear relaxation of the desire to work” will remain unnoticed. And the more staff the company - the more unnoticed people. It is a fact.

But if you transfer the level of responsibility from each employee to the team one, then the team will be the stimulator that will not allow the employee to relax. And it’s much easier to see achievements and shortcomings among several teams than among several dozen employees.
Thus, dividing a lot of employees into several teams - the work of the leadership becomes less time-consuming and the complex process of reward and punishment is greatly simplified.

conclusions

In our rapidly developing world, those who are more organized inside and flexible outside win, so I think that you should not disdain the means that make the organization even more organized and introduce teamwork at the level of ordinary employees. This post is not a guide for introducing teams, but only my thoughts on team work, so do not judge strictly.

Lastly, I want to recommend one wonderful video about the benefits of collectivism:



Try, demand, move and reach!