I have to admit that I’m a bit of a collaboration and community junkie and as such follow some obscure topics. One topic I’ve had on my radar for quite some time is Flock Theory. Flock theory tries to describe the self-organizing and emergent aspects of human behavior. Succinctly put, behavior in some cases is not a property of any individual person (or bird), but rather emerges as a property of a group or social network (flock). This concept can be used to describe aspects of both collaborative teams and open source communities. I’m not going to analyze the merits of the theory but I do want to introduce its concepts which I think have implications for team/community productivity and possibility even individual information relevance.
The fundamental aspects of Flock Theory can be distilled into the following axioms and tenets …
Distance Optimization
- Avoid crowding group members
- Move towards the central tendencies of the group
Motion Replication
- Direction Matching
- Velocity Matching
Leadership Maintenance
- Group leaders must shift efficiently</li>
- Eliminate extreme dissenters</li>
Distance optimization speaks to the fact that teams need to find a balance between working autonomously and relying too heavily on team decision making. Teams and communities that rely heavily on group cohesion (or decision-making) can find themselves with a case of “groupthink”. However, having accountability in such an environment is equally important, allowing group members the autonomy to work requires having goals that each member can be accountable for.
Motion replication fundamentally looks at two key principals, direction matching and velocity matching. Direction matching speaks to the pursuit of a shared or common goal among team members while velocity matching addresses the idea that optimal teams need members that can perform at a consistent rate. Other members of a team cannot consistently wait on suboptimal team members or risks to the group’s goals will ensue.
And finally, Leadership Maintenance is perhaps the most interesting part of the theory (for me) as it postulates that there is a need for constant leadership change so that management of the flock remains fresh and focused and is always headed towards the correct goal. Any extreme deviation from goal-oriented behavior by a team member can risk the mission and must be dealt with harshly.
I find Leadership Maintenance especially intriguing given my association with open source projects. Based on Flock Theory one could argue that open source project management should continuously turnover so that other community members can help shape the direction of the project. In reality many successful open source projects have very strong central leadership that never really change significantly. A few that jump to mind … Linux, Perl, Python, Scala, Ruby, etc. All of these projects have a vibrant community of active participants but are led by a strong leader. There are also examples of successful projects that follow Flock Theory more closely. Apache would be one. Is Apache a better project than Linux, Python, or Ruby? Certainly not. But perhaps it is a better example of what an “emergent” software project looks like?