Letter No. 9 hit inboxes yesterday.
In it, I did a deep dive (for a daily letter, anyway) on how you can navigate between being a hands on manager and a micromanager.
And this particular letter is free, so give it a read, but as promised, here's a quick summary here on dev.to!
At the outset, of course everyone hates being micromanaged. It destroys trust with your team, so obviously you want to stay away from it.
However, being hands on as a tech lead, engineering manager, or startup founder is inevitable and in some instances desirable. Every manager, sooner or later, will need to dive into the details, whether it's because he or she is managing a high profile project, under time pressure, or something has gone off the rails. Moreover, a lot of EMs at software companies spend a lot of their time writing code.
So the most important question is not whether you are managing details, but how the folks on your team are reacting to your fine grained management. "Micromanagement" is less of a process and more of a feeling by the one being micromanaged!
So, in the letter, I suggest two approaches to minimize the micromanagement effect. First is to check our motivations: if you're feeling the need to control your team for a variety of reasons, that could be a red flag.
Second, make sure you have a solid understanding of your team. If you don't, then use this as an opportunity to gain that understanding and gain trust with your team.
Then later in the letter, I mention that--for better or worse--there's no law against micromanagement. There are, however, some really important trust issues that we need to consider as leaders at our companies.
Without trust, your engineers can't do their best, creative work.