To me this is completely orthogonal to "micromanagement", which is a real problem whether or not you understand the system your team is building.
You absolutely will be a better engineering leader if you a) understand deeply the system your team is working on (though perhaps not all the corners) and b) maintain enough technical knowledge to keep up with changes.
To my mind though micromanagement, on the other hand, is the art of making decisions for people when they don't need it, and leaving your team unable to progress without you hovering over the work.
In this view micromanagement is always a poor choice, even worse if you don't know enough to make good choices for those team members.
I suppose the steel man version is that in an effort to avoid making that mistake, inexperienced managers back off too far and don't understand enough about the work anymore. This is in my experience a real problem, but needs a different name.
It's often the case where a good senior technical leader/manager could do the work most or all of the team members, and in the case of more junior ones, probably do it much more efficiently also. But they can't do that and be effective at their own role. Group velocity of the team is highest when they mostly coach from the sidelines.
I think you're correct here that "micromanagement" in the article is a poor word choice.
It's unfortunate that so much writing (especially prescriptive writing) uses inaccurate terminology for the sake of effect. It's usually to the detriment of readers/listeners being able to soak in the wisdom that's there, as they get tripped up by the poor wording.
For example, I can 100% get behind the "Engineer" level advice for the "Micromanagement" section. (Namely, have a high bar of excellence, for example when reviewing others' code.)
But as you point out, this isn't really micromanagement.
You absolutely will be a better engineering leader if you a) understand deeply the system your team is working on (though perhaps not all the corners) and b) maintain enough technical knowledge to keep up with changes.
To my mind though micromanagement, on the other hand, is the art of making decisions for people when they don't need it, and leaving your team unable to progress without you hovering over the work.
In this view micromanagement is always a poor choice, even worse if you don't know enough to make good choices for those team members.
I suppose the steel man version is that in an effort to avoid making that mistake, inexperienced managers back off too far and don't understand enough about the work anymore. This is in my experience a real problem, but needs a different name.
It's often the case where a good senior technical leader/manager could do the work most or all of the team members, and in the case of more junior ones, probably do it much more efficiently also. But they can't do that and be effective at their own role. Group velocity of the team is highest when they mostly coach from the sidelines.