Micromanagement: The Silent Threat to Engineering Teams

This is the Effective Engineering Manager podcast. In today's episode, Slava and Adam tackle the topic of micromanagement and provide guidance for engineering managers to avoid it. Welcome to the Effective Engineering Manager podcast. Hi Slava, it's good to be here today.

Today's your time. What would you like to talk about? Today I would like to talk about a pretty serious topic. Don't do it things.

Today I would like to talk about micromanagement and how it is a silent threat to the engineering teams. Intriguing topic. Certainly a term that has a lot of vitriol attached to it. Many of us can attest to either feeling like we've been micromanaged or maybe we've been the ones that micromanaging and we've had to alter our approach.

So I'm curious to hear more about this. Tell us a little bit more why micromanagement is a topic you want to talk about today. You are right. I have experienced it myself.

Every time it happened to me, basically I resigned. It's not a fun exercise and I think it's really a silent killer. That's why I think this topic is important. If you think of it, engineering managers play a crucial role in cultivating the environment that encourages creativity, autonomy, productivity.

What micromanagement does, it poses a significant challenge that undermines those efforts. It happens when managers excessively control or involve themselves in the team's work. Often taking the work that should be delegated, taking the work of the plates, of their direct reports and even skip levels. Essentially this behavior stifles the team's potential and as a result creates a toxic worker environment where morale and productivity steadily and sometimes sharply decline.

That's basically the problem. If you try to understand why it's coming from, it's that micromanagement in engineering teams often comes from these three primary factors or sources. Number one is and by the way I'm just going to do a step aside. Micromanagers don't know how to manage.

Very long story short, it is an ability to manage. It's just ineptitude and management. That's why it's scary when you have a manager who doesn't know how to do his job. That's one of the fairly strong and fairly scary options.

Anyway, number one is an ability to delegate. Micromanagers struggle to delegate effectively and this results in overwhelming workload for them and that distracts them from strategically leadership responsibilities. Most engineering managers grow into the leadership roles organically. I did, you did, we all were engineers and we didn't receive any formal training.

Some people are naturally gifted in delegation. They are naturally born managers. For some, for some, or for many rather, this critical skill of delegation remains underdeveloped. It doesn't exist at all.

If it's not studied, practiced. Without delegation, without mastering delegation managers will just keep taking on more and more tasks. The work comes at you and you keep working harder, harder, and harder. In the end, you know that your boss is a micromanager when he's working harder than everyone else.

I've seen it. They're unavailable to work, to management work. You cannot ask questions. You cannot ask for help.

They don't have time, period. Too much work. The next one is, the next cause of micromanagement is fear of failure. The anxiety that the team members mistakes will reflect poorly on the manager in the eyes of their own boss, that drives this need to control everything.

You're so fearful of the mistakes of your team that you just must be in the full control. This fear comes from the manager that the manager is concerned that their performance will be perceived as low because their team is making mistakes. That's what they do. They take on more and more responsibilities.

They do a team's work best they can and instead of enabling the entire team under them to perform, to train them, to develop them and enable them to deliver, which is what is your responsibility as the boss. It's not your responsibility to work harder than everyone else. I think the third one, the third cause of micromanagement is lack of trust. You and I, we talked about trust before.

It's a critical thing to develop. If trust is not developed, it means that managers will not trust their team's abilities to deliver. It will cause fear and it will cause lack of delegation. To me personally, even though it's the fourth thing in my list, I would say there's a good chance it's number one.

Why is it happening? Usually it starts from the failure to build working relationships with their direct reports. We know the tool for building those relationships. These are one-on-ones.

You know you're going to have a micromanager when your boss tells you, "Hey, I'm so busy I don't have time for one-on-ones." It means that there's not going to be any sort of a development of a relationship happening between you and your boss. Very simple. If you're a manager and you don't know anything about your team and the only thing you do is to dish out tasks and work hard yourself, how can you trust them?

You don't know them. It's natural not to trust people whom you don't know. But it's just a fallacy because managers do not make an effort to develop that trust, to develop an understanding of their people. When the trust is not there, what happens is that managers second-guess team's decisions, override technical choices.

You've seen it too. You come up with something that works, all it needs to be is just, "Hey, go ahead and do it." And then your boss comes in and says, "It's all wrong. It should be like this and this and that."

You may even know who I'm talking about. I've seen managers redoing the work that their team did. Literally going into GitHub and recording everything. Writing their own code.

