[jariel]

Different situations call for different levels of intervention.

Sometimes, a manager may be very involved in some specific artifact which may 'seem' like micromanaging but really it's 'topical' management.

Often Micromanaging isn't actually inherently 'wrong' or even bad, rather, it's the emotional corrosiveness that is the problem, i.e. people just don't like to be managed in that way, but, if we were all 'perfectly and completely mature team members' it wouldn't bother us if it was appropriate. But that's hard and most people just don't like it.

That said, it can be a 'true problem' in the sense that managers are too in the weeds - and a 'true problem' in the pragmatic social aspect in that if people 'really don't like it' then it's just not going to work out even if technically it could be warranted.

There are so many managers I've seen who are really high EI, who would never dare micromanaging, because they instinctively see their job as a popularity contest. They really don't actually care about the product or outcomes, they are not built that way, they have been managing their lives through the spectrum of likability, and instinctively feel that when 'everyone is happy' they are doing a 'good job' irrespective of outcomes. In many organizations this is actually normative.

And of course, there are just a lot of bad managers out there as well, micromanaging where they should not, with no sense of making better outcomes even as they believe they do.

Self awareness is really hard.

[bawolff]

What would be a situation where its appropriate?

Either you hired someone whose competent so you should let them do their job, or they're incompetent and you should fire them and hire someone else.

[jariel]

First - different perspectives (i.e. bigger vs. narrow picture), Second - skills and competencies gaps.

First 'Special Conditions' - The gap between 'customer' and 'engineer' can often be quite large. Junior Engineers especially generally don't have an intuition for those things, and often 'the technical details' deal directly with feature orientation. There are legal issues, operational issues, so many 'bigger picture' things that are relevant. Cross-functional issues are definitely a thing, which is why a guy like Musk is probably managing a few layers deep, and 'very deep' in some specific scenarios.

Musk is a good example - because when he intervenes, because he has 'a lot of legitimacy' as 'founder and supposed genius' - people may not feel 'micromanaged' whereas if it were any other situation they very well might.

You may have a very complex code base where the architects, or Senior Devs who built the system need to intervene with a bunch of things to ensure consistency, communicate much of the 'unspoken' idioms that exist, and provide 'leadership by example' etc. etc..

For example, I trust my team members a lot more in the Java/Python domain, I almost don't trust anyone in C++ there are just so many ways to skin the cat, so many horrible anti-patterns, I've seen it all, so I like to take a really good look at the code. Often a second set of eyes helps.

On the whole, yes, micromanaging probably shouldn't be constant, but it can be consistent.

Second - there are skills (and communications) gaps in every resume. I'm literally managing a small offshore team right now, not getting adequate response when asking some specific questions. I've come to the conclusion they are literally not considering a whole pile of corner cases. I'm going to have to step in and hold their hands through a set of functions that they, for whatever reason, are not wading through very well. Fortunately, I have a ton of experience with this, and it will be ok.

This idea of 'if they are not good enough use someone else' is a little bit glib because far more often than not, it's not an option - either you have an incumbent team, budgetary/timing issues, and frankly, even if you didn't have limitations there, it's hard to evaluate people anyhow.

Finally - I will say that there are some situations where micromanaging probably is going to be constant. For very young and new developers on any kind of complex system ... they will need to have a lot of coaching and oversight. Even little things like tooling usage, which may not be 'formalized' because the team is in good sync, or the team is senior, but you have a junior who's not familiar with the git idioms on the team etc...

[bawolff]

I think some of what you describe, i would consider to be "mentoring" not "micromanaging". I at least view those differently, but i can see how they can look similar in a lot of ways.