People with a tendency to micromanage usually do not notice this in themselves.
“Anton, there is a conversation. I don’t know how to say it more politely, but please stop with micromanagement, I’m already climbing the wall!”
Is it me?! Am I micromanaging??? I'm just trying to help! Judge for yourself.
An ordinary Tuesday, everyone is working remotely, communication takes place on Slack.
12:00
Anton: How are you doing with the task? Can I be of any help?
Bob: No, thanks, I've already made good progress.
15:30
Anton: How is it, Bob? Is things moving? If you need anything, I'm in touch.
Bob: Yes, everything is fine… I'll finish it by tomorrow's meeting, just like I said.
Two days later.
13:00
Alert on Pagerduty: /appears
Bob: I'll hire you.
13:15
Anton: Great, thank you. I looked too, it looks like the problem is in repository X, file Y, line 235, if you need help debugging, please contact me.
Bob: (hands) Anton, we have a conversation…
The remark given at the beginning of the article is fictitious, but all examples are taken from real life.
Micromanaging with good intentions is still micromanaging.
The two examples you observed above represent the two main manifestations of micromanagement:
- Require people to report constantly
- Doing people's work for them
Micromanagement is not a vice that only bad managers are guilty of. Good leaders can suffer from it too. Personally, I remain convinced that my intervention was motivated by a sincere desire to help. But here it is important to understand: it doesn’t matter what exactly motivates you. After all, the road to hell is paved with good intentions. It took me a while to accept this lesson.
I'm used to working with juniors fresh out of college, and they require much more attention. Everything is new to them: Docker, microservices, Jenkins, merge conflicts, and so on, so the involvement and willingness to help of a manager can play a very big role.
It’s still difficult for me to switch to managing seniors (and in the last month, technical leads), who are only annoyed and distracted from their work.
So what to do?
Step 0: Set Expectations
First of all, this applies to those who work remotely – it is necessary to clearly convey to everyone which mode of communication you prefer.
It’s better not to bother good senior developers at all – when you need them, they will contact you themselves. If there is an urgent task that is being continuously monitored by other teams or employees, explain the situation to the developers before asking for regular updates. There is no need to assume that they will figure out why you are constantly pulling them.
If you're like me and feel that control urges are hard to control, share your struggles with your team. Say that you understand how annoying it is and are trying to work on yourself. Ask for patience and to let you know when you are going overboard.
A simple way to make this process easier for yourself is to ask your team to provide short (one or two sentence) written reports at the end of the day. This will not be difficult for people, and you will be calmer.
Step 1: Tune in to Your People
This is the most common measure against micromanagement.
Talk to your team, ask them what format of communication is closer to them and what kind of support they expect from you. Let's imagine that Bob from the example above is a shy intern who is afraid to ask for help. In this situation, the questions “Are you okay? Can I help you?” will be received with gratitude and without any irritation.
Step 2: Based on your level of preparedness for the task
Most managers stop at the first step and come to the following scheme:
- If it's a junior, you can control it as much as you like
- If it's a senior, it's better to leave him alone
This, of course, is better than annoying everyone without exception, but it’s still no good. If some junior is writing his fifth microservice in a row, does he really need you? And if some senior works in a completely new field for himself, deadlines are running out, the project is sensitive, is it really worth leaving him to the mercy of fate?
In his book High Performance Management, Andrew Grove introduced the concept of task readiness. To quote the author, task readiness “represents a combination of level of achievement, willingness to accept responsibility, and education, training, and experience in the field.”
The concept can be summarized as follows:
The most important variable that determines which leadership style will produce the best results is the employee's level of preparation for the task.
Low level of employee preparedness
Key Characteristics of an Effective Leadership Style: structured, task-oriented, saying “what”, “when” and “how”.Average level of employee preparedness
Key Characteristics of an Effective Leadership Style: People-oriented, emphasis on two-way communication, support, collaborative discussion.High level of employee preparedness
Key Characteristics of an Effective Leadership Style: minimal intervention from management, goal setting, monitoring.
One fundamentally important aspect of this approach should be noted: if the level of preparedness is low, we cannot simply leave things to chance and leave people to make mistakes:
An acquaintance of mine who had always been excellent at his job hired a junior to take over some of his old tasks while he took on new ones.
The subordinate performed the tasks poorly. The friend’s reaction was: “He must make his own mistakes. That’s the only way to learn!”
The problem here is that this subordinate's training is paid for out of the clients' pocket. And this is completely unacceptable. Responsibility for training a subordinate should rest with his supervisor and not shift to the clients of his organization, whether they are external or internal.
Finally
Don't throw the baby out with the bathwater: micromanagement is not evil in its purest form. If you go too far in the opposite direction and are not involved at all in the day-to-day activities of employees, the team, the organization, and the customers will all suffer. On this topic there is
Taha Hussein with examples from personal practice.