Essentially, the result is that progress slows, team's confidence drops, innovation is not happening because innovation means mistakes. You cannot innovate without mistakes. The result is that the team becomes completely reluctant to make independent decisions and just sits and waits until the orders arrive. That's my take on the three causes of micromanagement.

What do you think? I think your causes are very spot-on and I think you bring up a lot of good rationale behind it. What I would add is first of all, I don't think micromanagers are micromanaging because they want to. What I mean by that is I don't think anybody genuinely comes in and says, "I'm going to get the most out of what I need by being supercharged and overseeing every little thing that's done and to the point where I'm actually telling you to do it."

I think that is a byproduct of two things. One, you've already hit on, which is lack of trust. I think the main reason why people actually do micromanage is because of a lack of trust, not just of their own team, but lack of trust from their managers, their bosses, or a culture, corporately, where there's a lack of trust. It creates a space where you as a manager now have to respond and still be productive in an environment where trust is not present.

Then I think the delegation part, which you hit on as well, is a very direct byproduct of lack of trust. I think when you don't have trust, either upward, downward, or around the organization, and you've never practiced good delegation, as you mentioned, your natural reaction is going to be to micromanage to feel that you're getting more control over it. If you've never practiced good delegation and cultivated that and enabled your directs on what a good delegation is, then you're basically working in a very brute force manner where you're trying to do everyone's job for them at the end of the day.

There's no trust around. You don't know how to properly delegate. You don't have the structure in place to delegate. Now you're effectively micromanaging every task.

Then that compounds on itself because, as we know, micromanagement creates fear. It creates animosity. It creates silos. It creates all the negative things.

Then you're working even doubly as hard as the micromanager to get the information you need to make sure things are still done, to fix mistakes, to prevent things from bubbling up. I think you're absolutely right that these are some of the three main root causes. I would just say that the delegation piece, I think, is an absolute differentiator between people that work environments where there's no trust that can effectively manage strong teams versus ones that end up micromanaging.

Yeah, good stuff. 100%. Let's just move on and talk about maybe do a deeper dive what is the impact of the micromanagement on the engineering teams. I believe that the consequences of the micromanagement are profoundly damaging.

Team morale plummets when team members feel disempowered and essentially unable to leverage their expertise. Productivity suffers as micromanagers fail to provide clear direction and when they're overwhelmed by the desire to control every detail. This stifling atmosphere essentially pushes talented engineers to seek opportunities elsewhere and ultimately affecting the retention and overall the culture of the organization. What also happens is the communication breakdown.

When teams are led by micromanagers, the communication tends to be vertical, flowing primarily through the manager rather than horizontally among the team members and it's usually top down. This dynamic essentially discourages collaboration as team members just feel that it's more efficient to influence the manager for the decisions rather than trying to work with their team members. The leadership development gets stunted. Micromanagers do not enable leadership and do not enable the development of the leaders because they do not trust the people.

How can you make someone a leader if you don't trust them? Also, because of that systemic lack of time, they cannot invest in their team's growth and they miss opportunities for the mentorship. Also, young managers may adopt micromanaging behaviors themselves, especially if they didn't have developed their own effective management style. If you're a young manager who just came into the profession from being an engineer and you have a micromanager, how are you going to learn?

What are you going to learn? It's pretty scary. Another thing is the burnout and disengagement. The engineers and the managers who micromanaged often experience burnout because they just feel trapped in unfulfilling situations.

There's no future. There's no light at the end of the tunnel. This constant oversight, lack of autonomy, it just leads to frustration and it just diminishes their engagement and motivation. I can double-click on the talent retention.

Micromanagement negatively impacts the retention of the top talent. High-performing engineers and managers require autonomy. That's why they are high-performing because they can grab the task, understand what needs to be done, and drive to completion without engaging too much with their boss because they know what they're doing. Without the trust to produce results, essentially the only message high-performers or great performers receive is that their work is not needed and the results are not needed.

That's why these talented members of the team will most likely leave and look for opportunities somewhere else. Maybe the fifth and maybe the most important thing, it's not the most important, but one of those most important things is the project performance because micromanagers do all the work themselves, don't allow the team to do the work, and if the team does the work, it's really a contingent or continuous input from their boss. The performance of the delivery of the project suffers because the focus inside the team with the micromanager boss is that the focus of control rather than collaboration and then you end up with essentially just like a downward spiral.

The more you micromanage, the less effective you and your team become, and then the more and more delays and progress. Forget about being able to respond to changes and trying to hit the deadlines in such a situation, and you can forget about the quality as well. These are my thoughts on the impact on the teams and the projects. What are your thoughts, Adam?

