Live data from Hacker News

Don't add your 2 cents

sivers.org

31–40 of 248 posts

Re: Don't add your 2 cents

#31
post #19

Earlier quoted context omitted.

It's a "suggestion" from a direct superior in a hierarchical power structure. A little bit of communication isn't going to change the context. So no, it is not something simple like "bad communication". I think one of the main problems here is that people in power often feel like they have to justify themselves by giving technical feedback, even when it's not appropriate.

But there are ways of eliciting critical thought about the choices made and even about alternatives that the person in power has. It is "bad communication" in that the person in power is communicating their desire in a way that is perceived, even if just a little bit, as being a command. And I do believe there are effective ways to mitigate this.

This conversation is a great example of bad communication, if you want a reference.

Communication is not just about how you communicate, but when. Good communicators know how and when to listen, and they keep their mouth shut when it's appropriate. That's the lesson of this article. If that's not a problem for you—if you know when to speak and when to listen—then maybe this article won't help you, personally.

And if my manager was always trying to elicit critical thought about trivial and mundane matters like font choice and colors on internal tools, then I'd want them to just shut up for a moment. I'd be glad to hear what your effective mitigation strategies are for giving unnecessary advice.

Re: Don't add your 2 cents

#33
post #26

I think the suggested comment It’s perfect. Great work! Let’s ship it. has its own set of issues. Firstly, while the conversation started with "I'm looking for input", the manager has suddenly moved it into a push for delivery. If the design was ready to ship, then that won't be an issue, but if all you're looking at is a mockup, or a slapped together stylesheet, etc, then what was an attempt an encouragement has jus…

I think Sivers can make the distinction between commenting on some draft wirh feedback welcome and a demo of some feature about to be released.

Re: Don't add your 2 cents

#34
Something a very smart person advised me was to "Tell people what you want, not what to do"

It sounds so simple yet is surprisingly hard to practice. It really puts the onus on you to think carefully about outcomes you desire and explain it clearly.

Re: Don't add your 2 cents

#35
post #8

What this article misses is that genuine feedback helps us grow, and being open to it is as important as being able to deliver it in a way that doesn't take something away from the recipient. Getting others' input and adapting to it (or learning when to accept but not heed it) is crucial for getting better at whatever endeavor one is engaged in. If you have a suitable level of trust and respect between you and the pe…

I thought that was the point of the article—give people only genuine feedback that helps, not hassle them with minutia. Giving unsolicited advice to people you manage can undermine the "suitable level of trust" that you would otherwise have, if you're not careful. There is a big difference, after all, between requesting feedback from someone you respect and getting approval from a superior in a hierarchical power str…

Exactly. If this article annoys you, read it again carefully, it does _not_ argue against feedback in general.

Re: Don't add your 2 cents

#36
post #26

I think the suggested comment It’s perfect. Great work! Let’s ship it. has its own set of issues. Firstly, while the conversation started with "I'm looking for input", the manager has suddenly moved it into a push for delivery. If the design was ready to ship, then that won't be an issue, but if all you're looking at is a mockup, or a slapped together stylesheet, etc, then what was an attempt an encouragement has jus…

I think your subtle focus on the semantics of the reply highlight a common block to agile feedback loops, small batches and generally getting things done. Sorry if that's harsh but you either missed the point of the article entirely or just overlooked it, the latter possibly being worse.

The primary point IMO is "don't squash ownership" because the cost of doing so is often not fully realised. The secondary point is "don't sweat the details". You've kinda proven you don't get this yet.

Re: Don't add your 2 cents

#37
I like the way Joel Spolsky describes managers taking this even further at Microsoft back in the day.

They wanted to make sure the engineers knew that they were the ones designing the software, to the point where they would refuse to even step in and resolve a conflict between two engineers about the design. Even when those two engineers came up and asked for help resolving said conflict.

Now you've got three people in the room: a designer, a developer, and a manager. Who's the person who knows least about the problem?

Solve it yourself, guys. Perfect.

http://www.joelonsoftware.com/articles/fog0000000072.html

Re: Don't add your 2 cents

#38
post #26

I think the suggested comment It’s perfect. Great work! Let’s ship it. has its own set of issues. Firstly, while the conversation started with "I'm looking for input", the manager has suddenly moved it into a push for delivery. If the design was ready to ship, then that won't be an issue, but if all you're looking at is a mockup, or a slapped together stylesheet, etc, then what was an attempt an encouragement has jus…

[deleted]

Re: Don't add your 2 cents

#39
post #28

Tread carefully between being fake and being sincere. People will stop asking you if you give a fake answer like the article.

People who can't sincerely ignore trivial matters probably should stay out of management.

I assume GP was refering to the "great work" part, but even then it's just matter of style; the point was only to show approval without nitpicking, not emphatic congratulations.

Re: Don't add your 2 cents

#40
As an independent contributor I don't want my manager weighing in on my choices. I see them as out of the loop on the more technical aspects of my job and they should leave those decisions to me.

If I come to a more technically senior member of the team who is more knowledgeable, it is to _precisely_ ask for their opinion.

So in my mind: if you're a manager, don't bother; if you're a more senior IC, do, with the explanation of why your approach is better. You're more of a mentor at that point than a manager.

Oh, and if your approach isn't really better, just different, keep it to yourself.

Post reply on HN