[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.