I think the part about burnout and disengagement is really significant, and I'm glad you point that out because again, I think coming back to the fact that micromanagers are doing this out of a need to have control to get something done. Again, I don't think it's intentional, but it's a byproduct of the environment. And now you've got a bunch of engineers in our case that are feeling overwhelmed, maybe threatened, maybe diminished because they feel like they're not good enough that their boss has to constantly manage them and micromanage them.

You don't have good relationships. There's no opportunity for delegation, so what's left then to keep going in that hamster wheel and burning out? There's no space for any normal human interaction, no appreciation for people's skills, and like we mentioned, no delegation, so you can't really own your own space on anything. And I think that's a real thing, and it comes very quickly.

I think you can burn people out very quickly because again, you're not speaking the same language. As the micromanager, you're often trying to get something done. You're often trying to make sure something is happening in a very ineffective manner, and then the ones that are being micromanaged often don't understand why. They don't feel like their work is appreciated.

So you've got this huge disconnect, and you're absolutely right. People will leave, and it's really hard to build out any kind of culture, any kind of sustainability with a team when there's this culture of micromanagement. Now, the one thing I'll also say is, I know we're talking a lot about this, and I'm sure a lot of people are shaking their heads and have experienced this, and I don't think there's a vacuum. We don't live in a vacuum where you can't just not micromanage all the time.

I think all of the guidance that we've given before, building good trust, having strong one-on-ones, learning delegation, these are all very strong pillars so that as a manager, when you need things to get done or you need to make a decision or you need to ask someone to do something, it doesn't get perceived as micromanagement. It gets perceived as "Oh, okay. My boss just needs this," and we have a very strong foundation of a relationship to build off of, and it's not just, "Oh, my gosh.

This person is asking me, is just taking control of everything I do," right? So I think it just reinforces that absolute need for everything else we talk about, and I appreciate you bringing up this topic because it is something I think more than not we experience and often is very difficult to deal with, and when you burn out and you can't survive in that environment anymore, it's not healthy. Yep. Well, yes, we've also brought up the impact of micromanagement on innovation briefly in the beginning, and I'd like to do a deeper dive into this.

So micromanagement does hinder the innovation inside the engineering teams because for a very simple reason, innovation is unpredictable, and it's an iterative process. It requires creative thinking. Sometimes you make two steps forward, one step back. Sometimes things break, and you have to experiment.

You have to learn from the mistakes, and these are the things which are the mistakes and the experimentation and the nonlinear thinking. This is what micromanagers are fearful of, and if you think of it, just think of lack of autonomy, which is necessary for... The autonomy is the key for the innovation because micromanagers usually impose... I mean, if they're good micromanagers, if they've been doing it for a long time and some of them didn't do, they come up with strict guidelines of how things can be done and should be done, and they also monitor every step of those guidelines.

Essentially, your ability of coming up with something which is not on the list of that guideline disappears, and that's just a playbook. You play by the book, and nothing else is going to happen. To be creative, engineers need freedom to explore different things, to make mistakes, and micromanagement just creates this culture where employees hesitate to take risks, and in the end, in the fully developed micromanagement culture, they avoid risks. They just will do everything not to take risks because they're going to get punished for the mistakes, and this is where the innovation goes.

And creativity gets reduced when there's a prescription on how things should be done. This limits the scope of the creative problem solving, and the engineers will feel constrained. They will have to follow prescribed methods other than developing their own innovative solutions, and in the end, this rigid structure just suppresses the original thought and leads to stagnation of the ideas. And it also slows down the decision-making.

If you think of it, no matter what the engineering team does, the micromanaged team must often wait for the approval from the higher-ups before proceeding with ideas or projects. No approval, no do, because it's all tightly controlled. And this slows the innovation process, and the timeliness of decisions also suffers because to have fast decision-making, people should be making decisions on the ground by themselves for the benefit of the project or the mission. And waiting for approval just results in the lost opportunities and reduced responsiveness, and it doesn't impact a company's ability to respond to the market needs.

And then it leads to a broader impact on the revenue of the company and the company being able to survive. And you're not enabling decision-making. Are you really getting the best out of your people? And especially, like you mentioned, in the moment when you need to make a decision, are you empowering your people who you've hired to do these things to do it?

And if you're not, not only does it slow down your decision-making, I think it just completely deconstructs your entire process for building really highly effective teams and projects that come out of that. It can create, I think, a very flat culture where it's kind of like command and control, right? And that nobody wants to work in that either. So I agree with that.

