How to feed cattle. Advice to the head of the developer unit
In addition to the eternal problem of fathers and children, in my opinion, there is another problem - subordinates and managers. I would like to talk about this problem in my article. More precisely, about this particular case, as the relationship of subordinates and managers in the development of software, design and technological documentation. Managers often consider their subordinates to be irresponsible slackers, and subordinate managers to incompetent shepherds who need to feed their flocks, and not command a division of developers. Often the situation is aggravated by misunderstanding, because the manager does not understand the development, and the subordinate understands administrative nuances poorly. This article is designed to help bad leaders become good leaders. Of course, you will say: "Hey, easy, what else are bad leaders?" And you will probably be right, I greatly exaggerate. Not very bad. Regular leaders, some 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 managers into good and not good ones. No semitones. As developers, by the way, this is said in the last tip. How to understand if you are a good leader or a bad one? Read the following rules. If some of them seem to you to be crap and indulgence to idlers - then the article is written for you.
So the rules are:
Rule one - in order to well lead the development, you must be a developer.
This rule is unshakable. Development is a complex process, and only one who knows this process from the inside can correctly manage it. There is no other. If you have never developed complex systems, you cannot manage the development with high quality. In this case, you can lead the developers. But to create a product you will have to find competent people whose work you will provide. I knew quite a few managers who completely shifted technical questions to subordinates, admired people who could do the equipment, and asked only two questions: “When will it be ready?” And “What is necessary for work?”. This is a great leadership style for a layman. The pitfall here is only one - personnel policy. An error in personnel policy may result in the disruption of the project and the loss of position. If you are lucky with the staff, it remains only to ensure their work. How to provide it - read the following rules.
')
Rule two - each developer should deal only with their work, and if to speak more precisely - only the adoption of technical solutions.
If this is a programmer, he should write a program. If this is an electronics engineer - he must draw the scheme. He should not write official notes, submit lists for procurement and so on. He should only make technical decisions in his area of competence, and do it perfectly. The same goes for programming and design. It is tempting to use a specialist for something else. But in this case, you provoke a procrastination with him and are guaranteed to reduce his productivity and skills. It takes up to 2 days to switch between heterogeneous tasks if the developer is an optimist and doesn’t get discouraged from being torn off from an unfinished task. A normal person loses up to a week to switch between tasks. And in the opposite direction again loses this week. Therefore, work to distribute tasks efficiently to avoid unpleasant surprises.
Rule three - when developing a complex product, a hierarchy of technical decision-making is necessary.
A complex product requires highly skilled professionals. But all specialists are different. And good enough. And they are expensive. Therefore, the development needs a hierarchy. There should be a system architect, who almost does not deal directly with the development, but sets specific tasks for the performers. This is a high-class 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. They 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. We also need regular developers. They do the usual work under the guidance of the architect and superfillers, they are easy to replace, their salary is quite ordinary. They do what is called routine. For the preparation of textual technical documentation, technical writers are needed. For the purchase of consumables 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."
Rule Four - Do not put one specialist diverse tasks.
In a single project, a developer must be either only a programmer, or just an architect of one or several subsystems, or just 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 such tasks as programming and electronics at the same time. Occasionally, electronics engineers can program, designers can design electrical circuits. It should not be considered the norm - it is a deviation. If a person is interested, he may combine two professions for some time, but sooner or later this leads to fatigue, greatly reduces labor productivity. Therefore, if you want to get a good job, forget about the "universal specialists." This is utopia.
Rule number five - not every mistake is a disaster.
In the process of developing programs and devices there will always be errors. We are only human, and we are too imperfect. All are mistaken. Any good techie knows this. For this purpose, there are development stages with prototyping, testing, prototypes, and so on. An indicator of poor performance is only error statistics and their level (there are children's mistakes, but there are phenomena for which you can write a thesis). The problem is that a manager who is not a technical specialist does not understand this. He believes that any mistake is an indicator of lack of professionalism. And he begins to scream at the wrong people and not at all for what he follows.
Rule six - developers are different.
There are capable, and there are ordinary. A capable developer is more effective than the usual ten times. This is not a joke, it is a well-known assessment, quite old. The mistake of many managers is that they consider specialists in pieces. In fact, there are key specialists in the sub-department who are worth ten developers. And they rarely make mistakes, and if they do, they are very non-obvious. And the attitude towards them should be special.
Rule number seven - developers should communicate on technical topics over a cup of tea.
Like this. If the developer is sitting in a meeting - it does not work. If he discusses new technologies with colleagues over a cup of tea, he works. Such conversations often inspire him to new technical solutions, which he will test during working hours, after work, at night or on weekends. The task of the leader is to maintain the tradition of creativity in the unit.
Rule of the eighth (Impossible) - 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 the average manager, then he should receive a higher salary than the lower level manager. From him more benefits. The chief is mainly needed for control and feedback. Make a plan, monitor its implementation. These tasks are quite simple, and they can be performed by any more or less disciplined person. But to write a complex program can not every programmer. This does not mean that the programmer must earn more than the CEO. Of course, if he is not a genius of development. But a good programmer may well earn more than the head of the department.
Rule ninth (illegal) - TK RF interferes with work.
All these posts-salaries, all these duties are fiction. Specialists differ in quality. There are highly qualified specialists, there are ordinary specialists. And if a bad specialist can be dismissed by concocting a commission that reveals his inconsistency with his position, then an ordinary specialist cannot be dismissed 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 you are working for. True, the inconvenient Labor Code of the Russian Federation is perfectly compensated by the compliantness of the workers - most of them agree to write a statement of their own accord, if they are directly told: “You are not suitable for us.”
Here, perhaps, that's all. I suggest that colleagues add their wishes in the comments.
If it seemed to you that the complexes speak in me, that I propose to allow the workers to drink tea, be late for work, not get a scolding for mistakes and earn more than a manager, then you do not understand anything in the design. These rules have their 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 head of the development department.
So the rules are:
Rule one - in order to well lead the development, you must be a developer.
This rule is unshakable. Development is a complex process, and only one who knows this process from the inside can correctly manage it. There is no other. If you have never developed complex systems, you cannot manage the development with high quality. In this case, you can lead the developers. But to create a product you will have to find competent people whose work you will provide. I knew quite a few managers who completely shifted technical questions to subordinates, admired people who could do the equipment, and asked only two questions: “When will it be ready?” And “What is necessary for work?”. This is a great leadership style for a layman. The pitfall here is only one - personnel policy. An error in personnel policy may result in the disruption of the project and the loss of position. If you are lucky with the staff, it remains only to ensure their work. How to provide it - read the following rules.
')
Rule two - each developer should deal only with their work, and if to speak more precisely - only the adoption of technical solutions.
If this is a programmer, he should write a program. If this is an electronics engineer - he must draw the scheme. He should not write official notes, submit lists for procurement and so on. He should only make technical decisions in his area of competence, and do it perfectly. The same goes for programming and design. It is tempting to use a specialist for something else. But in this case, you provoke a procrastination with him and are guaranteed to reduce his productivity and skills. It takes up to 2 days to switch between heterogeneous tasks if the developer is an optimist and doesn’t get discouraged from being torn off from an unfinished task. A normal person loses up to a week to switch between tasks. And in the opposite direction again loses this week. Therefore, work to distribute tasks efficiently to avoid unpleasant surprises.
Rule three - when developing a complex product, a hierarchy of technical decision-making is necessary.
A complex product requires highly skilled professionals. But all specialists are different. And good enough. And they are expensive. Therefore, the development needs a hierarchy. There should be a system architect, who almost does not deal directly with the development, but sets specific tasks for the performers. This is a high-class 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. They 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. We also need regular developers. They do the usual work under the guidance of the architect and superfillers, they are easy to replace, their salary is quite ordinary. They do what is called routine. For the preparation of textual technical documentation, technical writers are needed. For the purchase of consumables 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."
Rule Four - Do not put one specialist diverse tasks.
In a single project, a developer must be either only a programmer, or just an architect of one or several subsystems, or just 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 such tasks as programming and electronics at the same time. Occasionally, electronics engineers can program, designers can design electrical circuits. It should not be considered the norm - it is a deviation. If a person is interested, he may combine two professions for some time, but sooner or later this leads to fatigue, greatly reduces labor productivity. Therefore, if you want to get a good job, forget about the "universal specialists." This is utopia.
Rule number five - not every mistake is a disaster.
In the process of developing programs and devices there will always be errors. We are only human, and we are too imperfect. All are mistaken. Any good techie knows this. For this purpose, there are development stages with prototyping, testing, prototypes, and so on. An indicator of poor performance is only error statistics and their level (there are children's mistakes, but there are phenomena for which you can write a thesis). The problem is that a manager who is not a technical specialist does not understand this. He believes that any mistake is an indicator of lack of professionalism. And he begins to scream at the wrong people and not at all for what he follows.
Rule six - developers are different.
There are capable, and there are ordinary. A capable developer is more effective than the usual ten times. This is not a joke, it is a well-known assessment, quite old. The mistake of many managers is that they consider specialists in pieces. In fact, there are key specialists in the sub-department who are worth ten developers. And they rarely make mistakes, and if they do, they are very non-obvious. And the attitude towards them should be special.
Rule number seven - developers should communicate on technical topics over a cup of tea.
Like this. If the developer is sitting in a meeting - it does not work. If he discusses new technologies with colleagues over a cup of tea, he works. Such conversations often inspire him to new technical solutions, which he will test during working hours, after work, at night or on weekends. The task of the leader is to maintain the tradition of creativity in the unit.
Rule of the eighth (Impossible) - 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 the average manager, then he should receive a higher salary than the lower level manager. From him more benefits. The chief is mainly needed for control and feedback. Make a plan, monitor its implementation. These tasks are quite simple, and they can be performed by any more or less disciplined person. But to write a complex program can not every programmer. This does not mean that the programmer must earn more than the CEO. Of course, if he is not a genius of development. But a good programmer may well earn more than the head of the department.
Rule ninth (illegal) - TK RF interferes with work.
All these posts-salaries, all these duties are fiction. Specialists differ in quality. There are highly qualified specialists, there are ordinary specialists. And if a bad specialist can be dismissed by concocting a commission that reveals his inconsistency with his position, then an ordinary specialist cannot be dismissed 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 you are working for. True, the inconvenient Labor Code of the Russian Federation is perfectly compensated by the compliantness of the workers - most of them agree to write a statement of their own accord, if they are directly told: “You are not suitable for us.”
Here, perhaps, that's all. I suggest that colleagues add their wishes in the comments.
If it seemed to you that the complexes speak in me, that I propose to allow the workers to drink tea, be late for work, not get a scolding for mistakes and earn more than a manager, then you do not understand anything in the design. These rules have their 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 head of the development department.
Source: https://habr.com/ru/post/324068/
All Articles