Community Style Business – Rewarding Performance


The core problem with any reward system is the question as to how to ensure the reward is representative of the effectiveness. Wether it is a paycheck/compensation, a bonus or results based compensation, companies find ways to reward their employees. These rewards are not an exact science, see Corporate Scarcity – The manager’s mindset, and can contain quite a bit of disparity from effectiveness.

Community Style Business approaches the problem around rewards preferably through the use of non-loss obverse point systems, leveraging lead measure tasks and gates to ensure high quality services are performed. This blog post will cover various theories around CSB reward systems, along with references which I found useful.

Results Based Rewards

The core concept in community style business is that its members are rewarded proportionally to to what they contribute. This creates a problem when trying to define what and how much a contribution is. How do you identify what is or is not valuable?

There are various guidelines, and examples, on how this can be done. None of these guidelines are absolute, as it is up to the community, ultimately, to correct deficiencies when they occur.

Defining a measurement

The first step in creating a value based reward system is to define a way to measure both effort, risk & need/desirability. Typically the points should be based off of effort relative to a baseline which everyone can understand. One example of how to evaluate tasks for points is a practice known as planning poker, which will be discussed later. This point system is re-evaluated as needed every iteration by the community.

Planning Poker

Planning poker is a means by which all members have the ability to vote as to how many points a task is worth. Each time there is a large disparity in the voting the a representative from the high and low point group can voice their arguments to the group.

The site below provides a good overview and guidelines for planning poker.

Setting the bar

If planning happens on a team level or there is a disparity based on the type of knowledge someone has to have, it is often a good idea to set a bar for a baseline for each discipline. This is meant to normalize the disciplines, while still allowing for adjustments based on need/desirability. The one I’d recommend is, what could an average individual skilled in the craft get done in a set duration. This allows for both normalization across disciplines as well as eliminating a notion of inflation causing disparity.

As the organizations cash reserves build it is best practice to get a third, non-invested party to do these evaluations. This is to ensure that there are no biases toward a discipline or career lifecycle. It also helps reduce the potential for political infighting.

Need / Desirability

I’ve stated multiple times this notion of need / desirability, but I want to take a moment to really define what that means.

In a community system, we start off by assuming all normalized efforts are equivalent, no matter what the discipline. This creates a problem right off the bat. Some work requires specialization, is not something people tend to enjoy or require more end entices to get the right level of talent to do the job well. Alternatively, other jobs it’s easy to find people to work on, these are the “sexy” jobs.

The goal here is not to reduce the value of the “sexy” jobs, but to find an equilibrium with those tasks which are less so. An example of this might be someone working the night shift might get more points than someone working a day shift, if the night shift isn’t attracting enough high caliber people.

This isn’t really a new concept for business, as worker salary is a reflection of this calculation. When applied to a CSB it is expected to manifest differently. Since things like schedules and efforts are ultimately influenced by a community of individuals working, more variation is expected to occur over time, as individuals find the niche which best fits their life. Rather than a stick approach, CSB tends to be best with a carrot.

Defining results not method

While lead measures are useful, they shouldn’t be the only mechanism which is used. Often times when looking at an objectives there is the work done which directly contribute and those which correct deficiencies along the way. A good example of this is a software developer & a software tester. In these types of scenarios there are two approaches which can be used: distribution of existing value or value created for the corrective action.

Understanding the impact of imperfection

The example of a software developer is a good example of missed potential. The reason for this is that if the software developer wrote perfect code, the effort needed by the software tester is minimal. Their job is to just verify the expected results. The problem is that perfect code is very hard to write for many various reasons. As the flaws in the software are discovered, the amount of effort given by both the software developer and tester multiply.

Distribution of existing points

The above scenario lays out a real life scenario, of which happens every day. With a distribution of existing points philosophy, the completion of the goal is seen as the value. There for efficiency is rewarded, but higher efforts will not be recognized. Points are distributed after the work is done based on the amount of effort and lead measures completed.

If applied to the scenario above, the more the tester has to work the fewer points the developer receives. The danger here is that points can reduce in value for effort pretty easily, causing the goal to become less compelling. The positive aspect here is that it rewards quality with more points regardless of time spent. This allows an individual to spend more time to produce higher quality upfront and have that behavior re-enforced.

Value created for the corrective actions

This philosophy states that those efforts directly inline with the goal will be rewarded statically. The corrective efforts will be rewarded without the scarcity of the initial goal.

The example above would be handled by the developer getting a static set of points, while the tester would be rewarded more for anything extra beyond the initial verification effort.

This method plays more nicely when looking at objectives which run longer than expected. The problem is that this method increases the value a goal is worth artificially based on how much correction is needed. The positive aspect is that important goals don’t become meaningless. The developer in the example would have to spend longer to fix the issues before his points would be realized, which also balances out the effort to reward ratio for lower quality work.

Dividing up the spoils

As I stated in the overview, the gross profit is first used to pay for all materials and expenses the community is required to pay. Once that is done, any community initiatives are taken out, things such as a rainy day fund or saving for a consultant to normalize efforts across disciplines. After those two are completed, the points from all contributors are added up, and each member’s percentage of points are calculated. The remaining money is distributed accordingly.