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.
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.
I find it extremely rare that a source of issue is the former and relatively common that I’ve been confusing or incomplete in my own guidance. If it’s in my head only, it doesn’t exist for my team and I need to fix the issue at the source (me) and, in so doing, that might change the engineering course and/or estimate.
(I have also accidentally undermined my team unrelated to the above; IMO, the best response there is to acknowledge it and try not to repeat it, because if you do, people in the company are prone to try to exploit that to drive outcomes that they think is best for the company. That’s fine, but it may undermine your ability to lead change in the company and cede it to others.)
Here's what OP said:
> This isn't exactly "micromanagement" (and the article says as much) but great eng leaders not only understand things at a lower level of detail, but they're able to communicate with their team in a way that doesn't feel like micromanagement at all.
Do you disagree with this? If so, why?
If you truly do have the best knowledge, build support for your ideas through dialogue. Make engineers and other leaders feel like they own the idea.
Good managers build consensus. Good ideas build their own momentum. Bad managers use the megaphone, and push their ideas by avoiding dialogue. Even if their ideas are implemented through micromanagement/force of will, they do not stick, because no one else feels ownership.
Larson seems to think that engineering excellence from ICs is synonymous with doing what your manager tells you without question.
> It's key to not confine your conflict mining strategy to your peer group on the leadership team. “You can usually get buy-in from other executives pretty easily, but it’s much more difficult to get buy-in from people with the most context around a given problem,” he says, “Their opinion is most valuable because they are the ones who live in the details. You can’t lie to them. They know the truth of how things run.”
This immediately follows an anecdote where he talks about listening to an engineer and realizing that his approach was wrong and the engineer was right. The whole section on "micromanagement" is really about this—get down into the weeds with your engineers and listen to what they have to say.
I get from your other comment that you have had bad experiences with people "applying" Larson's ideas in the past, but I'm really not seeing that at all in this text.
This sounds like good ideas. And also sounds a lot like what I just read in the article…
I don’t think there was any presumption that eng leaders are the “best” source of ideas. But there is a presumption he tried to communicate that they should participate, because they have experience, rather than recuse themselves from technical decisions.
I will say though, if you're going to do both, do a good job, meaning one you'd expect of your reports. Don't be a manager that hands off his half-working project "to take it over the line." Finish your work.
Right. The other comment said that people don't move into management because they are a great engineer. That doesn't mean managers haven't been engineers.
So what I think will is saying is not really to not trust your engineers, but to mistrust your managers.
There's a middle-ground between micromanaging and making sure high-level decisions are deeply sound. The second point of the article is pretty much this again: make sure the decisions are based on tangible facts, and not on chimeras.
An author who deliberately abuses terminology is someone whose work I do not trust.
I'm not even sure how much I think it matters though, I think more important is that you know where you stand in terms of reporting, and that you're able to 'code-switch' as it were appropriately for a less technically inclined person. Are engineering leaders that 'understand things at a much lower level of detail' really 'the best', or are they just the ones that make it easiest for us?
(Maybe you could argue there's not a difference, but I don't think it goes without saying that the ability to communicate to technical & non-technical alike is not a valuable skill, or that it shouldn't be required.)
> “The core challenge for engineering execs is they have to wear three different, kind of opposing hats. The best ones can toggle back and forth between them deftly.”