No manager decides to be a micromanager, but micromanagers obviously exist, so they must come from somewhere. Managers who do micromanage either say what they’re doing is not micromanaging or provide a justification for why they have to manage that way. Both of those are the result of the same underlying problem: these managers don’t understand how to give direction.
A manager giving direction can do it either of two basic ways. One way is to define the activities to do and the other is to describe the output to produce. Micromanagement is to some extent a matter of degree, which is to say providing the direction in too much detail. More often, though, it’s a consequence of providing too much detailed direction in the activity not too much detail in the output.
The simple explanation is that defining the desired output is actually hard. We spend most of our thought and energy on how to do something. We don’t think nearly as much about the product of that activity. Thinking about it less means we are less able to describe it.
To make it worse, it can be hard to describe what a good work product is. What we can remember may be hard to describe precisely, e.g. what it means for a software change to be fully verified. We also don’t always remember everything we want to describe, only realizing the omission after our delegate produces something that doesn’t meet the requirement we forgot to state. The desired properties of the product are not always apparent. They’re embedded in implicit knowledge, the things we know but don’t know we know.
On the other hand, actions are easier to see and thus easier to describe. You do one thing, then the next thing, then the next. What you’re doing is visible. Certainly there’s nuance, but they’re easier to break down into individual steps. You don’t even have to explicitly describe them. You can just say “watch this” and expect them to emulate you. They don’t need to understand the why. They don’t need to understand how you painstakingly arrived at this method after years of trial and error and improvement that you don’t clearly remember and can’t fully explain. Just… do it. It’s not that hard. And when they do get it wrong, how do we try to debug it? We want to know how they did it.
Micromanagement happens because good management is hard. It’s hard to describe the desired outcome. It’s hard to think of what is fixed and what is free. It’s hard to transfer the knowledge and judgment that allow you to assess a work product and deem it good. It’s hard to debug the expectations you gave someone because they make sense to you; how could they possibly have misunderstood? So you throw up your hands and just tell them what to do. It’s just easier that way.