What motivational mechanism works more effectively - penalties or rewards? I'm also interested to know whether penalties are used in modern software development teams. If they are - in what form?
ps. Please pay attention that I didn't say "monetary" rewards or penalties.
pps. I've written an article recently, on this very subject: Monetary Awards Can Work
When dealing with professionals, I find that Theory Y style management is best. Theory Y assumes that employees want to do a good job. It assumes money is not a motivator, so intangible rewards are best.
Theory X style management assumes employees are lazy, need constant direction, and are motivated by fear of punishment and cold hard cash.
When dealing with people who you need to be proactive and make their own decisions, a positive, rewarding, encouraging atmosphere will foster more leaders in your team, and that's what you need as a PM.
If penalties are used, they shouldn't be anything drastic, demotivating, or something that will make the team members job incredibly difficult. In software teams, the person who breaks the build usually is responsible for having to fix it. Although it's a type of penalty, the developer will learn from the mistake and also be able to take the leadership role on coordinating getting it fixed.
Another type of penalty might be putting a penny in a jar each time another developer finds a bug in your code. Since it's more like a game where the person with the most pennies loses, it's actually quite motivating.
Maybe the loser in the group has to be the one to go get coffee for the others that week.
To use an example outside programming, when I was in the Army, if I forgot something on my uniform, the penalty was 20 push-ups. It helped me stay in shape, served as a reminder for next time, and was a sort of game that we all laughed about, even with our Sergeant.
I would avoid financial penalties at all costs, as this is someone's livelihood! Everytime Roger Goodell fines an NFL player for making a mistake, I cringe.
UPDATE:
For rewards, the reward should also be intangible. You're not dealing with rats in a cage that you can shock and feed arbitrarily based on their choice of paths. Instead, the reward could be work related, such as giving the best engineer the opportunity to lead the team presentation of a new product feature to the CEO or a client. A reward such as this is work related, so it actually encourages the behaviors that may have helped the employee get to where they are in the first place.
Another example of a great reward would be more freedom to make decisions on the project independently. If an engineer has proven him/herself, then let him/her have more of an independent role on a project. Make this clear so that everyone knows this priviledge/right of passage was earned. (This is more for junior engineers. Senior engineers should already have earned this right.)
Someone else (Craig Villacorta) said recognition, which is what I'm alluding to with these examples, so I won't beat a dead horse.
In summary, keep in mind that while you are dealing with professionals who naturally will do their best because that is who they are, that doesn't mean these professionals are dry and don't like to have fun.
As long as the reward/penalty system is a fun thing, it can be a tool used to help improve morale.
Think reputation on Stack Exchange sites! Sure, most of us are here to help people, improve our writing skills, and learn from others, but isn't it just a little fun to see your reputation score go up??
I'd forget about typical reward/penalty approach. Vast majority of people I know who are best in their project teams don't work to get reward or avoid penalty. They do it because they feel accountable for the results of their work, they don't want to let client/their organization/leader/themselves down, they simply want to do good job, etc. Basically they dedicate 100% (or more) of their work because they believe it is a right thing to do.
If you make it all about reward and/or penalty you create the system which will be tricked or at least people will make attempts to trick it. You won't get significantly better performance if you tell the people that at the end of the project there's a huge reward. If it worked that way in sports you would always have teams rewarded best on the top, which obviously doesn't work that way.
Having said that, I'm not against rewards, but don't make it the clue of motivating people. And regarding penalties for me well-delivered critical feedback always worked better than any specific penalty.
So in short my answer for the question rewards versus penalties is "neither."
+1 to @pawelbrodzinski for "neither". However, I'll add that sometimes recognition can be a great reward. It doesn't have to be monetary or material. Many people I've worked with and interviewed really respond positively to a genuine "thank you for doing a great job." It makes them feel like people really notice and value their work. In my organization, we start our team meetings with a roundtable list of "wins". People love recognizing others and being recognized themselves in public. We also "manage up" where I'll pass along a hint to my VP that a team member did a good job on something, and our VP will actually send a handwritten "thank you" note to the individual saying something like, "I heard you were working on X and are doing a fine job. Thanks and keep it up!"
I don't have a direct answer, but a story that may tell you something to keep in mind.
Once, there was a training for leaders of a military flight school. They were explained that for learning new skills, it is best to reward good performance, but not reprimand bad performance.
One of the flight instructors immediately argued that that was wrong.
When one of his students would perform badly on a day, he would reprimand them. The next day, their performance got better. When one of his students would perform very well, he would reward them. The next day, their performance dropped. His conclusion was that reprimanding is effective, where rewarding achieves the complete opposite of what he wants.
The reality of the story is that his reprimanding or rewarding have little to do with this kind of performance changes. Flying, like software engineering, is a skill that takes time and effort to gradually learn and improve. Sometimes you will have good days, sometimes you will have bad days. But, you usually regress back to the mean - which is gradual growth.
The morale of the story for your question is: if you decide to do reprimanding or rewarding, make sure this is something based on the long term. Everybody has good and bad days, sometimes even weeks. If you act as the flight instructor in this story, you will actually end up with the mindset that rewarding is ineffective, and reprimanding works well.
Being part of a good team that accomplishes and delivers good products, being treated with respect and having a chance to grow in your craft are what I've found to be the most desirable factors for a software development environment.
If you must work in an environment where knowledge workers are treated more like 19th century factory workers (as seems to happen in some development shops) then power and money are the main variables management plays with. Power can range from having higher priority in picking vacation days or project assignments to having the ability to tattle-tale on other workers.
This is NOT, IN ANY WAY the kind of environment I would recommend nor want to operate, but that's how I've observed managers navigate those kinds of shops. Incidentally, shops run that way can only exist when there is a low cost advantage to the environment. However, once innovation and creativity become factors in winning business, these kind of environments generally implode.
Here is a post (and discussion with Pawel) you may find interesting on the topic of Teaching Engineers to Be Remarkable.
I would refer you to this video which gives several citations demonstrating that for skilled jobs, performance actually decreases with pay. (I suspect that the "overpayment" part of that statistic is a red herring, but the general point is still good.) Of course, pay is only one kind of reward, but I infer that the only kind of reward many skilled individuals really want is ongoing access to interesting problems and occasional, not over-the-top recognition.
Management through fear of negative consequences is going obsolete. Its even seeing decreasing usage in the military, which is where you would think it would prevail. Ultimately it adds far too much stress which is very detrimental to progress.
Ideally, your group should be motivated enough that you don't have to provide tangible rewards for them. If you must provide rewards, complements are probably the best, followed by project related rewards like the privilege to help in project management. But punishment should virtually never be used with employees you'd like to keep.
Neither. To most developers, what gets rewarded or punished is perceived as being out of their control, so the rewards/punishments end up getting perceived as arbitrary or based on popularity.
