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 an organization, arises quite often, but there is little adequate practical argumentation to these statements. Therefore, I want to fill this gap and try to convincingly prove the benefits of commands.

I divide this article into four main advantages, which are clearly visible and of little indisputable, based on which one can begin a reasoned introduction of team work in an organization. In fact, the benefits are much greater, and the work of describing them can help to create a whole series of books.
')
And one moment. I will call the alternative organization building model the “lonely programmer” model.

Team cohesion

We will start with this advantage of teamwork, since any organization is first of all people, and how much they feel comfortable, how much they feel part of something bigger and how much they help each other depends overall performance of the whole organization.

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

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

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

The new employee joins the team more easily, since he doesn’t need to choose which tasks to start his work with or how to perform them, the team will do it for him, accordingly 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 is not a secret for anybody that different developers can solve the same task in different ways, and probably each of the developers has come up against a situation where disputes over a problem solving scheme take much longer than the implementation of such a solution itself. This situation is easily excluded from the workflow, when developers work with each other for a long time, in such a case they will choose a single solution and will use it constantly, without losing time on unnecessary disputes. And one more note: the decision of the team is always more objective and optimal, therefore the product developed by the team works better.

And here is another situation that occurs quite often in the developer’s daily life: you urgently need to tweak a part of the project that another developer did and you don’t have a clue how to fix it. And what happens in the “lonely programmer” model? At best, they explain to you on your fingers how to do this and where, at worst, you are looking for yourself, losing a large amount of time. This task is again self-excluded if the team uses common approaches to solving problems. The developer does not search and does not ask - he just does.

And the last is a question of communication. Having worked with the same people a large period of time, the developer can convey his opinion in two words and understand his colleagues from the floor of the word, and this is so important in the conditions of extreme situation on the project.

Uniform Coding Standards

And how many disputes and resentments in your organization are dedicated to poorly written code?
In the course of team work, developers begin not only to think the same way, but also to write the same code, and even if you do not have the same well-described coding standards, and there is no possibility to describe them because of a large load, or the absence of an initiator, the team will work out such standards in the process of “lapping”, and they will unconditionally follow them and supplement them, because no one wants to argue in vain - 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 projects of the team and old employees who are actively teaching new ones, in view of their unwillingness to rewrite someone else's code.

Resistance to external factors

Have you ever had such that it is very urgent to complete some thing, but without a layout designer it is simply impossible to do it, but it isn’t? I think that you understand this awkward feeling when the administrator of the web server is not in place at the most inopportune moment, but you need to correct htaccess. Or, the frontend programmer fell ill after unannounced update of the application.
So, if you use the cross-functional team approach, then the situations described above will not be able to stop the process of developing and supporting the application, but only slow it down a little. Indeed, in a closed society, which is a team, employees are more actively sharing their knowledge and experience, developing each team member in their field of specialization. As a result, after some time we get a team in which each of the employees can perform different roles and, if necessary, replace the sick or missing coleg. Thus, questions about the allocation of a frontend developer or layout designer disappear by themselves.
It is necessary to mention that the cross-functional team easily handles 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 out if you want.

Centralized management

It is not difficult to keep track of achievements and shortcomings in an employee’s work, as long as there are less than ten such employees, but when there are more of them, it is not uncommon that the “feat at work” or “obvious relief of the desire to work” will remain unnoticed. And the more the staff of the company - the more unnoticed people. It is a fact.

But if you transfer the level of responsibility from each employee to the team - then the team will be the stimulator that will not allow the employee to relax. And it is much easier to see the achievements and shortcomings among several teams than among several dozen employees.
Thus, dividing many employees into several teams - the work of management becomes less laborious and the difficult process of reward and punishment - is greatly simplified.

findings

In our rapidly developing world, winners are those who are more organized internally and flexible from the outside, so I think that we should not disdain with the means that make an organization even more organized and introduce teamwork at the level of ordinary employees. This post is not a guide to the introduction of commands, but only my thoughts on teamwork, so do not judge strictly.

Lastly, I would like to recommend one remarkable video about the advantage of collectivism:



Try, demand move and reach!