As "workers" in general we all likely have different pictures in our minds of what "micromanagement" actually means. Maybe it's a boss who incessantly demands reports without giving you the time to complete them, maybe it's a manager who seems intent on monitoring your every move during a workday, or maybe it's your director that demands to have a hand in all technical planning and implementation.

All of these are various forms of micromanagement, and of course, this list is far from comprehensive.

There is no one "right way" to deal with micromanagement, in my opinion. Rather, the appropriate course of action will most often depend on the specific circumstances and context of the management issue you are experiencing. Sure, there are some management teams out there who would probably be very receptive to criticism of their management style by an employee. On the other hand, there are probably many others who would not take that criticism very well at all.

Herein lies the problem that I see for software engineers: what do you do when management is incapable of reforming their own process, unable or unwilling to do so at the behest of their employees.

I argue that this responsibility does not fall on the engineer, but rather on the manager themselves.

It is far too easy from a management perspective to take a stance that does offer transparency and communication to your team, but does so by way of implying engineers should be the first people to raise comments or concerns – particularly regarding management style. It is far too easy to hold a team meeting and tell your team:

Hey folks! If anyone has any suggestions regarding my management process – like how I run meetings or plan sprints or participate in codebase related work – please let me know! I'm excited to make positive changes.

This puts an undue burden on the engineer to then substantiate any claim they're making regarding the manager's process or performance. Why shouldn't we substantiate a claim against someone else? Well, it's not that we shouldn't, it's that we simply don't need to.

A technical manager's job is comprised primarily of two abstract job duties:

• Technical
• Interpersonal

This "interpersonal" duty is where this burden should lie – with the manager. Management should not only be making constant efforts to improve things in a technical context, but also a constant effort to be vigilant and cognizant of their teams' mental well-being. That is to say, when you notice an employee who is ordinarily very engaged suddenly becomes less engaged for a period of time, this is likely a signal that something is wrong.

No, it's not always micromanagement that upsets employees. However, let's pretend that in this example it is.

Meeting Burnout

I can really only speak anecdotally here: I have met very few software engineers who describe themselves as "extroverted" people. The "norm" for our industry seems to be that classic "nerd": not super social, etc. My sincere apologies if I've offended any extroverted engineers here. I'm a nerd myself :)

We do not enjoy wasting time. There is a well-known phrase in the corporate world: that meeting could have been an email! If your meetings can be emails, make them emails instead.

The main issue here is that many managers seem to believe that meetings are benign interruptions that only serve a positive purpose even if no resolution is reached during the meeting. They have this idea that if there is a potential problem, it's best to effectively set everything else aside and get together "in person" to come to a resolution.

I challenge this philosophy with this: instead, try viewing these interruptions as wholly detrimental to your team's efficiency. With this mindset you will likely only be interested in setting meetings when it is absolutely necessary, rather than whenever you feel like it.

There are loads of metrics that can be used to determine the efficacy and relevancy of a meeting. To name a few:

• Average participant count and time – are your engineers even speaking up? are they yes/no answers? does it seem like they don't really want to be there?
• Total number of speakers – if you, the manager, are the only one speaking during a meeting, it is highly likely that you could have just sent that information out in an email or Slack message. Likewise, if it is just you and two other managers talking with an entire engineering team present, this too is a useless meeting.
• Disengaging topics of discussion – what are we even talking about in this meeting? Are we asking engineers for detailed rundowns of what exactly they're working on? Are we making organizational announcements that have little bearing on the department participating in the meeting? These things cause participants to become less engaged.

The reason I bring up "meetings" at all is because they are an extremely common precursor and very strong catalyst for systemic micromanagement issues within organizations. As meetings become more frequent, management begins to normalize that frequency and the agendas for each meeting. Over time this can easily devolve into long and complicated meetings where engineers are simply grilled about their progress, and this is micromanagement. The processes that engineering managers find valuable will sometimes conflict with the processes that engineers themselves find valuable. Of course this relationship must be balanced: we need engineering managers to do their jobs, and we need engineers to do their jobs. It would be naive to suggest that engineers should dictate management process within their own department, but it would be equally as naive to suggest that management alone has the understanding, information, and tools necessary to effectively manage an engineering team.

At the end of the day, these things just need to be balanced. I would encourage managers to examine their meeting schedule and see what can be cut from it. Heck, maybe even go to the other extreme and attempt to remove all meetings from your weekly schedule. This probably won't work long-term, but it is a great way to see what you really don't need. It's like cleaning house: chances are you won't miss a lot of the junk you throw away.

Infrastructure Support

Let's first break down the term "infrastructure" into two categories here:

1. Corporate/workplace infrastructure – the tools that are provided to assist engineers in their job duties
2. Technical infrastructure – the actual servers, repositories, pipelines, etc that are involved in an engineering department or team

Both of these have varying levels of potential for micromanagement to take place. Unless a developer operations (devops) team is available, it is highly likely that the engineering team are the subject matter experts on technical infrastructure. Additionally, while management may be apt to provide effective workplace infrastructure, doing so without consulting the engineering team on their needs will often result in misguided process or tool implementations.

In short: listen to your engineers. They know what they're talking about.

Management has the ability to intensely micromanage in both of these categories without even being aware of it. By enforcing workplace processes and infrastructure that are unhelpful or sometimes even detrimental to engineering process, you are forcing your engineers into a path they're uncomfortable with. Your processes may add additional steps or work for engineers, with varying levels of value. Implementing too-strict of workplace infrastructure will sideline your engineers into what is essentially your way or the highway. This is micromanagement.

