Micromanagement: time to create zombies

Habraderae greetings to all who are interested in this topic.

Of course, micromanagement is found not only in IT, but it is in this area that this black ritual can cause significant harm to the development process and the final result, not to mention the professional development of employees.

Probably, for a start it is worth giving a definition to this cataclysm from management. So, according to businessdiction.com, micromanagement is a tough, thorough, ongoing, and often demotivating, control of work performed by employees. In other words, if your boss doesn’t allow you to take a step without checking whether you did it correctly, constantly monitors all your actions and requires an account of even the slightest movements - congratulations, you are a potential or already fully committed micromanagement company.
')
What are the disadvantages of micromanagement?
The greatest danger of this management style is the transformation of creative, independent-minded, enterprising employees into weak-willed zombies who regularly carry out assignments without any shine in their eyes. Considering that in IT the percentage of people who can think outside the box and generate bright ideas is very high, such a management style as micromanagement is not only unwise, but in some cases contributes to project paralysis, conflicts and even the departure of specialists from the team.

What else is dangerous micromanagement?
The lack of confidence in the team from its head and his prohibition to make mistakes, which leads to a halt in the development of the team. If people feel that they are not trusted, then the formation of the team is frozen. That's right, the zombies have no team spirit: they are united only by the geographical proximity of the graves, from which they rose.

The micromanager thinks he knows when he can trust his team in making decisions, and when not. He follows one principle - allows his people to act independently and freely as long as they act correctly in his understanding. This is anything, but not independence or freedom. Freedom is the ability to act differently from what the necromancer micromanager himself would have acted on the site of a zombie . In a broader sense, this is also true: the right to be right (in the eyes of the micromanager) has nothing to do with freedom; real freedom is to be right to be wrong.

Constant checks and too frequent reporting is another great opportunity to kill the developer’s confidence, his faith in his own strength and the desire to cooperate with the team leader. Nothing destroys worker enthusiasm as much as the feeling that you are treated like an underdeveloped child who needs to be controlled in every minute. In addition to a decline in the level of morality, such a management model is fraught with inefficient use of the manager’s own time. It turns out that 2 specialists work on the developer’s task: the developer and the manager himself, and the latter’s time is much more expensive.

Another lack of micromanagement is the loss of a strategic approach to problem solving out of focus. Of course, not such a strategic approach as in the joke about a wise owl and mice that wanted to become hedgehogs, but adequate strategic thinking when planning the development process. When focus is lost, there is a danger of going to the extreme of tactical planning, which will make development management itself ineffective.

Another unobvious enemy of the manager is perfectionism. Since the main property of perfectionism is uncontrolled distribution, it is very difficult to determine the moment when perfectionism turns into micromanagement. The pursuit of perfection and the belief in oneself as perfection creates wonders: the micromanager sees himself as the all-powerful war magician of the penultimate level, who keeps abreast of his squad of pumped fighters. But there comes a time when a casual glance, as in stupid horror films, suddenly snatches out the pretty faces of a zombie instead of the usual skewed heroism of faces.

In addition, a developer who has fallen into the range of a micromanager for some time may not only stop developing, but also significantly spoil his karma or even his career. How much manna to spend on rehabilitating a zombie and integrating it into another team? It’s easy to forget how to think independently, and it will take precious time and resources to restore this skill.

Is it really that bad and there are no situations when micromanagement is acceptable?
Of course it does. If, for example, there are problems with the involvement of the team in the process. Say, mass cognitive dissonance, seasonal depression or just pre-holiday mood, as a result of which the team just drops out of the process and does not want to fall into it voluntarily. That's when it's time to open your necromantic notes and read from there at least a simple spell to create and manage zombies.

Sometimes for some personal reasons, the employee suddenly begins to behave destructively in relation to the work or colleagues. In this case, micromanagement does not hurt, but on the contrary, helps prevent unexpected or unpleasant events. In other words, if there is a threat to internal security (of a project, information, employees), then micromanagement as a strategy of behavior and protection is fully justified.
But the justified use of micromanagement is the exception rather than the rule.
In general, it is better to exclude this black magic from the development process. How to do it?

Here are some recommendations for beginners and accomplished micromanagers:
- remember that you are the team leader , not one of the developers or testers. Your role is to help your subordinates apply their knowledge and development experience, not your own. No one doubts that you have pumped up to the breathtaking level of software development magic, and no need to be reminded of this once again. Not every brain will cope with the comprehension of the concept of infinity. Try as quickly and safer for yourself and those around you to make your transition to a new quality - from expert to manager.

- focus on the formulation of the problem , and not on explaining how to solve it. Tell WHAT you need to do, and not HOW you need to do it. Tell the team what should happen as a result of their joint magical efforts, and also give the necessary explanations on the parameters or restrictions that must be considered when performing the task. Let the team itself process the initial data, use its experience and creative potential and find the necessary way of action. Do not be afraid to delegate authority, because with them you delegate and responsibility, which in itself is a motivation.

- explain the significance of a particular development stage in the context of the entire project . The vision of the complete picture and interrelations between the stages of the project helps to consciously move ahead, systematize the work already done and predict the upcoming tasks.

- ask the team more questions and give less ready answers. As a manager, ask questions whenever possible, and give answers only in case of real need.

- remember: people, not a resource! (c) Developers can be perceived as numbers and man-hours during project appraisal, but when the manager works with the team, it is better to build partnerships with the team, since the goals of the developers and the project manager are common.

Try to avoid the use of necromantic micromanagement practices , because apart from overcontrolled zombies, there are still so many combat-ready and effective units!

I would very much like to hear from respected Habrah citizens how to deal with micromanagement in field conditions by the developers. Particularly interested in cases of successful struggle.