Designing Cooperation: An Institutional Approach to Software Teams

An institutional analysis of software teams

2007-08-30
Josh Tenenberg
Summary
Problem
Method
Results
Takeaways
Abstract

This paper applies the Institutional Analysis and Development (IAD) framework to software engineering teams, treating software development as a collective action problem. By implementing specific "rules-in-use," the author demonstrates how to mitigate free-riding and enhance cooperation in team settings.

Executive Summary

TL;DR: Software development is fundamentally a social "collective action" problem where the incentive to shirk (free-ride) is a constant threat. This paper moves beyond traditional "managerial control" and utilizes the Institutional Analysis and Development (IAD) framework to show how specific rules—emphasizing face-to-face communication, repeatability, and mutual monitoring—can virtually eliminate free-riding and foster high-performance cooperation.

Background Positioning: This work bridges the gap between political economy and software engineering management. It moves the discourse from "how to control developers" to "how to design institutions that facilitate self-governance."

The Social Dilemma of Code

The paper argues that every software team faces a classic Social Dilemma. If everyone else works hard, an individual is better off shirking. If everyone else shirks, the individual is also better off shirking to avoid being the "sucker." This logic leads to the "Tragedy of the Commons," where the collective project fails despite everyone desiring a good outcome.

Existing management literature suggests Hierarchical Control (managers watching experts) or Clan Control (socializing everyone into shared values). However, the author argues these are insufficient for diverse or autonomous settings like student teams or Open Source projects.

Methodology: The IAD Framework

The core of the paper is the application of the IAD Framework, originally developed by Nobel laureate Elinor Ostrom for managing shared natural resources (like fisheries or forests).

The Internal Structure of Action Situations

The author breaks down the "Action Arena" of a software team into several rule-based components:

  • Position Rules: Defining roles like "Scribe" or "Facilitator."
  • Information Rules: Requiring weekly "Task Matrices" that make individual commitments public and transparent.
  • Payoff Rules: Implementing individual multipliers (0.0 to 2.0) based on peer evaluations to create "Quasi-voluntary compliance."

IAD Framework Overview Figure 1: The Institutional Analysis and Development (IAD) Framework illustrating the interaction between rules, biophysical conditions, and outcomes.

The Four Pillars of Cooperation

Based on experimental economics, the author identifies why this specific institutional design works:

  1. Face-to-Face Communication: Simply talking in person dramatically increases the pressure to keep promises and allows for verbal "soft sanctions."
  2. Repeatability (The Shadow of the Future): By breaking a 9-week project into weekly deliverables, the "future casts a shadow on the present." If you shirk in Week 1, you know your team will punish you in Week 2.
  3. Mutual Monitoring: Instead of a manager watching every move, team members monitor each other. This is low-cost and more transparent.
  4. Graduated Sanctions: Small penalties for first-time offenders prevent the "sucker" feeling among others without destroying motivation.

Evidence and Results

The study of student teams at the University of Washington, Tacoma, provided empirical proof:

  • Commitment: Students met 94% of their self-defined weekly tasks.
  • Fairness: Over 82% of anonymous peer ratings indicated that work was distributed with surgical fairness.
  • Attitude Shift: Using a pre- and post-course survey, the author found a statistically significant drop in perceived free-riding.
MetricPre-Course (Previous Experience)Post-Course (This Method)
Free Rider Frequency3.44 (Higher)1.64 (Lower)
Commitment Level3.114.28

Deep Insights & Conclusion

Takeaway

Software "institutions" (the rules of the game) always exist—whether they are accidental or designed. By intentionally designing for transparency and mutual accountability, we can reduce the "transaction costs" of management while preserving developer autonomy.

Limitations

A major question remains: Can this be replicated in purely virtual environments? The author leans heavily on the "magic" of face-to-face interaction. Future research must determine if high-bandwidth video or VR can provide the same psychological "promise-keeping" effect.

Future Outlook

For practitioners, the message is clear: Stop trying to control behavior through surveillance. Instead, provide teams with the tools to monitor themselves and the sanctioning power to hold each other accountable. This is the essence of true self-organizing teams.

Find Similar Papers

Try Our Examples

  • Search for recent studies that apply Elinor Ostrom's IAD framework to the governance of Open Source Software (OSS) communities.
  • Which paper originally defined the "Institutional Analysis and Development (IAD) framework," and how has it been modified for digital as opposed to physical commons?
  • Have there been comparative studies on the effectiveness of face-to-face vs. virtual communication in mitigating free-riding within distributed Agile software teams?
Contents
Designing Cooperation: An Institutional Approach to Software Teams
1. Executive Summary
2. The Social Dilemma of Code
3. Methodology: The IAD Framework
3.1. The Internal Structure of Action Situations
4. The Four Pillars of Cooperation
5. Evidence and Results
6. Deep Insights & Conclusion
6.1. Takeaway
6.2. Limitations
6.3. Future Outlook