Well, this is not a treatise on either😉
But, I’ve had these frequent discussions (bordering on arguments) with someone on when to compliment and when not-to. While I am always accused of being “not-so-appreciative”, my argument always was that appreciations are not for free. As I was reading the chapter “managing volunteers” in Karl Fogel’s book “Producing open source software”, I found it discussed and thought it would be a good idea to share.
Quoting from Karl Fogel’s “Producing Open source software”:
“Praise and criticism are not opposites; in many ways, they are very similar. Both are primarily forms of attention, and are most effective when specific rather than generic. Both should be deployed with concrete goals in mind. Both can be diluted by inflation: praise too much or too often and you will devalue your praise; the same is true for criticism, though in practice, criticism is usually reactive and therefore a bit more resistant to devaluation.“
And one more passage on the problem of praising for each and every small thing:
“Praise won’t hurt anyone’s feelings, of course, but that doesn’t mean it should be used any less carefully than criticism. Praise is a tool: before you use it, ask yourself why you want to use it. As a rule, it’s not a good idea to praise people for doing what they usually do, or for actions that are a normal and expected part of participating in the group. If you were to do that, it would be hard to know when to stop: should you praise everyone for doing the usual things? After all, if you leave some people out, they’ll wonder why. It’s much better to express praise and gratitude sparingly, in response to unusual or unexpected efforts, with the intention of encouraging more such efforts. When a participant seems to have moved permanently into a state of higher productivity, adjust your praise threshold for that person accordingly. Repeated praise for normal behavior gradually becomes meaningless anyway. Instead, that person should sense that her high level of productivity is now considered normal and natural, and only work that goes beyond that should be specially noticed.”
-How true! Although the whole thing is written in the context of volunteer management on opensource projects, it makes so much of sense in all human-relations!!
and he concludes this part saying –
“This is not to say that the person’s contributions shouldn’t be acknowledged, of course. But remember that if the project is set up right, everything that person does is already visible anyway, and so the group will know (and the person will know that the rest of the group knows) everything she does. There are also ways to acknowledge someone’s work by means other than direct praise. You could mention in passing, while discussing a related topic, that she has done a lot of work in the given area and is the resident expert there; you could publicly consult her on some question about the code; or perhaps most effectively, you could conspicuously make further use of the work she has done, so she sees that others are now comfortable relying on the results of her work. It’s probably not necessary to do these things in any calculated way. Someone who regularly makes large contributions in a project will know it, and will occupy a position of influence by default. There’s usually no need to take explicit steps to ensure this, unless you sense that, for whatever reason, a contributor is underappreciated.”
-I’d say this is one essay which applies to managing people everywhere, not just in projects!!!
(More on the topic on the book’s website, here)