[lolinder]

Your summary of this article is unnecessarily dismissive and misleading. It might be an accurate summary of what you saw in organizations that purported to be following this guy's advice, but I think we should let the article write its own tldr. Here are some of the key extracts that capture the actual ideas, which are in each case very different from your summary:

Yours: > 1. Micromanage early and often

Theirs: > New engineering managers are often advised to “step away from the code.” But an extremely high-functioning exec understands the domain they are operating in at some level of detail. As you get too far out of the details, you just become a bureaucrat. Too many well-meaning engineering managers end up as bureaucrats.

Yours: > 2. Measure, and whatever you're measuring, act like it's truth and that you know best.

Theirs: > "I think where I’ve gone wrong in the past, and where engineering leaders get into trouble, is by pushing back. They focus on saying ‘This is a terrible way to measure,’ instead of saying, ‘Let’s start here and drill in until we can understand the limitations of measuring this way."

Yours: > 3. Listen to the curmudgeons and the naysayers because they are the true sources of knowledge.

Theirs: > “I’m a big believer in bringing folks into the room so that they can represent themselves rather than having small decision groups. I like working out problems in larger groups where you can hold people accountable for showing up in thoughtful and effective ways,”

[jujube3]

1. Managers ARE bureaucrats, though. That's what the job is, integrating employees into processes. If you want to be a principal engineer doing architecture, that's a different career track than management.

2. You should not "get into trouble" for pushing back on flawed metrics, as long as the pushback is actionable and constructive. No metric may indeed be better than a bad metric in a lot of cases.

3. If you're "bringing everyone into the room" to make engineering decisions then either you have a very small company, or you just treat all engineers as juniors (meshes well with constant micromanagement, of course). Google doesn't "bring everyone into the room" to make tech decisions about networking, they bring the networking experts into the room (the "small decision groups" the author hates).

In summary, it all sounds very Dilbert.

[itsdrewmiller]

1 - I don't think he's trying to use bureaucrat precisely here - he's saying that the role of engineering manager is more valuable if they understand their domain vs. if they do not. This seems uncontroversial; staffing decisions for projects are more likely to be made correctly when those projects are understood.

2 - "should not" and "will not" are not the same thing. A huge part of bridging the divide between general management and engineering management is finessing the issue of performance/productivity measurement.

3 - Yeah I agree, I like a lot of Larson's stuff but not this. I kind of wonder how much of it is even real vs. just posturing; as you say it doesn't scale well at all, and he's worked at very large companies.

[jujube3]

Part of a manager's job is to suggest better measurements if the ones that are in use are flawed.

[lazyasciiart]

I used to work for someone who believed in 'bringing everyone into the room'. It was fine when that meant a team of 7 people, but he got promoted and kept doing it with 25 or 40 people, mostly irrelevant and mostly unheard. He once scheduled a meeting "in case anyone had something to say". It's probably clear that I didn't find him effective.