I thought the first part about "micromanagement" was a great one. In my experience, the best engineering leaders understand things at a much lower level of detail than their title would suggest. 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.
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.
An engineer turned to the executive dark side is still an engineer, and if they use their seat at the table to keep an approximately optimal amount of engineering quality up they'll need to pay attention and micromanage the details sometimes.
Bill Gates was famous for this, about thirty years ago; Joel Spolsky wrote about it in https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev.... Maybe it was over the top, and I'm sure it didn't work all the time, but I feel like it would have contributed to Microsoft's success.
It's really a balancing act. It's also surprisingly difficult as an eng-exec with a deep eng background to correct some things without accidentally undermining those around you. Happy to provide examples of this comment is too vague.
There’s definitely a balance and even within the challenging something that smells wrong, there are grades of undermining, ranging from public pronouncement of “y’all are lazy or incompetent and I know better” to private “I think I misled you about a core constraint and that may have led you to assume the scope needed to be 4x as large in order to address that perceived constraint.”
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.)
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.
Yeah the problem when higher-ups have little care for details is that they may act on an imprecise-to-incorrect understanding of the factual reality ("the map isn't the territory", yada-yada).
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.
Doesn't the article scream loose grasp on technical side though? Maybe that's the author rather than Larson if they're different, but bits like how it turned out the senior engineer was right to be against automation, because they were using Ruby, come on. (I'm not saying the guy was wrong, it just seems poorly explained/understood.)
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.)
Re: your point about code switching - I think that's basically his point here:
> “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.”
