Hacker News Reader

Comment by ubertaco | Hacker News Reader

[flagged]

I get that engineers have general beef with management "techniques" of any kind—the whole concept feels manipulative and/or hand-wavy—but the comments in this article are disappointing and not really up to what I expect from HN. Multiple people read the section headings (which are absolutely provocative, unnecessarily so) and decided correctly they'd get lots of internet points for writing "summaries" that are actually just caricatures of the worst management practices they could imagine someone recommending under that section heading.

The article honestly isn't that bad and has a number of interesting points to make. I recommend reading it rather than just dismissing it out of hand because of caricatures in the HN comments.

Yeah, I don't think it's useful (except to score [office] political points) to read the least generous interpretation you can. Trying to understand a position lets you better decide whether or not it actually makes sense, e.g. Chesterton's fence. Although, if we tried to fairly assess every argument we see, we'd spend all our time doing that instead of being productive, so I get why it's often wise to dismiss things out of hand, at least initially.

You can disagree with the article, but I think your parent comment is not a fair summary, e.g. w/ respect to bullets 1 and 2:

> At first, I thought, ‘This is a really unreasonable person.’ But later as I dug into it, I discovered he was right...This process of conflict mining served Larson a key lesson. “I could have just ignored him, But then I would have missed the key learning, which is that I was the one who was missing context, and needed to refine my approach.”

Maybe the parent comment was "conflict mining" itself. Often the quickest way to learn about something is to make a statement about it and then let others correct you if you're wrong.

On the other hand, "what is a power dynamic" is a fair counterpoint to that. Jeff Bezos, in contrast, said he generally withheld his opinion until the end so others wouldn't be afraid to contradict him; a powerful person sharing their idea can prevent others from sharing better ones.

I think that engineers would had better opinion of management techniques if those actually worked and if tech actually had more then a few good managers.The problem is that all too many management techniques are effectively cargo cult and all too many managers have low social skills.

A very good example of a ad social skill is to use provocative sentences and then wonder why people react to your provocation.

While I can totally see toxic managers reading this, and thinking, "Ha! I told them my management style isn't toxic," my takeaways were a bit different. I read it as being about the dangers of overcorrecting when trying to avoid bad management practice.

To play a charitable devil's advocate, here's my summary:

- You should have some understanding of what your people are working on.

- Suggesting a (potentially) bad idea is an efficient way to get people to teach you all the information you're missing.

- Rather than pinning down the perfect metrics, try to make do with the imperfect measurements that you already have. What do you want to achieve with those measurements? Focus on the end result (e.g., CEO understanding) rather than the metrics themselves.

- Don't sacrifice transparency on the altar of your shit umbrella. Protecting your team is good. Hiding things from them is bad.

I think these ideas could have been expressed better, to make them less easy to misconstrue. (I might be misconstruing the article in my summary! I'm honestly not 100% sure myself.)

If a toxic manager recommends this article and doesn't change their behavior, then that's definitely a red flag. They'll read anything and take it as vindication that they're doing the right thing.

Some amount of micro-management is key to being a good manager. If you're not directly involved in what your reports are doing, it's difficult to know whether they're doing a good job or not.

Most IC engineers are cowards that refuse to give negative feedback about a peer even when it's anonymous. In order to really know how your reports are doing, you need to get down into the details with them. I've seen way too many low performer engineers survive for years just because their manager doesn't know enough about their work to know they suck.

Micromanagement and knowing what people do are two different things.

They're anti-patterns, meaning you shouldn't follow them. Think of it as sarcasm, and the "advice" becomes what you should avoid.

At least that's how your summary reads to me.

The summary bears almost no relation to the actual article content.

The article is essentially arguing that the common management advice that circulates in our industry has caused too many engineers-turned-managers to pivot too far in the opposite direction from the caricature that OP created above, to the point where they've reached another ineffective part of the manifold of possible management styles. It argues that there's a space between OP's caricature and the traditional, ineffective engineering manager/executive and that in that space they can have real impact.

Reply on news.ycombinator.com