A couple of years ago, inspired by an article about the “revolutionary system of working time management” by Artyom Gorbunov on the philosophy of organizing work processes introduced in the studio of the same name, I was puzzled by the question: how much human resource is needed for the unit to operate stably? It will be about the ideas and conclusions that I came to as a leader. The article will be useful to novice leaders and those who are just planning to become one.

What are you talking about?

In the concept introduced in the studio of Artyom Gorbunov, “Resource” as an idea, and “resource” as the main object of study, things are much more multifaceted, the issue that I touch on. But I want to dwell in more detail on the human resource.

Someone will say that these are completely different things, and will be partially right. But it is only partially, because the main object of the above concept is a person / employee.

After all, it was not in vain that the guys called the concept “Resource”, knowingly foreseeing associations with Human Resource .

Imagine the situation, a new group / department / project is being formed. Let the starting number of employees is two. What are the roles of these people? Even among two people there should be a subordination scheme, since one specific person should be responsible for the activities of the department. Thus, it turns out that one is a responsible person, and the second is an active person.



Let me explain, the first one is not directly responsible for the fact, he is responsible for the charter / regulation / rules. Those. he is responsible for the activities of the unit, but this does not mean that in all cases he will be 100% responsible. And on the second lies the task, first of all, of directly implementing the tasks of the department. The first, of course, too, should and can do the work "by hand", but to a much lesser extent.

Division formation

Two, three, four people work, the volume of tasks is growing, there is a need to increase productivity and, so to speak, the fault tolerance of the department. How will we decide: increasing the number of employees or increasing the productivity of current employees, or will we use both directions? The appearance of such questions is a normal stage in the development of any unit.



The answer, as a rule, is work in two directions at once: the number of employees is increasing and the quality of employees' skills, both current and new, is improving.

So what should be the size of the team? Who can’t do without a team?

For the formation of the department, it is necessary to form healthy competition in the department. One in which conflicts are minimal, productivity is maximum and growth prospects of an interested employee are clearly visible. Competition in an equal society is weak in nature - there is no guideline. Significant success / development cannot be achieved without an example ahead (good or bad).



We are not talking about competition between an ordinary specialist and a leading developer, the role of a leading developer is to enable those who are interested to develop faster. There is a reverse point, if a specialist does not strive for development, then there is no need to force him. It is necessary to find him a comfortable position / role / task. Perhaps this is the value of this employee.

Roles and Specialization

Develop roles in team members. Do not assign, namely develop! The initiative to have this or that role should come from the employee himself, albeit unconsciously.

Analyze which of the employees what he is doing besides fulfilling his direct duties.



Roles can be very different, from critic to the know-it-all, the most obvious is Team Lead. Employees of the role will be given the opportunity to understand "with whom on what issue you can consult." And the leader will be another "good" tool for self-organization of the team.

In addition to roles, it is possible and necessary to develop specializations in employees: any narrow areas that are insanely interesting to a particular employee. This skill is sometimes required to be applied in the department, but it is not necessary for all team members to have it.

Quantity or quality?

And now comes the moment when the department is formed, albeit in the minimum configuration, tasks are completed, hr'y from time to time offer new candidates.

There are reasonable questions: what kind of employees to look for, how to strengthen the team, how to provide redundancy, where to find resources for the technical development of the department?

Looking ahead, I’ll say that the conclusions I came to may not be suitable for your model. If your team consists only of professionals, or vice versa, if your model is "worked out" for junior wear, then the scheme is not for you.

Have you analyzed who in your team makes the most real product with a predetermined quality?

I hope that your answer is “ordinary specialist”. A young specialist cannot solve problems with the speed of an ordinary specialist, for many reasons: he studies, he asks many questions, he does not have the proper professional skills. Higher-level specialists: leading developers, technical leaders, more often deal with more global technical issues: architecture, tools, teach juniors, etc.

And the fact that young and leading experts make a real product smaller is the norm.

If otherwise, then most likely you have some difficulties in the team - everyone should be engaged, first of all, with their tasks.

The concept of "Bowls"

Frankly, I do not remember where did the term "bowl", whether at Gorbunova spied read, whether in the course of the discussion, the term was born, whether he came up with, ... it does not matter. The main thing is that the term clearly and fairly accurately reflects the concept.

Let's get down to business. We agree that the abscissa axis (x) is the conditional level of pumping of a specialist, and the ordinate axis (y) is the conditional number of employees at this level.

Imagine a department in which the majority of employees are juniors. Let's look at the "bowl" reflecting this situation.



We see a heavily overloaded left side. There are few specialists - the central part is not filled. This option is the most expensive in terms of management and testing. But cheap in terms of monthly labor costs. As for the total cost of development, it will directly depend on the quality of the code. And the scatter here can be significant. The development time with such a scheme is long.



The reverse situation, if the team is based on leading experts. It is one thing when the general / average level of an ordinary specialist is high, another when these specialists occupy high positions within a team / project. There are few specialists in the central part.

In this situation, the opportunities for vertical growth are very limited, motivation is falling, and employee dissatisfaction is growing, which must be compensated.

Yes, there are teams consisting of only bearded specialists, but in this case, the team should be beyond motivation for the product / company, etc. There must be a unifying factor that will be above everything. This atmosphere is more typical for startups than successful products.

We recall that the main real work is done by ordinary specialists. Let's look at the "bowl" in this case.



Please note that the total number of specialists in all schedules is the same. For clarity, we will demonstrate various situations in one image.



The bulk of the employees are ordinary specialists. Juniors and hosts are, but without excess. Juniors have room to grow, specialists have an environment for development (there is someone to teach, there is someone to learn from), the leaders have a sufficient area of ​​responsibility and control.

Appreciate the experts! They are the main strength of the unit.

A situation may arise in which there may be many young specialists; you will not be able to adequately manage a large number of juniors in the absence of employees with sufficient managerial skills. Similarly, there can be many cool developers, they may not have enough cool tasks.

And many specialists with experience in 2-3 years - this is happiness! More than half of the tasks, as a rule, are the current development and support of existing code. And for these tasks, your team needs a sufficient number of ordinary specialists.

I note that the probability of an employee leaving is maximized precisely at the edges of the bowl: the junior may get tired, understand that “it’s not mine”, or fail to pass the probationary period, and the reason for the leader’s departure may be to reach the development limit within this project / department / company.

Use and develop!