Hacker News Reader

Comment by tobtoh | Hacker News Reader

As a manager, I tend to frame my feedback/opinions as 'Have you considered <something>?' or 'Can you explain your thinking behind this <feature/function/design>?'

Doing it this way, I get an understanding of their rationale and if I still think my idea is good, I can debate the worthiness of it against my employees reasoning. I feel this approach fosters a 'best idea wins' rather than a 'manager opinion trumps all'.

I agree with Derek's implied point that 'manager opinion trumps all is bad', but think it's a discredit to his staff if he doesn't challenge their ideas if he thinks he has something more worthwhile.

View on HN

It depends on the culture, but I prefer cultures where everyone, including management, gives input, and the creator picks-and-chooses. Management, even upper management, giving input shouldn't necessitate a change.

Management has a big picture individuals often lack. That's an important part of the process. On the other hand, it shouldn't dominate the process.

This post is much better than the article. The manner in which you deliver criticism is very important. When criticising somebody on their method I find it is much nicer to say "I like to do it like this..." They will then be encouraged to try your method and they might like it. You are not attacking their method.

I find it unfortunate that most people take criticism as an attack, but they do and choice of language and delivery can soften the blow and bypass their defences.

> "I like to do it like this..." They will then be encouraged to try your method and they might like it

The danger here is that this will often be interpreted as "my boss wants me to do it like this", and they will do it not because the idea stands on its own merits, but because it was the boss's idea.

I love this, I have taught few people programming and I always do it this way.

My guess is that it also depends on the level of knowledge of the person doing the task. Since they were students, there are small things that they just don's know (for example, adding a class to make it responsive).

But since I'm always challenging my own decisions, I have no problem when someone adds their "two cents" and I have to show why it doesn't work that way (or I learn something new). After a couple of times they realize I know what I'm doing.

Was going to reply along the same lines. Much better is asking questions like "Why did you choose this shade of blue?" Which leads to improved understanding from both parties: The color may be more important than the original selection merited, or the selection was chosen specifically for reasons that the Manager wasn't aware. In general phrasing this as a dialog where the Manager (expert or no) and the Do-er both work to educate each other. "Did you consider X2?" becomes a valuable question if you think the implementation selection of X1 is "incorrect" or "sub-optimal"

I agree in part. Except for "have you considered" which always sounds patronising to me. It's very clearly a disguised way of saying "you should have done..."

There's another part too which to me is; if the point that I, as a manager, am making suggestions (even valid ones) is when looking at the complete "diagram" then I've failed as a manager. The point to offer an alternative option is the point at which the team was discussing it in the first place.

Reply on news.ycombinator.com