How to graze cattle. Tips for the development manager

Published on March 16, 2017

How to graze cattle. Tips for the development manager

In addition to the eternal problem of fathers and children, in my opinion, there is another problem - subordinates and leaders. It is about this problem that I would like to talk about in my article. More precisely, about such a special case as the relationship of subordinates and managers in the development of software, design and technological documentation. Leaders often consider subordinates to be irresponsible slobs, and subordinates of leaders are incompetent shepherds who need to graze herds, and not command the development unit. Often the situation is compounded by misunderstanding, as the head does not understand the development, and the subordinate does not understand the administrative nuances. This article is designed to help bad leaders become good leaders. You, of course, say: “Hey, take it easy, what other bad leaders?” And you will probably right, I am greatly exaggerating. Not very bad. Ordinary leaders, of which hundreds and thousands. But in order to build a high-quality development process, we need the best specialists - both performers and managers. Therefore, I divide the leaders into good and not good. Without halftones. Like developers, by the way, this is mentioned in the last tip. How to understand whether you are a good leader or a bad one? Read the rules below. If some of them seem nonsense to you and indulging loafers - then the article is written for you. this is said in the last council. How to understand whether you are a good leader or a bad one? Read the rules below. If some of them seem nonsense to you and indulging loafers - then the article is written for you. this is said in the last council. How to understand whether you are a good leader or a bad one? Read the rules below. If some of them seem nonsense to you and indulging loafers - then the article is written for you.
So, the rules:

Rule one - in order to manage the development well, you must be a developer.

This rule is unshakable. Development is a complex process, and only someone who knows this process from the inside can competently manage it. No other is given. If you have never developed complex systems, you cannot manage the quality of development. In this case, you can lead the developers. But to create a product you have to select competent people whose work you will provide. I knew many leaders who completely shifted technical questions to subordinates, admired people who knew how to make equipment, and asked only two questions: “When will it be ready?” And “What is needed for work?”. This is a great leadership style for the layman. There is only one pitfall - personnel policy. A mistake in the personnel policy may result in the disruption of the project and the loss of position. If you’re lucky with the frames, it remains only to ensure their work. About how to provide it - read the following rules.

Правило второе — каждый разработчик должен заниматься только своей работой, а если говорить точнее — только принятием технических решений.

If he is a programmer, he must write a program. If this is an electronic engineer, he must draw circuits. He should not write memos, submit lists for the purchase, etc. He should only make technical decisions in the field of his competence, and do it perfectly. The same applies to programming and design. Great temptation to use a specialist for something else. But in this case, you provoke procrastination in him and are guaranteed to reduce his productivity and qualifications. It takes up to 2 days to switch between different tasks if the developer is optimistic and does not become discouraged by the fact that he was torn from an unfinished task. A normal person loses time before switching between tasks. And in the opposite direction again loses this week.

Правило третье — при разработке сложного продукта необходима иерархия принятия технических решений.

A sophisticated product requires top-notch professionals. But all the experts are different. And there are few good ones. And they are expensive. Therefore, a hierarchy is needed in development. There should be a systems architect who almost does not directly engage in development, but poses specific tasks to the performers. This is an upscale specialist who is expensive. Perhaps it costs more than some executives. And certainly for the enterprise it is more valuable than many managers. There should be several (from one to infinity, depending on the complexity of the project) super-executors. These are highly qualified specialists who have an idea of ​​the structure of the project, and can perform the functions of an architect. They develop the most critical parts of the system. Ordinary developers are also needed. They do the usual work under the guidance of an architect and super-executors, they are easy to replace, their salary is quite ordinary. They do what is called a routine. For the design of text technical documentation required technical writers. To purchase supplies, you need a secretary or assistant manager. These functions can be performed by a manager if he is not a technical specialist and is not directly involved in product development. As in the joke: "feed the dogs and do not touch anything."

Правило четвертое — не ставьте одному специалисту разнородные задачи.

Within the framework of one project, a developer must be either only a programmer, or only an architect of one or several subsystems, or only an electronics engineer. He must do one thing, and bring it to perfection. It is impossible to combine the development of complex systems of various kinds at the same time. Moreover, you should not use one specialist for tasks such as programming and electronics at the same time. Occasionally, electronics engineers are able to program, designers - to make electrical circuits. This should not be considered the norm - this is a deviation. If a person is interested, he can combine two professions for some time, but sooner or later this leads to fatigue and greatly reduces labor productivity. Therefore, if you want to get a good job, forget about the "universal specialists." This is utopia.

Rule fifth - not every mistake is a catastrophe.

In the process of developing programs and devices there will always be errors. We are only human beings and we are too imperfect. Everyone is mistaken. Any good techie knows this. It is for this that there are development stages with prototyping, testing, prototypes, and so on. An indicator of poor work is only the statistics of errors and their level (there are children's errors, but there are phenomena by which you can write a dissertation). The problem is that the manager, who is not a technical specialist, does not understand this. He believes that any mistake is an indicator of unprofessionalism. And he begins to bake at all the wrong people and not at all for what he should.

Rule six - developers are different.

There are capable, but there are ordinary. A capable developer is ten times more efficient than a regular developer. This is not a joke, this is a well-known assessment, quite old. The mistake of many managers is that they consider specialists in pieces. But in fact, there are key specialists in the sub-department who are worth ten developers. And their mistakes are rare, and if they are, they are very unobvious. And the attitude towards them should be special.

Rule seven - developers should communicate on technical topics over a cup of tea.

Like this. If the developer is sitting in a meeting, he is not working. If he discusses new technologies with colleagues over a cup of tea - he works. Such conversations often inspire him with new technical solutions that he will test during working hours, after work, at night or on weekends. The task of the leader is to maintain the traditions of creativity in the unit.

Rule eight (impracticable) - market principles should apply not only to the salaries of specialists, but also to the salaries of managers.

If a good programmer is harder to find than an average manager, then he should receive a higher salary than a lower-level manager. It’s more useful. The boss is mainly needed for control and feedback. Make a plan, monitor its implementation. These tasks are quite simple, and any disciplined person can perform them. But not every programmer can write a complex program. This does not mean that a programmer should earn more than a CEO. Of course, if he is not a development genius. But a good programmer may well earn more than the head of the department.

Rule nine (illegal) - The Labor Code of the Russian Federation interferes with work.

All these salary posts, all these duties are fictitious. Specialists differ in quality. There are high-class specialists, there are ordinary specialists. And if you can dismiss a bad specialist by making up a commission that will reveal his inconsistency in his position, then it is impossible to dismiss an ordinary specialist if he does not commit gross disciplinary offenses. But you need to fire him. And look for in his place a better, more capable and qualified. Although, in my opinion, a trial period of three months is quite sufficient to understand what kind of specialist is being arranged for you. True, the inconvenient Labor Code of the Russian Federation is perfectly compensated by the accommodating nature of the workers - most of them will agree to write a statement of their own free will, if they directly say: "You do not suit us."

That’s probably all. I suggest colleagues to add their wishes in the comments.

If it seemed to you that the complexes were saying in me that I propose to allow employees to drink tea, be late for work, not get scolded for mistakes and earn more than a manager, then you don’t understand anything in development. These rules have their own scope, and an overdose will lead to exactly what you thought. But the ability to feel this line separating the creative atmosphere from anarchy is an indicator of a good leader of the development department.