Teams thrive on reciprocity.

Biases affect everyone’s behavior in all walks of life.  In a recent Freakonomics podcast, The Stupidest Thing You Can Do With Your Money, Stephen Dubner described the impact of various cognitive biases on the behaviors of many well-known money managers (and nearly 70% of the investors in the world).  The people on teams involved in the development, support and maintenance of software products are not immune to the impact of biases.  After the publication of our essay A Return to Cognitive Biases, Steven Adams asked “What biases/fallacies might a developer fall prey to when testing code that he or she developed?” It is a great question that gets to the heart of why understanding cognitive biases is important for leaders and team members.  We will return to the question after we added two more biases to our growing pallet of biases that we have explored.

  1. Reciprocity bias.  Have you ever been out to lunch with friends and picked up a check with the expectation that next time someone one else would pick up the check?  The reciprocity bias is a social rule that states that someone should repay, in kind, what another provided for them.  Agile teams are built with an expectation of reciprocity between team members.  If one team member helps another they will be helped in their time of need.  Favors, gifts, support amongst team members create an obligation between team members.  I have occasionally observed teams where a member will accept support and help but never seems to have time to help others.  Over time those types of team members are typically ostracized and are often driven from the team.  When assessing teams ask if they is anyone that chronically never picks up the check when team member go out socially.
    Note:  The reciprocity bias is a classic tool of salesman and negotiators who will “give” the other side a gift with the expectations of getting repaid.  The action builds trust and can be used to break impasses by creating movement between parties.
  2. Priming. Priming is behavioral bias that is used to guide behaviors and, in some cases, thoughts. Priming occurs when one stimulus or event influences the response to another event or stimulus. I recently observed a pilot project that was organized with handpicked team members and structured to increase the probability of good outcome.  The group leading the effort explicitly wanted to manufacture an event that could be used to prime the organization for further change.  The goal was to get people excited about change (prime) and set an anchor (anchor bias) through the use of teams and procedural frameworks.

Biases affect how people and team members behave.  An understanding of potential biases can be used to identify blind spots in how people or teams behave.  This is the underlying basis of Steven’s question. Establishing the common blinds spots the flow in the process that take an idea from concept to delivery is more complicated that developing a process flow and identifying constraints.  We need to understand how teams and individuals think.