Technical infrastructure can also cause pain points for engineering teams if management is too involved with decisions around it. To reiterate though: if a devops team is present, this issue becomes much, much less severe. Generally, engineering teams and devops teams work very well together. For the most part they will understand each other and be able to communicate their needs effectively. However in an organization where technical infrastructure is to some extent management by the management team, this can turn into micromanagement. Just like you may be sidelining your engineers into restrictive, inefficient, or difficult processes with workplace infrastructure, you may be forcing your engineering team to work within a technical infrastructure that is unfit for the application or applications they are developing. This alone can bring it's own set of problems, from application efficiency and up-time to billing and financial impact based on the usage of the infrastructure in place.

Engineers who continuously raise infrastructure related problems or improvements but are shot down are extremely likely to burn out from micromanagement.

Wait, what about nuance?

Sure, an engineer suggesting a codebase rewrite or language change for an established enterprise application should have that suggestion rejected. Rejecting bad suggestions is not micromanagement, it's just good management. So I'm certainly not saying to only listen to your engineering team, but rather to make an effort to actively listen to them instead of making infrastructure decisions on your own.

Due Diligence

It is important that any manager do their "due diligence" with any action they take that affects the engineering team. The best example of this is bug tickets. When you as a manager find an issue with your application, you will most likely file a bug ticket. However in doing so it is imperative that you take the necessary steps to investigate the issue yourself first – this is called doing "due diligence".

The micromanagement in this case comes when management fires off dozens of bug tickets for issues that haven't been sufficiently reproduced, issues that are a direct result of an action they have taken that is expected, or issues with their understanding of the application. Managers will most likely not know if their ticket is violating any of these points though, so it is important for management to adopt a mindset that works with their engineering team.

In this example, I would suggest that the manager take the following steps in this order:

• Attempt to reproduce the issue at least twice. This is a great way to rule out network connectivity issues or other temporary problems that are not a result of codebase behavior. If you're receiving different errors or undesirable behavior, these should be treated as distinctly separate bugs. It is up to the engineering team to combine them if necessary.
• Gather information about the issue: what page or component of the application are you interacting with, what model or resource is being accessed or manipulated, if you have access to a debugging console collect any logs delivered there. This information will be useful for a ticket, but can also clue you into problems that you may be able to solve without the engineering team, specifically problems that do not require codebase changes.
• Use additional resources at your disposal to gather information or debug the problem: if you have access to application logs, check them. If you have access to a bug reporting portal for your app, check it. Sure, this can be done by engineering too, but if you're able to quickly identify the problem without roping in a highly paid engineer, then that is an objectively better outcome.

After you've done this due diligence, you may still need to open a bug ticket. At this point though, you will have infinitely more information about this issue than you would have had if you had just fired off the ticket from the very beginning. In most cases these hastily produced tickets would lack any type of reproduction steps (or include steps that are not accurate), could potentially combine or conflate multiple issues and slow down the debugging process for engineers, or simply be misunderstood by the engineering team due to the lack of information in the ticket.

It is very enticing as a manager who is QA'ing the last few bits of a project before release to dump any and every tiny issue they've experienced into bug tickets. This can be overwhelming for an engineering team who most likely assumed the application was in a "done" state. However if properly constructed bug tickets come in regarding the application, these are much easier for engineers to triage and resolve. The micromanagement in this case comes in when management coerces the engineering team into highly specific tasks without first debugging those issues themselves to the best of their abilities. Management is essentially dictating the implementation details to the engineering team, and while in some cases this is actually necessary, in most cases it is not.

Summary

With these three abstract concepts, an engineer can go from being free in their job to being bogged down by micromanagement:

1. Meeting frequency can interrupt engineering flow and also fosters an environment very conducive to micromanagement.
2. Infrastructure support can dictate how an engineer must implement or design certain things, and workplace infrastructure can dictate how an engineer must operate on a daily basis to complete their work.
3. Due diligence (or lack thereof) can overwhelm engineers and push them into potentially unnecessary or less-than-valuable work at the behest of management.

Ultimately what micromanagement leads to is burn out. During periods of burnout engineers often lose motivation for the work they're doing, put less effort into tasks, and have a less positive outlook on the company and their position. Burn out is avoidable. While it can and probably will happen even in environments with little to no micromanagement, taking steps as managers to reduce a strong cause of burn out will put you in a better position overall.

Conclusion

I've managed engineers, and I am an engineer myself. What I've found in my limited management experience is that most things just boil down to trust. Do you trust your engineers? Do you trust them to make good decisions when they implement a task? Do you trust them to know what the best environment is for the application they're developing? Do you trust them to stick to the estimates they've provided and alert you if things change?

If you do trust your engineers: stop roping them into meetings to discuss their daily work in detail, stop forcing them to work within technical environments that aren't conducive to their application's design or within workplace processes that make their jobs more difficult without providing substantial value, and stop giving them bug tickets with empty descriptions that you spent 3.5 seconds creating.

The average software engineer is highly intelligent and highly skilled. 9 times out of 10 they do not need a semi- or non-technical person breathing down their neck all day. It is painful, at least for me, to watch efficient processes degrade into inefficient micromanagement just because management "fires first and asks questions later" when it comes to implementing new process. It is even more painful to watch those processes change for the worse simply because a less-than-technically-skilled manager decides X is better than Y.

Trust your engineers, please, before they leave you for a better company.