I think that's a significant negative impact of micromanagement. Sounds good. And one of the things I've heard before is that micromanagement is seen as over-management because there's a flood of low, low, low directives driving everything hard. In fact, it's a form of under-management because to be an effective manager, you have to be focusing on guiding your team.

We discussed you can drive from the front, you can drive from the back, delegate and all the good stuff. And in the case of micromanagers, they overload themselves by taking on the work their team should be doing. And then this literally leaves no time for them to develop the teams, to take care of the teams, to give them what they need to be successful and to get results. So they under-manage as a result.

So what are your thoughts on this? Oh, I 100% agree with that. I mean, and I'll also attest as an engineering manager, especially early on as being a manager, it was hard for me to sort of separate from the day-to-day task of engineering and kind of trust that to other people. I pushed really hard against the need or the desire to want to like, oh, if I just jump in, I can help this.

If I just jumped in, I feel like I keep the program on track. Certainly I did at times, you have to, but I really tried really hard to push against it. It was not easy. And I think what I learned over time was two things.

One, when you show trust in people, right? When you show that respect, the people that are your best employees really appreciate that. And they're going to really come out swinging to help support you in that regard, because they're going to appreciate the opportunity. They're going to appreciate that you actually did not micromanage them.

And so that's really important. And it really shows how you appreciate the people that they're there for you and the people you've hired to do the job. And secondly, as a manager, that is the main thing you can do at scale. When you can properly delegate, when you can properly show trust, and you can probably say, look, I am not going to step into everything.

It enables you to A, have a clear head as a leader to make good, more effective decisions, more time to contemplate those decisions and stay at a level where you're going to provide a significant benefit to the team. And number two, you can scale. You can be able to focus on other things. And I think that's the biggest challenge.

I think a lot of times, many people can manage a small team of three or four or five people few projects. I mean, that's pretty much in most people's wheelhouse, as long as you know what you're doing and you can manage that. But if you want to scale to 10, 20, 50, 100 people, you cannot at all try to dive into everything everyone does. And so I agree with you 100% that you cannot try to do everyone's work for them.

If that's your mindset, you really got to force yourself to stop, step back and say, look, in order for me to scale, in order for us to be successful, I have to trust the people I have. And if it turns out the people that you have, or some of them are not good enough to do the job, then you look at replacing those individuals or consolidating those roles. But trying to do people's work for them, thinking that it's going to be sustainable is never successful. Does that make sense?

It does. So it sort of brings this next question, or the question is, what does the org do if it discovers that they have a micromanager in their midst? And many organizations don't actively measure the impact of micromanagement. But I think it's essential to do and it's essential to know, especially within the engineering teams.

And one of the tools could be, actually it's a great tool, is regular surveys that assesses how the team is doing and what is the input on how managers behave, if there are signals that the team is overworked and overdriven without giving the agency. But once the organization identified that they have a micromanager, this should start with making sure that they provided coaching, they provided leadership training, bosses of the micromanagers need to work harder, they need to monitor the situation, making sure that progress is made.

Now, what does an org do if after a period of coaching, a manager doesn't show any improvement in their ability to lead without micromanagement? Then I think the unfortunate reality of it is that those people may need to be let go, because the toxic effect and impact of micromanagement goes beyond the individual teams that they're managing and impacts the entire org. If they cannot immediately let an individual go, they can mitigate it by reducing the span of their control, maybe giving them smaller teams and maybe transitioning them to roles where they will be contributing as an individual contributor, where the only thing which they are responsible for is their individual output, which is what they're doing anyway, and then instead of letting them manage people.

So this might allow them to continue adding value to the org while minimizing the damage caused by their micromanagement style. What are your thoughts? No, I agree with you. I think one thing I would say is I think it's extremely important to survey teams in a non-intimidating way, certainly not, you know, just to gauge really how the teams are.

And you have to kind of dissect that too. Just because team members think they're overworked and think they're being micromanaged may not always be the case. So you got to kind of look at it through multiple lenses. The other thing I would also say though, while I do believe it may be necessary to remove a notorious micromanager from that role and find a better position, I think in this particular case, I would take a slightly softer stance on that because I think most times micromanagers get that way, again, because they're in a culture of mistrust around them.

They probably never had really good disciplines and habits built up to be a good leader, be good manager. And so it's a byproduct of a lot of that. And I think there should be an opportunity for the team to come together and say, okay, we feel overwhelmed because we feel like we're being micromanaged. We understand the need and the ask of what our management wants, but here's how we think it can be better.

