Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One thing about negative feedback is, that to give it to subordinates you have to tick a few boxes first, otherwise your feedback won't make things better, but worse:

- if they cannot get better because you don't provide the environment, tools, time, resources (even if you think you do), they will read your negative feedback as you having unrealistic expectations or no clue of the real world

- if you are the cause of the things you are critizising (e.g. you are the one creating chaos, taking time away from their actual tasks etc), giving negative feedback is like critizising the person who held the door open for you: extremely rude and shitty, says more about you than them.

- if you always give negative feedback, because you believe there must be always something to improve, they will start to ignore negative feedback, because it doesn't indicate whether they did good or not

- if you fail to get them on board with actually getting better. In some jobs the salary and the involvement they expect from you doesn't align. You cannot expect someone to tear out their leg for a job where they feel like they are doing you an favour. The solution is to help them getting better at something where they feel they are giving themselves a favour.

If you tick any (or god forbid multiple!) of those boxes, you are better of with not giving negative feedback and telling them on how you plan to improve those points.



> if you are the cause of the things you are critizising

Manager: "you need to spend less time helping you colleagues and more time getting work done"

Me, most experienced developer on a team of 75% newbies, without a lead or even official senior developer: "Wat?"


I always wondered how the stories in r/MaliciousCompliance got started…


In my experience, the title “Senior developer” encompasses two separate ideas: the subject matter expert and the team leader. (One can be both.)

The leader aspect tends to be harder to pin down because it amplifies team output at the expense of immediate individual output.

Leader in this context also means helping the team avoid wasting effort on ineffective solution.


Another point, I think way too many people confuse "you should give clear feedback that shows you're judging your subordinate's work, not their worth as a person" with "you should sugar-coat feedback so you don't hurt people's feelings".

Even in an environment of trust, people still instinctively take feedback personally, as if saying "what you did doesn't work and you need to improve it" meant "you're a terrible worker and what you did just made you a step closer to getting fired". Even emotionally intelligent people do it without noticing. I've found that for my feedback to be effective, I have to make sure that what the person hears is what I mean to say, which by no means is "softening" the feedback.


Another thing I'd add to that list:

- make sure your facts are right. Ideally, make sure they are right well before you give feedback.

You can end up in awkward situations where a manager says "you promised to deliver this in a month but it's taken the whole quarter" but the one month timeline was the PM's idea, and you told everyone it would take 4 months.


This is a good one. The classic example would be: "why didn't you tell me $x"

When you told them $x in the first line of an email you sent to them 2 times.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: