A group is its own worst enemy

In April 2003 Clay Shirky gave a keynote at O’Reilly’s Emerging Technology Conference called “A Group Is Its Own Worst Enemy.” It was about online communities, but it reached back to the 1940s and to a British psychoanalyst, Wilfred Bion, who ran therapy groups for soldiers and wrote up what he saw in Experiences in Groups (1961).

Bion’s basic assumptions

Bion noticed that a group meeting to do a job often behaves as if it had met for some other purpose entirely. He called these hidden purposes “basic assumptions,” and described three. In Shirky’s plain-language version: the group drifts into pairing off and flirtation; it unites against an outside enemy; or it treats some person, idea, or text as beyond question. Each one feels like group cohesion. Each one stops the group doing the work it gathered for.

Shirky’s point was that software designers kept being surprised by this. They built tools for individuals and were baffled when the group that formed around the tool started to eat itself. His conclusion: groups are a runtime phenomenon. You cannot fully specify a group in advance; you can only design the conditions it runs in.

What to design for

Shirky suggested that any software for groups should plan for a few things up front:

• Some form of constitution. The group will need rules, and a way to change them, that protect it from its own worst moments.
• Persistent identity. Members need names that carry a history, so reputation can form.
• A way to recognize core members. Not everyone in a group is equally invested, and the tool should let the people who carry it be seen.
• Some cost to participating. Friction is not always a bug; a small barrier filters for people who mean it.

The workplace version

Patrick Lencioni’s The Five Dysfunctions of a Team (2002) reaches a related diagnosis from management consulting rather than psychoanalysis. Told as a fable, it describes a stack of failures, each resting on the one below: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. It is a business book, not a research study, but its account of how teams avoid the work they exist to do lines up closely with Bion’s.

Why this matters for convivial tools

Illich described convivial tools as ones that serve people as members of communities, not just as individuals. That makes group behaviour part of the design problem. A tool for a community garden, a mutual-aid network, or a plugin’s volunteer contributors will meet Bion’s basic assumptions sooner or later. Counterfoil’s catalogue asks of every group tool: what has it done to help the group keep working when it would rather be doing something else?