Photo by Christopher Windus on Unsplash
How to identify micromanagement
When trust is missing, you deserve better.
Working in a big tech company can be tough. A lot of human dynamics take place, and things get even more complicated in remote-first working environments.
Micromanagement is surely one of the most debated practices of bad management. There are plenty of articles, videos, talks, books and other stuff around the web and in your closest library, that will cover the subject way better than I could. Nonetheless, I think sharing my experience is worth it, as you may relate in one way or another and perhaps take away some advice.
If I should give an informal definition, it would be:
Micromanagement is when your manager steals your daily job.
Working for a micromanager is mostly like that, whatever you do is questioned, from code to simple coffee breaks. When a manager talks over others, wants an ACK every half an hour, analyzes every minute of your time reporting, or questions even the smallest decision you made, that's probably a micromanager. Micromanagers can be harmful in so many ways, not only to their teams but to the company as a whole, by stressing out employees, increasing tension and contributing to resignation waves.
I saw many skilled people quitting because of them and noticed them in action in very different contexts. By sharing what I have seen over the years I hope I can help you better identify if your working environment is rotten by this bad management strategy.
Meetings
If you ever worked with Scrum, you know one of the golden rules: meetings are timeboxed. Period. To be effective, a meeting needs a well-defined goal and a proportionally fair amount of time allocated for the discussion. If the foreseen required time is too much, it should be chopped off into different meetings, each with its subgoal.
Now, figure out someone who overtalks in the meeting or, even worse, talks over other team members. How rude! That is what I recognize as typical micromanager behavior. Usually, a Scrum Master must speak up and ensure everyone has the chance and time to express their ideas, but there are many ways this can go wrong.
if the micromanager is the Team Leader, working tightly with management, he/she could silence the Scrum Master because of his/her authority or even reject the presence of a Scrum Master with a statement along the lines of: "We're such a good team, we don't need supervision" and taking control over what is going to be decided. This is an example of a Vulgar Display of Power principle (🤘). Yes, it does not exist formally, but you get the idea.
if the meeting has a strict tech scope and the micromanager is the code's owner, then you have no chance to question past decisions or propose something that goes beyond their view. Usually, they are also very strict on code conventions (more on this later).
if the micromanager is a wannabe Team Leader or manager, meetings are the perfect moment to show off themselves to their boss. The mantra is: "The more I speak, the more I am visible" or "The more I make decisions, the more I will be seen as a decision maker", so they'll gonna eat up all the meeting time, talk over others and bend the final decision to their desiderata.
Usually, the reality lies in the shades of a gray area in between. Even though you can experience them to their fullest (and I did more than once, unfortunately), those are behavioral smells.
Time tracking
Every project needs time management. One of the crucial activities is time tracking, a log of how many hours/days have been spent on a certain task, oftentimes because there is a direct impact on costs and incomes.
What can go wrong?
"Hey, you spent too much time on this task".
When a chat starts like this, you better know why you spent that time: perhaps there was a hidden criticality to be addressed, and this is fine as a developer is meant to find problems and discuss possible solutions, or the micromanager is going to question every single minute of a working day.
"At what time did you start working? At what time did you stop?"
"Why did you spend X instead of Y?"
"How long did your lunch break last? Trust me, eat only bananas for lunch, it will save a lot of your time and make you more efficient. You don't need to peel them off like apples!"
"I sleep only 4 hours per night, will have a lot of time to rest once I pass away"
"Oh, you were away from the keyboard! Why was that?"
Yes, those are extracts from real conversations, even though no one ever wanted me to eat only bananas for lunch. Nonetheless, how sad is that? A developer is a professional and as such must be trusted. Yes, also junior ones. Yes, even if they make mistakes. Everyone makes mistakes.
This is particularly dramatic in remote working, where developers must be trusted even more.
Calendar invites
I was new to a team, up to my second working day with them, and was assigned a tricky task. I was struggling to get it done in the best possible way when an email popped up.
"WHERE ARE YOU? WHY YOU'RE NOT ATTENDING THAT F. MARKETING MEETING?"
Caps lock intended. My thoughts immediately started to spin around. What meeting? Oh, that one. So I was supposed to join. But that was tagged as a marketing event, so why did nobody warn me I had to attend?
That's a subtle way of micromanagement. If developers must attend a meeting, they have to know it clearly, especially if those meetings fall off their duty borders. Software development has nothing to do with marketing, so it was OK to assume developers were not required to attend unless explicitly told they were. With that, I am not saying developers should not join non-techy meetings, nor that they should not be interested in them. They can be very interesting! I am just highlighting that people must know in advance, and it has to be crystal clear if they are required to spend time on activities that go beyond their duties.
This is because people, developers in our case, are free to organize their time and to choose whether to attend optional meetings or not. But for micromanagers, it is hard to let you decide something on your own as you're just a pawn on their chessboard, to live or die for their game.
Work-life balance
Another form of micromanagement comes into place in the mantra "work hard, work overtime". Micromanagers want to control everything and that takes time. So they advertise it as hardworking while in reality is the will to be noticed by their boss and a very bad time management strategy.
What could happen on a Monday morning, is your git fetch / git status pops up a new commit that was checked in on Saturday at 3:35 AM. As soon as the micromanager enters the room, he/she makes sure everyone knows how much effort he/she puts into his/her job. This could implicitly force every teammate, especially the younger ones, to work overtime.
Some other times there are also jokes around the hardworking mantra. For example, you could hear: "Hey, did you take a half day off, right?" while leaving the office on Friday at 7 PM.
Should we laugh? Really?
Code
A good product is the goal of every company and product manager. Good code is the consequent goal. For micromanagers, good code translates into something like "the code I would write". And they of course would write neat, clean, bug-free code.
Let's see some examples where I saw micromanagers' creativity shine.
Naming things. We all know this is a hard game. Micromanagers will complain about local scoped variables' names and will require a new commit to fix this urgent matter even if it is Friday at 6 PM.
Code formatting. Oh, code formatting. I've seen this nonsense debate so many times that my answer is always the same: "Pick one, I will stick to it. Just, provide autoformatting on save". While in Javascript the problem has an easy answer that is called Prettier, I am not sure about other languages, even if there are plugins for it for the main languages.
ESLint custom plugins: while ESLint is a very powerful tool to provide advanced code assistance, going beyond mere syntax rules, it can be used to impose micromanagers' views, making them feel like the code was written by them. They can impose very strict code conventions on, as we have seen, naming and formatting.
Code reviews. I love code reviews, there is a lot to learn from teammates. But they have a dark side, also. Similarly to ESLint plugins, they could lead to long discussions to force the developer to forcibly accept very strict code conventions.
Micromanaging code can easily lead developers to frustration and mere monkey executioners, where the room for personal initiative is persecuted and reduced over time.
Conclusions
Micromanagement is a sad reality and what I described in this bite is surely not exhaustive. In the next one, I will try to answer the question "why is it a thing?" and shape possible solutions.
References
Vulgar display of power