Would you partner with us from direct to manager or in a team setting to say, how can we work this better? And then the manager to be able to say, okay, here are the things that I need out of you guys and I'll try my best to step back from that. And I think it should be allowed that opportunity because I think more often than not, teams are in some flavor of micromanagement. It's just how much it's really impacting the team.

And I agree with you. If you can't get beyond working together and getting beyond that, then maybe there is no other option other than removing that manager from that particular role. Because it's certainly, as we mentioned, has a very negative effect and longstanding effect to the team. So I agree with that part of it.

Can you talk to us a little bit about what advice we have for engineering managers now, after having heard how we've broken down why micromanagement is such an important area to be aware of? So yes, it's a good question. So what do we do if an engineering manager found themselves in a situation with having a micromanager boss? And I must say that it's not easy, but yet something can be done.

And I'll just try to share some suggestions on how to behave in situations like this and how to manage in situations like this. So number one, it might sound obvious, but the first and the most important thing that you're going to be doing is be an effective manager. Take care of the team. Get stuff done and take care of your boss.

So it means that build relationships with your team, build trust, delegate, empower and keep going. And make sure that that stream of micromanagement does not go through you down to the team. It's not always possible because if you're receiving a stream of orders every two hours, you won't have an option but to delegate down to the team and then the team is going to be receiving a stream of orders every two hours. But you should do your best to be a good employee to your boss, to your micromanager boss.

And what it does, longer term, if it's survivable, what it's going to do is that your boss maybe hopefully will develop a bit more of trust in you if they're continuously seeing results get done, delivered, the team taken care of. So maybe they'll feel more safe and feel more trusting in working with you and maybe you are going to suffer less and your team is going to suffer less. So what it means is that thoroughly understand what's important to your customers, to your company, to your boss, to your team.

Make it happen. And also it's important to communicate clearly. What micromanagers do not like at all or what makes them really become even worse in their behaviors is lack of communication or poor communication. You need to over communicate with the micromanager.

If your micromanager knows that things are happening, everything is fine, things are going, they're going to feel better about it. They're going to be less fearful. And they do not hate surprises. And when you communicate, focus on positives because there are a lot of good things happening.

Sometimes the things are not so good, but focus on positives and do make sure that you do communicate negatives professionally. And when you communicate negatives, the critical component it's important basic communication skill I think. When you communicate negatives or mistakes or events going in the wrong direction, don't just say that things went in the wrong direction. Do tell what you're doing about it.

Or what you're going to be doing about it. That is so much better because if you don't your micromanager will come up with his own ideas how things should be done. Like I said, you have to protect your team. So as much as you can avoid putting your direct reports in front of your boss because if you do, they'll start managing them as well.

So sometimes, you know, your boss has a role power of asking for work from anyone on your team. They'll do it. But again, make sure that your boss feels safe and they feel that you and your team are reliable. That will help a bit.

So you have to maintain professional compliance. Because you have a micromanager it doesn't mean that you should not talk to your boss or you should stonewall them. If you receive an order, you have to execute because your boss is the company to you. You have to execute.

And you'll see that they'll ask who's working on what on your team or maybe down deep in the work if you're a middle manager. You have to be truthful. You have to provide high quality responses. But again, focusing on successes, on deliverables, and thoroughly communicating timelines, what's expected and what's happening.

And the last one is that even though I'm a bit pessimistic and at the end of the day, they're not going to change. It's unlikely. And you will be tempted to leave. And if you can, my personal advice is you go and find a leader you can stand behind and you can work together.

But I have to warn that that option is not available to everyone. Because you may have a family, you may be providing for a family, you may have a mortgage, and you have a bunch of social and family responsibilities. And then you just need to soldier on. Just follow these approaches I already described and keep going.

Keep delivering because your responsibility to the company is to deliver good stuff and take care of the team. These are the four things or five things I wanted to share with our listeners. Well, thank you, Slava. Certainly a very important topic.

And I think this is really great guidance. And I think you buttoned it up pretty well by saying there's reality in everything. You can't just get up and leave so easily. And still being professional is really important.

And working through that and finding a way to have good communication with your boss and give good feedback and maybe even take on opportunity or encourage opportunity for them to delegate. Maybe they're looking for that too. So I think great stuff. Really appreciate the topic today.

Thank you, Adam. It's good to have you as a partner as always. And more good stuff is coming. And I just want to remind our listeners that we are doing this because we believe that better managers will build a better world.

And if you found this episode valuable, I encourage our listeners to share it with your network. And the complete archive of the episodes of the Effective Engineering Manager podcast and our contacts and contact details can be found at www.effectiveam.com.