Freeriding in teams, communities and networks: 5 tips for fighting it

One of the biggest problems in teams, communities and networks, whether co-located or virtual, is freeriding (aka freeloading or lurking or loafing) where certain team members do not pull their weight. Here are 5 things you can do about it.

Freeriding is a particularly big issue for virtual teams, virtual networks and virtual communities as research shows it is easier to break a (virtual) commitment to someone you rarely meet than a (physical) commitment to someone you see all the time.(That’s why the telephone seems to be the preferred communication channel for people who wish to conceal or embellish the truth.)
In the world of biological teams the very same problem exists – it is known as parasitism.
For example ant colonies in particular are plagued by parasitic beetles which trick the ants into feeding them on a regular basis.
5 tips for stopping team freeriding

  1. Make sure you have a real relationship with your team members
    This is easier to do this if you can physically meet the other members of your team. However it is not impossible to have a real relationship with someone you have never met – it’s just a bit harder.
  2. Develop a set of team ground rules
    Ground Rules define what constitutes freeriding and what the sanctions should be when its spotted. This can be addressed initially in a fun way such as ‘Freeloader of the Month’ awards.
  3. Only make important commitments
    Make sure that each commitment is actually important to the person making it and the person asking for it. The commitments which are most likely to be broken are the ones that seem like ‘nice-to-haves’ – it is better to have short must-do commitment lists rather than long wish lists.
  4. Have a Transparency & Reputation System
    Some of the best self-managed teams today are OSS (Open Source Software) Teams where there is no command and control structure. Things get done here mostly because of the individual team members desire to manage and enhance their reputations with their community peers. ‘Name and shame’ via a commitment register showing the live status of all commitments, which all team members can see, is one way to do this.
  5. Have a reminder system
    Even if people sincerely intend to deliver their commitments in busy teams they can easily forget. Put in place simple reminder systems (avoiding a command and control style) to help team members remember their commitments in advance of their due dates.

5 Replies to “Freeriding in teams, communities and networks: 5 tips for fighting it”

  1. The system of “mutual responsibility to goals” breaks down if everybody isn’t responsible for a common goal. The “common goal” in an open source development team might be reasonably seen as “the release date and performance criteria” (i.e. it doesn’t fall over). With teams where Sales targets and Marketing actions aren’t always 100% measurable, I suspect that there might be a division between “soft goals” and “hard goals”. There is also (in related thinking) the organisational theory that those that work in the area of most unformalised knowledge (or where their is a high degree of ambiguity involved in the task/role, or people just don’t know anything about that knowlege base), then those people wield additional power and influence. I guess this is a long winded way of saying that the best way of managing freeloading is thinking about goals, but that goals themselves can be hard to manage.

  2. Paul – you make a very good point.
    I guess I assumed “shared goals” to already be present in my 5 tips which of course it is not always the case.
    And if you dont share common goals then freeriding may be the natural result…..

  3. Global Guerrillas talks about a “plausible promise” or shared story that is an animating factor. This plausible promise is shared by all, and from it comes shared values (we value some things more based on the promise we all agree to). From the values should come common, actionable, measurable behaviors.

  4. Heres a link to what Justin was referring to:
    “In sum, his work suggests that one or two widely held rules (greater than 50% adoption) provide the basis for the evolution of an entire set. All rules that have affinity to those founding rules evolve until they are widely adopted. All minority rules that do not have much affinity are flushed”
    This relates particularly well to my point “Develop a set of team ground rules”

Comments are closed.