Micromanagement is what managers do who don't trust their teams or feel threatened by their engineers.
If you are a former engineer in management, remember what it feels like to be micromanaged. You are not a manager because you were/are still a great engineer. If you are- your org is broken and the wrong people are in management.
It depends. My best managers have been engineers. You generally don't need a full time engineering manager for a small 4 person team. If you do, your org is probably dysfunctional.
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.
I'm happy to say that one of my managers was also the best engineer I've ever worked with. He told me he didn't really like managing but basically did it because he didn't felt like he had a choice.
You just repeated the common understanding of micromanagement, which both OP and TFA are responding to. Just repeating back the same ideas which your interlocutor thought that they already addressed doesn't make for very effective discourse.
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.
The presumption here is that engineering leadership is the best source of intelligence and ideas. That now you are in a leadership role, you have a megaphone, so use it.
This is a terrible, terrible practice.
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.
I'm not convinced you actually read the article at all. Here's just one extract of several that to me says exactly what you're saying, except it's Larson speaking:
> 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.
> If you truly do have the best knowledge, build support for your ideas through dialogue. […] Good managers build consensus.
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.
My dark perspective here is that what Will is saying is that, as the number of people under you grows, the ability of some people to completely bungle everything up without consequences goes up. And this isn't really about really bad engineers, but really bad first and second level managers, as upper levels are often quite bad at identifying performance at those roles.
So what I think will is saying is not really to not trust your engineers, but to mistrust your managers.
