November 29, 2011 at 13:08Micromanagement: time to create zombies
I greet everyone who is interested in this topic.
Of course, micromanagement is found not only in IT, but it is in this area that this black ritual can bring 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 control. So, according to businessdictionary.com, micromanagement is a tough, thorough, ongoing and often demotivating control of the work performed by employees. In other words, if your bosses do not allow you to take a step without checking whether you did it right, constantly monitors all your actions and requires a report on even the smallest movements, I congratulate you, you are a potential or already fully-fledged victim of micromanagement.
What are the downsides of micromanagement?
The biggest danger of this management style is the transformation of creative, self-minded, initiative workers into weak-willed zombies who regularly execute assignments without a gleam in their eyes. Given 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 unreasonable, but also in some cases contributes to project paralysis, conflicts and even the departure of specialists from the team.
What is more dangerous micromanagement?
The lack of confidence in the team from its leader and its prohibition to make mistakes, which leads to a halt in the development of the team. If people feel that they are not trusted, then team building 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 rebelled.
The micromanager thinks that he knows when he can trust his team in making decisions, and when not. He follows one principle - he allows his people to act independently and freely as long as they act correctly in his understanding. This is anything, but not independence and freedom. Freedom is the ability to act differently than thenecromancer himself would have acted in the place of a zombie of an organized developer
Constant checks and too frequent reporting is another great opportunity to kill the developer’s trust, his faith in his own strength and the desire to cooperate with the team leader. Nothing destroys working enthusiasm so much as the feeling that you are treated like an underdeveloped child who needs to be controlled every minute. In addition to falling moral standards, such a management model is fraught with inefficient use of time by the manager himself. It turns out that 2 specialists are working on the developer’s task: the developer himself and the manager, and the latter’s time is much more expensive.
Another drawback of micromanagement is the loss of the strategic approach to solving problems out of focus. Of course, not such a strategic approach as in the joke about the wise owl and mice who wanted to become hedgehogs, but adequate strategic thinking when planning the development process. If you lose focus, there is a danger of falling into the extreme of tactical planning, which will make the 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 when perfectionism goes into micromanagement. The pursuit of perfection and belief in oneself as perfection works wonders: the micro-manager sees himself as the all-powerful fighting magician of the penultimate level, who keeps his finger on the pulse of his squad of pumped fighters. But there comes a moment when a casual glance, like in stupid horror films, suddenly snatches out the cute zombie faces instead of the usual warped faces of heroism.
In addition, a developer who has been within the range of a micro-manager for some time can not only stop in development, but also significantly ruin his karma or even his career. How much manna will be spent on rehabilitating the zombie and integrating it into another team? It is easy to forget how to think independently, and the restoration of this skill will take precious time and resources.
Is everything really so bad and there are no situations when micromanagement is permissible?
Of course it does. If, for example, there are problems with the involvement of the team in the process. Say, massive cognitive dissonance, seasonal depression or just a holiday mood, as a result of which the team simply drops out of the process and does not want to fall into it of its own free will. Then it's time to open your necromancy compendiums and read out at least a simple spell to create zombies and control them.
Sometimes, for some personal reasons, an employee suddenly begins to behave destructively in relation to the work performed or to colleagues. In this case, micromanagement does not hurt, but rather 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 justified.
But the justified use of micromanagement is the exception rather than the rule.
In general, it is best to exclude this black magic from the development process. How to do it?
Here are some recommendations for beginners and successful micromanagers:
- remember that you are a managerteams, not one of the developers or testers. Your role is to help your subordinates apply their development knowledge and experience, not your own. That you have been pumped to a breathtaking level of software development magic, and so no one doubts, and you do not need to remind about this once again. Not every brain can cope with the concept of infinity. Try as quickly and safely as possible for yourself and others to make your transition to a new quality - from an expert to a leader.
- focus on the statement of the problemrather than explaining how to solve it. Tell WHAT to do, not HOW 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 limitations that need to be considered when completing the task. Let the team process the initial data itself, use its experience and creativity and find the right way of action. Do not be afraid to delegate authority, because with them you delegate responsibility, which in itself is motivation.
- explain the significance of a particular development phase in the context of the entire project. Vision of the full picture and the interconnections between the stages of the project helps to consciously move forward, systematize the work already done and predict future tasks.
- Ask the team more questions and give less ready-made answers. As a leader, ask questions whenever possible, and give answers only when absolutely necessary.
- remember: people, not a resource! (c) Developers can be perceived as numbers and man-hours during project optimization, but when the manager works with the team, it is better to build partnerships with the team, since the goals of both the developers and the project manager are common.
Try to Avoid UsingNecromancer Practicesmicromanagement, because in addition to the re-controlled zombies there are still so many combat-ready and effective units!
I would very much like to hear from respected habrag citizens how to deal with micromanagement in the field by developers. Particularly interested in cases of successful struggle.
Of course, micromanagement is found not only in IT, but it is in this area that this black ritual can bring 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 control. So, according to businessdictionary.com, micromanagement is a tough, thorough, ongoing and often demotivating control of the work performed by employees. In other words, if your bosses do not allow you to take a step without checking whether you did it right, constantly monitors all your actions and requires a report on even the smallest movements, I congratulate you, you are a potential or already fully-fledged victim of micromanagement.
What are the downsides of micromanagement?
The biggest danger of this management style is the transformation of creative, self-minded, initiative workers into weak-willed zombies who regularly execute assignments without a gleam in their eyes. Given 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 unreasonable, but also in some cases contributes to project paralysis, conflicts and even the departure of specialists from the team.
What is more dangerous micromanagement?
The lack of confidence in the team from its leader and its prohibition to make mistakes, which leads to a halt in the development of the team. If people feel that they are not trusted, then team building 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 rebelled.
The micromanager thinks that he knows when he can trust his team in making decisions, and when not. He follows one principle - he allows his people to act independently and freely as long as they act correctly in his understanding. This is anything, but not independence and freedom. Freedom is the ability to act differently than the
Constant checks and too frequent reporting is another great opportunity to kill the developer’s trust, his faith in his own strength and the desire to cooperate with the team leader. Nothing destroys working enthusiasm so much as the feeling that you are treated like an underdeveloped child who needs to be controlled every minute. In addition to falling moral standards, such a management model is fraught with inefficient use of time by the manager himself. It turns out that 2 specialists are working on the developer’s task: the developer himself and the manager, and the latter’s time is much more expensive.
Another drawback of micromanagement is the loss of the strategic approach to solving problems out of focus. Of course, not such a strategic approach as in the joke about the wise owl and mice who wanted to become hedgehogs, but adequate strategic thinking when planning the development process. If you lose focus, there is a danger of falling into the extreme of tactical planning, which will make the 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 when perfectionism goes into micromanagement. The pursuit of perfection and belief in oneself as perfection works wonders: the micro-manager sees himself as the all-powerful fighting magician of the penultimate level, who keeps his finger on the pulse of his squad of pumped fighters. But there comes a moment when a casual glance, like in stupid horror films, suddenly snatches out the cute zombie faces instead of the usual warped faces of heroism.
In addition, a developer who has been within the range of a micro-manager for some time can not only stop in development, but also significantly ruin his karma or even his career. How much manna will be spent on rehabilitating the zombie and integrating it into another team? It is easy to forget how to think independently, and the restoration of this skill will take precious time and resources.
Is everything really so bad and there are no situations when micromanagement is permissible?
Of course it does. If, for example, there are problems with the involvement of the team in the process. Say, massive cognitive dissonance, seasonal depression or just a holiday mood, as a result of which the team simply drops out of the process and does not want to fall into it of its own free will. Then it's time to open your necromancy compendiums and read out at least a simple spell to create zombies and control them.
Sometimes, for some personal reasons, an employee suddenly begins to behave destructively in relation to the work performed or to colleagues. In this case, micromanagement does not hurt, but rather 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 justified.
But the justified use of micromanagement is the exception rather than the rule.
In general, it is best to exclude this black magic from the development process. How to do it?
Here are some recommendations for beginners and successful micromanagers:
- remember that you are a managerteams, not one of the developers or testers. Your role is to help your subordinates apply their development knowledge and experience, not your own. That you have been pumped to a breathtaking level of software development magic, and so no one doubts, and you do not need to remind about this once again. Not every brain can cope with the concept of infinity. Try as quickly and safely as possible for yourself and others to make your transition to a new quality - from an expert to a leader.
- focus on the statement of the problemrather than explaining how to solve it. Tell WHAT to do, not HOW 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 limitations that need to be considered when completing the task. Let the team process the initial data itself, use its experience and creativity and find the right way of action. Do not be afraid to delegate authority, because with them you delegate responsibility, which in itself is motivation.
- explain the significance of a particular development phase in the context of the entire project. Vision of the full picture and the interconnections between the stages of the project helps to consciously move forward, systematize the work already done and predict future tasks.
- Ask the team more questions and give less ready-made answers. As a leader, ask questions whenever possible, and give answers only when absolutely necessary.
- remember: people, not a resource! (c) Developers can be perceived as numbers and man-hours during project optimization, but when the manager works with the team, it is better to build partnerships with the team, since the goals of both the developers and the project manager are common.
Try to Avoid Using
I would very much like to hear from respected habrag citizens how to deal with micromanagement in the field by developers. Particularly interested in cases of successful struggle.