Incentive plays an important role in communities. We see it everywhere: community members are rewarded with extrinsic rewards such as t-shirts, stickers, gadgets, or other material, or intrinsic rewards such as increased responsibilities, kudos, reputation, or other benefits.

The logic seems seems sound: if someone is the bees knees and doing a great job, they deserve to be rewarded. People like rewards, and rewards make people want to stick around and contribute more. What’s not to love?

There is though some interesting evidence to suggest that over-rewarding your communities, either internal to an organization or external, has some potent risks. Let’s explore the evidence and then see how we can harness it.

The Research

Back in 1908, Yerkes-Dodson, psychologists (and potential prog rock band) developed the Yerkes-Dodson Law. It suggests performance in a task increases with arousal, but only to a point. Now, before you get too hot under the collar, this study refers to mental or physiological arousal such as motivation. The study highlights a “peak arousal” time which is the ideal mix of the right amount of arousal to hit maximal performance.

Dan Ariely in The Upside of Irrationality took this research and built on it to test the effect of extrinsic rewards on performance. He asked a series of people in India to perform tasks with varying levels of financial reward (very small up to very high). His results were interesting:

Relative to those in the low- or medium-bonus conditions, they achieved good or very good performance less than a third of the time. The experience was so stressful to those in the very-large-bonus condition that they choked under the pressure.

I found this choke point insight interesting. We often see an inverse choke point when the stress of joining a community is too high (e.g. submitting a first code pull request to your peers). Do we see choke points for communities members with a high level of pressure to perform though?

Community Strategy Implications

I am not so sure. Many communities have high performing community members with high levels of responsibility (e.g. release managers, security teams, and core maintainers) who perform with predictably high quality results.

Where we often see the ugly head of community is with entitlement; that is, when some community members expect to be treated differently to others.

When I think back to the cases where I have seen examples of this entitlement (which shall remain anonymous to protect the innocent) it has invariably been due to an imbalance of expectations and rewards. In other words, when their expectations don’t match their level of influence on a community and/or they feel rewarded beyond that suitable level of influence, entitlement tends to brew.

As as such, my graph looks a little like this:

This shows the Yerkes-Dodson curve but subdivides the timeline into three distinctive areas. The first area is used for growth and we use rewards as a means to encourage participation. The middle area is for maintenance and ensuring regular contribution over an extended period of time. The final area is the danger zone – this is where entitlement can set in, so we want to ensure that manage expectations and rewards carefully. In this end zone we want to reward great work, but ultimately cap the size of the reward – lavish gifts and experiences are probably not going to have as much impact and may even risk the dreaded entitlement phenomena.

This narrative matches a hunch I have had for a while that rewards have a direct line to expectations. If we can map our rewards to effectively mitigate the inverse choke point for new members (thus make it easier to get involved) and reduce the latter choke point (thus reduce entitlement), we will have a balanced community.

Things You Can Do

So, dear reader, this is where I give you some homework you can do to harness this research:

1. Design what a ‘good’ contribution is – before you can reward people well you need to decide what a good contribution is. As an example, is a good code contribution a well formed, submitted, reviewed, and merged pull request? Decide what it is and write it down.
2. Create a platform for effectively tracking capabilities – while you can always throw out rewards willy-nilly based on observations of performance, this risks accusations of rewarding some but not others. As such, implement an independent way of mapping this good contribution to some kind of automatically generated numeric representation (e.g. reputation/karma).
3. Front-load intrinsic rewards – for new contributors in the growth stage, intrinsic rewards (such as respect, support, and mentoring) are more meaningful as these new members are often nervous about getting started. You want these intrinsic rewards primarily at the beginning of a new contributor on-ramp – it will build a personal sense of community with them.
4. Carefully distribute extrinsic rewards – extrinsic rewards such as clothing, gadgets, and money should be carefully distributed along the curve in the graph above. In other words, give out great material, but don’t make it too opulent otherwise you may face the latter choke point.
5. Create a distribution curve of expectations – in the same way we are mapping rewards to the above graph, we should do the same with expectations. At different points in the community lifecycle we need to provide different levels of expectations and information (e.g. limited scope for new contributions, much wider for regular participants). Map this out and design systems for delivering it.

If we can be mindful of the Yerkes-Dodson curve and balance expectations and rewards well, we have the ability to build truly engaging and incentivized communities and organizations.

I would love to have a discussion about this in the comments. Do you think this makes sense? What am I missing in my thinking here? What are great examples of effective rewards? How have you reduced entitlement? Share your thoughts…