This week, I'm going to digress from the topic of flow and rank ladders in order to share an interesting talk I heard at a conference. Last week, I was at the C&T2009 meeting at Penn State University with our Chief Community Officer, Joe Cothrel. Although this meeting was rather relaxing for me, because I didn't have to present, I still can't believe it took me 12 hours to get there (9 hours of travel from SFO to State College connecting at DC, plus 3 hours lost from PST to EST). I stayed on campus at the Nittany Lion Inn that is a 5 minute walk to the IST building, the meeting venue location. I will not bother to recap the meeting, since a concise summary can be found in the conference program. However, one talk sparked some thoughts in my head that I'd like to share with you.
Day 2 of the conference opened with a keynote, titled "Knowledge Reuse and Novelty in Community Settings," delivered by Prof. Karim R. Lakhani from Harvard Business School. Prof. Lakhani presented an interesting experiment on collaborative innovation in the form of a MATLAB programming contest for solving an NP hard problem. Each code entry's performance is evaluated, scored, ranked, and displayed immediately with the contestant's name. Since this is a collaborative effort, any contestant may reuse and modify code submitted by others and then resubmit it as their own entry. The contest is closed after about a week and the top score at that time wins regardless of how many times one submits, how many lines of code one adds, or how much performance gain one contributes. The competition is all about reputation, collaboration, and learning; the winner only gets a T-shirt or a cap.
The results of this experiment are quite interesting!
Novelty per entry is quite low: 3.5% on average.
Borrowed code per entry is rather high: 71% on average.
Small chunks of novelty code are often reused, so they tend to have high social values. But code entries that are too novel (have too many novel blocks of code) are often not reused because they are too hard to understand. Therefore their social value decreases.
In contrary, small chunks of borrowed code are not often reused, so they tend to have lower social values. However, as the sizes (number of lines) of the borrowed blocks of code increase, they become reused more often, so their social value increases.
Winning entries tend to have few lines of novel code and many chunks of borrowed code. In fact, the amount of borrowed code is twice as predictive of top performance as novelty.
Finally, collaborative innovation almost always leads to a more optimal solution in shorter amount of time.
Since all communications in a community are persistent and are made available through the internet to the rest of the world, a community is a fertile ground for collaborative innovation. Although the amount of novelty per post is usually negligible, through many iterative refinements by many users from different backgrounds, the solution is often highly optimized and very innovative. This method of innovation and optimization is actually very similar to how evolution optimizes certain biological motifs through natural selection. Computer scientists have found this optimization method so effective that they invented the field of evolutionary computing through biomimicry.
Now, how would you like to run a similar type of collaborative innovation "contest" on your community? Lithium is geared up for a new product that will enable you to reuse the great content in your community, collaborate, innovate and produce highly valuable knowledge base articles. Watch out for our Tribal Knowledge Base (TKB) products announcement soon!
... View more
Previously, I have blogged on using the principle of flow to build ranking ladders and scale them to match the skill level of the superusers in your community. Because these blog articles are the foundation for this blog, I strongly recommend reading them first if you haven't. They can be found here:
1. Spacing the rungs of your ranking ladder
2. Know your superusers!
Flow with your most prolific superusers
In a benchmark study I conducted last year, we found that healthy and vibrant communities that have many superusers generally have a large number of ranks. In fact, the benchmark list of top communities has an average of 31 non-role-based ranks (ranks that are achievable through participation). If we include role-based ranks (that were assigned), the average is 59. Among these top communities, the number of ranks goes as high as 134 ranks. But does this apply to your community? The important questions are: How many ranks does YOUR community need, and how many is enough?
The answer is that you need as many ranks as necessary to keep your most active superuser engaged. The exact number will depend on how prolific your most active superuser is. I will illustrate this with the calculation on Lithosphere again. Last time we've designed an optimal ranking ladder for Lithosphere. The post requirement for each rank are: 3 posts, 9, 18, 30, 45, 63, 84, 108, 135, 165, 198, 234, 273, 315, 360, 408, 459, 513, 570, 630, 693, 759, 828, and finally 900 posts at the 24th rank. We've also calculated the post rate for all users who have been in the community for more than 2 weeks and sorted them. If you look at the previous blog, you will see that ScottD is the most active superuser on Lithosphere (he also happens to be our community admin, but let's ignore that for now). He has posted 451 messages in total and his post rate is 1.16 posts/day. If ScottD wasn't our admin, he would be on the 16th rank now. So the proposed rank ladder with 24 levels is definitely enough for now.
A natural question is when will this rank ladder become insufficient? If ScottD posts 450 more messages, his post count will exceed 900. After that, his contribution will no longer be rewarded by this ranking ladder. Soon after, he may become bored with the community. How long would that take? Since we have ScottD's post rate, 450 more posts would take him about (450 post)÷(1.16 posts/day)=388 days. So in a little more than a year, it will be time to adjust this ranking ladder. What do we need to do a year from now to keep ScottD engaged in his personal flow state? Add more ranks! But how should we set the rank criteria? Remember, if it's too easy, ScottD will be bored, and if too hard, he might become frustrated and leave.
Note that the gap between the 23rd and 24th rung of the ranking ladder is (900-828)=72 posts. For typical Lithosphere superusers with post rate of 0.851 posts/day, this will take them about (72 posts)÷(0.851 posts/day)=85 days, which is almost 3 months. Even for ScottD, the most prolific superusers on Lithosphere, it will take him about (72 posts)÷(1.16 posts/day)=62 days, which is about 2 month. This means the gaps between the top rungs of our existing ranking ladder is already challenging for our superusers. So after the 24 linearly incremental ranks that are designed to engaged the superusers of Lithosphere, it is a good time to switch to the arithmetic progression (a.k.a linear progression), which has a constant growth rate. The logical choice is to continue the rung spacing between the top ranks of the existing ranking ladder. How many ranks we add depends on how soon we want to adjust the ranking ladder again. If we want to challenge ScottD with the appropriate difficulty for 1 more year, we will need to add at least 6 ranks, starting with the 25th rank requiring 972 posts, and then spaced evenly every 72 posts thereafter.
Why wouldn't we just add 60 more ranks and be good for the next 10 years? You can, but I certainly would not recommend that because ScottD's capability may change. Perhaps another more prolific superuser will come along, or maybe some other superusers will surpass ScottD. So we may need to change the spacing of the linear progression again the following year. In general, it is a good idea to re-compute the post rate of your top superusers yearly (or semi annually) and adapt the post criteria to keep the "flow" with your superusers. Alternatively, if you have a superuser MVP program, you can also switch your top contributors to an assigned-rank system to build a more personal relationship with your superusers.
Next time we will add some mysteries and surprises to spice up your ranking ladder and explore what happens after we switched the ranking criteria over to the arithmetic progressions. Come and follow my update at mich8elwu. May the flow be with your superusers!
... View more
An important mechanism for getting into the state of flow is to have a balance between ability and challenge. In a community, this means having a set of ranking criteria that matches your superusers' ability. If the criteria are too easy, superusers will quickly reach the top rank and become bored. But if the criteria are too difficult, superusers will become frustrated over their lack of advancement. In either case, the risk is that superusers will give up trying and abandon the community eventually.
Know your superusers!
Knowing your superusers is the key to designing a ranking structure that matches their capability. This is done by computing the post rate for all users that have registered for more than 2 weeks on the community. I will illustrate this calculation with Lithosphere as an example (see screen shot). As of June 6, 2009, Lithosphere had 524 members who have registration age of more than 14 days (2 weeks). Column B shows the total post count by these users (including blogs, ideas, comments and replies, but excluding deleted messages). Then I divided each user's post count by their respective registration age in days (column C) and sorted the resulting post rate (column D).
Now, if you believe the 90-9-1 rule, the top 1% (the 99 percentile) should be your superusers. In our experience, the fraction of superusers consists of only about 0.1% of the community population. Sean O'Driscoll also claimed that only 0.5% of the members in his data are superusers (see Interview with superuser guru Sean O'Driscoll from our 2009 Customer Conference). If we use our conservative estimate of 0.1%, the capability of Lithosphere's superusers is simply the 99.9 percentile of the post rates. Capability, in this example, means how fast your superusers can post. Using Excel's percentile function, you can calculate the 99, 99.5, or 99.9 percentile values from the post rates (column D). From the screen shot, we can see that the 99.9 percentile post rate is about 0.851 posts/day. This is the approximate capability of the superusers on Lithosphere. The superusers on your community will have a different number, and communities with very active superusers will have a larger number. I've certainly seen communities with superusers posting up to 35 posts/days. Armed with this knowledge of your superusers, you can now scale your community's ranking ladder so that its ranking criteria match your superusers' capability.
Our empirical data suggests that, on average, community members expect a promotion to higher rank once every month. This would require an average of 12 ranks in 1 year, or 24 ranks in 2 years. Using the ranking criteria formula I presented last time, we can calculate the post requirement for the 24th rank. If we use the incremental difference of 10 as in my previous blog, then c(24)=(10/2)×(24+24 2 )=5×(24+576)=3000 posts. For Lithosphere superusers (posting 0.851 posts/day), this would take them roughly 3525 days or 9.7 years to reach a post count of 3000, because (3000 posts)÷(0.851 posts/day)=3525 days. Clearly this ranking criterion is too challenging for the Lithosphere superusers. At 0.851 posts/day, we can only expect the Lithosphere superusers to post about 621 posts in 2 years, since (2 years)×(365 days/year)×(0.851 posts/day)=621 posts. Even if we make a wild speculation that the superusers capability will double in 2 year, this would only brings the expected post count to 621×200%=1242 posts, nowhere near 3000 posts.
Clearly, we need to rescale this ranking structure. With simple algebra, I solved for the incremental difference as a function of the post criterion from the formula I presented in my previous blog article:
But what do we plug in for the post criterion c(n)? Since Lithosphere is a young community, the superusers definitely have room for improvement. I will assume a 20% yearly increase in the superusers' capability, so that their expected post count over 2 years could potentially reach (621 post)×(120%)×(120%)=894 posts. Therefore roughly 894 posts should be the proper post requirement for the 24th rank, hence d=2×(894 post)/(24+24 2 )=1789/600=2.98. Rounding this to 3, we may now generate the optimal ranking criteria that are match to the capability of the superusers on Lithosphere. The post requirement for the first rank is 3 posts, then 9, 18, 30, 45, 63, 84, 108, 135, 165, 198, 234, 273, 315, 360, 408, 459, 513, 570, 630, 693, 759, 828, and finally 900 posts at the 24th rank. Even if Lithosphere's superusers did not improve their capability at all, they would have gotten approximately 621 posts in 2 years and ascend through 19 ranks requiring 570 posts.
So, is your ranking ladder too easy or too difficult for your superusers? A sanity check by computing the post rate of just the top users on your community and comparing that to the post requirement of the top rank can quickly tell you if your ranking structure makes sense. A ranking structure that is design to "flow" could engage and captivate your superusers with superior efficacy. Next time we will answer a question that every community manager once had, "How many ranks do I need, and how many is enough?" Stay tuned at mich8elwu.
... View more
Hello and welcome back. It's been a while, so we'll review a bit throughout this article. Last time I described the concept of flow and discussed how it is governed by an individual's abilities and the challenges he encounters. I also talked about the connection between flow, gamers and superusers. In this miniseries of blogs, we'll apply this to optimize the ranking structure for your community. We all know that reputation matters. Here, we will show you the details that make it work.
Spacing the rungs of your ranking ladder
Previously, we discussed how games transport players into flow. A well designed game usually has many levels. with the difficulty between levels increasing slowly so that the gamers can easily find challenges that match their skills. By extrapolation, an engaging ranking ladder for the superusers should mimic the gradually increasing difficulty levels of a game. Although the ranking criteria may depend on any combination of metrics we collect, I will use the most common criterion, post count, as an illustrative example.
A common mistake that many communities make is to use the convenient geometric progression as the post criterion for promotion to successive ranks. A geometric progression is a numerical sequence where successive terms are obtained by multiplying the current term by a fixed common ratio. For example, the post requirement for the first rank might be 10 posts, and then successive ranks require 20, 40, 80, 160, 320, 640, 1280, etc (blue ladder). Geometric progressions are terrible as ranking criteria because they grow very rapidly. In fact, the growth rate of geometric progressions is exponential! The example sequence above, with a common ratio of 2, grew over 1000 in just 8 terms.
So how should you space the rungs of your ranking ladder? There are two possible solutions. First is an arithmetic progression (a.k.a. linear progression), where the successive terms are obtained by adding a fixed value to the current term. For example, the first rank might require 10 posts, and then the higher ranks require 30, 50, 70, 90, 110, 130, 150, 170, 190, etc (red ladder). Because arithmetic progressions grow more slowly than geometric progressions, they are better suited for ranking criteria. However, because such ranking criteria are very regular, they may be too predictable to challenge highly competitive superusers.
If you want to challenge your superusers, I recommend using a sequence with a linear increment, where the difference between successive terms grows linearly. For example, the first rank might require 10 post, then subsequently, 30, 60, 100, 150, 210, 280, 360, 450, 550 etc (green ladder). Unlike the arithmetic progression, where the difference between successive terms is always 20, the difference between successive terms of this sequence increases linearly: (30-10)=20, (60-30)=30, (100-60)=40, etc. This sequence can be generated by the following ranking criteria formula,
where d is the incremental difference between successive terms and n is the rank number. The example I presented above has an incremental difference of 10, so it can be generated by . You can easily check that the third term is 60 = (10/2)(3+3 2 ) = 5×(3+9) = 5×12, and the forth term is 100 = (10/2)(4+4 2 ) = 5×(4+16) = 5×20, etc.
Keep in mind, the key is to have small gaps between the rungs of your ranking ladder. An ideal ladder might start with a geometric progression, since the early terms of a geometric progression are fairly closely spaced. As the gaps between the ranks increase, you can control them by switching the ranking criteria to a linear incremental scheme. And finally, you can move to an arithmetic progression to prevent the gap size between ranks from growing so large that it is nearly impossible to move up the ladder.
Now that you know how to build your ranking ladder, next time we'll scale it so that the ranking criteria are tuned specifically for the superusers in your community. Stay tuned at mich8elwu.
... View more
Welcome to my blog and thank you for the comment and the kudos. I'm glad you find this article unusual and interesting. Rather than just giving a bunch of hand-waving advice, I hope I can use this blog to give you a deeper theoretical understanding behind our best practices. I hope you will find future articles as enjoyable as this one.
... View more