4 ms·

Some rules I follow: - Correct in private, praise in public. - Correction needs to be proportional to what happened. - Employee level matters. For example, a

Some rules I follow: - Correct in private, praise in public. - Correction needs to be proportional to what happened. - Employee level matters. For example, a manager should be gentler with a junior IC than a SVP. - Always be direct and specific. - Keep issues internal. Customers should only see a united front, that also takes ownership of problems. - Think it through, don't correct while being emotional.

101404 7y ago
That's a good list. I would add - Listen, because maybe they are right after all
- matwood 7y ago
  Of course. Being a good manager/teammate/human is listening and admitting when you're wrong.
chrismdp 7y ago
Nice list.
sulairris 7y ago
All very good advice, just pull them aside, not out of sight just out of ear shot
downerending 7y ago
- Ask yourself whether you really need to take action, especially if you're not the person's manager. There's a lot to be said for keeping your mouth shut.
bsder 7y ago
Also, I can praise in email or in person. If I'm admonishing, it will be privately face-to-face unless I absolutely can't otherwise. Quite often I'm trying to be gentle, but email just loses too much context and it comes across as me being genuinely upset.
arikr 7y ago
- Only correct for things where the benefit of the correction outweighs the reduction in motivation that often comes with being corrected (e.g. if it's a critical correction, do it! but if it's a non-important benefit, consider skipping it)
- Igelau 7y ago
  > a non-important benefit E.g. "this will make me look so much smarter"
  - thewebcount 7y ago
    Ugh, I have to deal with someone who is bad at this. He regularly sends out emails that include all the devs pointing out that someone broke the build (worth pointing out if they didn't already see the automated email - not worth humiliating them in front of the whole team), and then also tries to show the fix that will be needed. On the one hand, when he's right (which is often) it can save some work, but on the other hand, he's not always right, and he always sounds like an ass. I've repeatedly asked management to have a word with him about it, but they haven't because he's a valued team member and they don't want to rock the boat. I ended up blowing up at him over email about it and he's definitely been less of a dick to me about these things, but he continues to be a dick to everyone else about it because it makes him look smarter. It's pretty irritating and I never want to have to work with him again because of it.
    - TheSpiceIsLife 7y ago
      Anonymously gift him the book The Asshole Survival Guide.
    - mcv 7y ago
      Don't you have a code review tool? That's a more productive way to channel corrections to other people's code.
- refurb 7y ago
  This is a great point actually. As a manager I had to "let go" of the small stuff and let the person learn on their own. Happy to share my own opinion, but left the decision up to them. Nothing worse than getting "correction" about trivial things.
erichurkman 7y ago
Add to that that praise is often more effective than correction, particularly for more junior folks. If I can praise and lift up 95% of what someone is doing, they will do more of that, and less of the 5% that I'd otherwise like to see be done better — unless that 5% has a disproportionate amount of damage to the organization.
kovac 7y ago
Really good list, thanks for sharing.
zelphirkalt 7y ago
> - Correct in private, praise in public. This is very good manners and also the default in some cultures, a huge humiliation to do otherwise. On the other hand you might have people, who will always argue against anY correction you have and correcting in private makes it seem for them, that the discussion is 50-50, that it is only you telling them something is wrong and their opinion is as good as yours. It might not be worth correcting, unless critical, in such cases though.
minipci1321 7y ago
Great list. + When stating the issue, avoid using "You are/were", prefer "You did/didn't do". EDIT: and especially, absolutely avoid saying "You will never"

101404 7y ago

That's a good list. I would add - Listen, because maybe they are right after all

matwood 7y ago
Of course. Being a good manager/teammate/human is listening and admitting when you're wrong.

chrismdp 7y ago

Nice list.

sulairris 7y ago

All very good advice, just pull them aside, not out of sight just out of ear shot

downerending 7y ago

- Ask yourself whether you really need to take action, especially if you're not the person's manager. There's a lot to be said for keeping your mouth shut.

bsder 7y ago

Also, I can praise in email or in person. If I'm admonishing, it will be privately face-to-face unless I absolutely can't otherwise. Quite often I'm trying to be gentle, but email just loses too much context and it comes across as me being genuinely upset.

arikr 7y ago

- Only correct for things where the benefit of the correction outweighs the reduction in motivation that often comes with being corrected (e.g. if it's a critical correction, do it! but if it's a non-important benefit, consider skipping it)

Igelau 7y ago
> a non-important benefit E.g. "this will make me look so much smarter"
- thewebcount 7y ago
  Ugh, I have to deal with someone who is bad at this. He regularly sends out emails that include all the devs pointing out that someone broke the build (worth pointing out if they didn't already see the automated email - not worth humiliating them in front of the whole team), and then also tries to show the fix that will be needed. On the one hand, when he's right (which is often) it can save some work, but on the other hand, he's not always right, and he always sounds like an ass. I've repeatedly asked management to have a word with him about it, but they haven't because he's a valued team member and they don't want to rock the boat. I ended up blowing up at him over email about it and he's definitely been less of a dick to me about these things, but he continues to be a dick to everyone else about it because it makes him look smarter. It's pretty irritating and I never want to have to work with him again because of it.
  - TheSpiceIsLife 7y ago
    Anonymously gift him the book The Asshole Survival Guide.
  - mcv 7y ago
    Don't you have a code review tool? That's a more productive way to channel corrections to other people's code.
refurb 7y ago
This is a great point actually. As a manager I had to "let go" of the small stuff and let the person learn on their own. Happy to share my own opinion, but left the decision up to them. Nothing worse than getting "correction" about trivial things.

erichurkman 7y ago

Add to that that praise is often more effective than correction, particularly for more junior folks. If I can praise and lift up 95% of what someone is doing, they will do more of that, and less of the 5% that I'd otherwise like to see be done better — unless that 5% has a disproportionate amount of damage to the organization.

kovac 7y ago

Really good list, thanks for sharing.

zelphirkalt 7y ago

> - Correct in private, praise in public. This is very good manners and also the default in some cultures, a huge humiliation to do otherwise. On the other hand you might have people, who will always argue against anY correction you have and correcting in private makes it seem for them, that the discussion is 50-50, that it is only you telling them something is wrong and their opinion is as good as yours. It might not be worth correcting, unless critical, in such cases though.

minipci1321 7y ago

Great list. + When stating the issue, avoid using "You are/were", prefer "You did/didn't do". EDIT: and especially, absolutely avoid saying "You will never"