Watching sports live is one of the best places to observe group dynamics. I’m not talking about watching the actual teams play, although that’s great too. I’m talking about watching the fans. Baseball, in particular, is great for this, because there’s a lot of downtime between plays.
The richest experiences come from watching teams with great fans. Oakland fans are some of the very best in sports, bar none. Warriors fans are widely acknowledged as the best in the NBA, and A’s fans are right up there. I don’t even have to mention Raiders fans.
I went to the A’s game yesterday, and I got some video clips of fan dynamics and collective leadership in action. This guy consistently got the crowd going, simply by standing up and clapping loudly, rhythmically, and enthusiastically. But this doesn’t work unless you have the right fan culture. I’ve been to many games on the other side of the Bay where these types of efforts are met with uncomfortable passivity.
I’ve been to a lot of baseball games in my life, but somehow, I’ve never seen this before: fans taunting the opposing relief pitchers warming up in a very creative way. I wasn’t sure what would happen with a second relief pitcher, but when it happened, the fans didn’t miss a beat. I was literally rolling around in my seat laughing.
This video shows the fan ritual whenever closer Grant Balfour comes into the game. It’s known as “Balfour rage” in honor of the closer’s legendary volatile temper, and the history of its evolution is fascinating.
My only regret was that there were no waves. Watching a wave form is a fascinating study in group dynamics.
And, I was disappointed to see that Kat Walsh, the longest running community member on the board and current board chair, was not re-elected. In the grand scheme of things, that’s probably for the best. I’m a firm believer in term limits for nonprofit board members, and if the Wikimedia Foundation had had them, Kat would have been termed out at some point anyway. I also think that this will be a wonderful opportunity for her to take a break from the drama that Wikimedia board members have to deal with on an ongoing basis.
I don’t know anyone in the Wikimedia community who doesn’t love and respect Kat, and she’ll continue to be a community leader, board seat or not. I want to tell a personal story about Kat that says a lot about what it means to be a leader, especially in a network and in a community.
I’ve been part of the larger wiki community since 2000 (pre-dating Wikipedia). I was friends with Wikipedia contributors in its earliest days, but I only edited sporadically and anonymously. Because of my role in the larger wiki community, I was invited to participate at the first Wikimania in August 2005, where I met many Wikipedians for the first time. I created my user account shortly thereafter, but I didn’t make my first non-anonymous edit until November 2006, and only then at the urging of my friend, Erik Möller.
What does it mean to be a Wikipedian? Obviously, if you edit Wikipedia frequently, you are a Wikipedian, but how frequently? The Wikimedia Foundation currently defines “active contributors” as anyone who edits five or more times a month, but not all edits are created equal. There are the edits that I specialize in — mostly typos and occasional citations — and there are the edits that make Wikipedia sing, the ones that require painstaking research and eloquent craftsmanship. Does one type of edit make you more of a community member than another?
And do you have to be an editor to be a Wikipedian? What about the Wikipedia enthusiast, the people who evangelize Wikipedia to all of their friends and colleagues, despite never having clicked the edit button? What about the people who consistently donate money? My dad has nary a clue of my involvement with Wikimedia over the years, but he has enthusiastically given money every year completely on his own accord, and he waxes poetic about the project. He almost certainly evangelizes it more than I do. Is my dad a Wikipedian?
Most importantly, who decides who gets to be a Wikipedian? What is it that makes a Wikipedian feel like he or she is a Wikipedian?
Back in the day, I never felt like I was a Wikipedian, and I was perfectly fine with that. Whenever I participated in Wikimedia things, people were always very friendly, and I never felt excluded. I just didn’t feel like I was enough of a contributor to consider myself a Wikipedian.
That all changed on November 10, 2007, the day I first met Kat. Phoebe had organized a San Francisco meetup, and Kat was visiting from Washington, D.C. Even though I knew folks there, I was sitting quietly in a corner somewhere, when Kat approached me and introduced herself.
Barnstars are the virtual currency of the wiki community. Anyone can award a barnstar to anyone else for their contributions to the community. Kat made it a point to carry around real-life barnstars, which are beautiful and heavy, and give them out to people at meetups. She did this entirely on her own accord and at her own expense.
I knew who Kat was, and I knew what barnstars were. As I said, I had never felt excluded from the community before — I was at a Wikipedia meetup, after all — but when Kat handed me that barnstar, that was the first time I felt welcomed. It was the first time I felt like I was a Wikipedian.
As networks mature, they sometimes start spending an inordinate amount of time on issues like governance, where defining things like community membership suddenly becomes more important. (This is especially endemic to networks with a strong top-down element, such as funder-initiated networks, but it’s true across the board.) This is where the organizational mindset tends to kick in, and people are easily sucked into complex and difficult questions around criteria. At some level, it’s unavoidable. However, I think that people spend way more time on these issues than are merited (and often earlier than necessary).
Worse, it often comes at the expense of what really matters. Human things, like welcoming people. It may sound basic and perhaps too squishy for some tastes, but it’s incredibly important, and in my experience, groups neglect these basic human patterns to their detriment.
When Groupaya designed the Delta Dialogues last year, we incorporated some sophisticated tools, because we were dealing with a wicked problem and a toxic culture. While we were incredibly skilled at using those tools, that’s not what differentiated our process from the countless other processes that had been tried in that region.
Our secret sauce wasn’t our tools. It was our attention to our participants’ humanity. It was our instinct to open the Dialogues by having every participant describe their favorite place in the Delta. It was our instinct to rotate the locations of those meetings, to have different stakeholders host them, so that other stakeholders could break bread in each other’s homes and get a better sense of who they were as people. It was how we incorporated both head and heart into our process. None of this was brain surgery, and yet, no one else was doing it.
Back in 2007, Kat was already a long-time contributor and board member. All of that was simply status. You can have those things and not be exercising any leadership. Going out on her own and finding simple, human ways to make others feel welcome — that’s leadership, and you don’t need any kind of official status to practice it.
The Wikimedia projects have seen an ongoing decline in active contributors since 2007. The reasons why are complex, and there are no simple solutions to turning that around. At the risk of sounding simplistic, I’m going to offer a solution anyway. Find ways to be more human.
It’s simple, but it’s not easy. There are systemic ways to encourage this, such as making the tool easier to use, revamping the language in the templates, and starting community initiatives like the wonderful Wikipedia Teahouse. All of this stuff is already happening.
Then there are the individual things that everyone can do. Things like reaching out to someone and welcoming them, or expressing gratitude to someone whom you value. Those things matter a lot more than we think, regardless who is doing them, and we don’t do them often enough.
Here’s my advice to everyone who participates in any Wikimedia project in any way — contributor, reader, donor, enthusiast. Make it a point to reach out to one other person. Maybe it’s someone who’s just getting started. Maybe it’s someone whom you’ve appreciated for a long time. Take the time to drop them a note, to welcome them or express your gratitude to them.
If we all did this, I promise you, something magical would start to happen. That’s true of Wikimedia, and it’s true of the world.
Consider this my small little expression of gratitude. Kat, thank you for making me feel welcome!
In other words, powerful communities empower their participants to lead by giving them Permission To Participate. When it’s clear that a community has thought about what needs to be done and that people within the community are doing those things, then people can have confidence in that community’s leadership. (N52)
Good Project Management tools encourage good Group Information Hygiene via transparency. As a member of a project team, I can look at all of the group’s tasks, I can see what’s been assigned, and I can know who’s following through. Moreover, others can see the same about me. (N54)
In a small team with clearly defined roles, project leaders are supposed to be responsible for all of this. But by making these things transparent, project leaders engender greater trust and empower the entire team. (N55)
In a large community with no imposed authority, this is even more critical, because there isn’t anyone who has been pre-assigned with the responsibility. One of the most powerful ways to be transparent and empowering is by using a Project Management tool to openly list tasks, and by enabling anyone in the community to contribute to or volunteer for tasks. (N56)
A few years ago, I had a conversation with my friend, Steve Ketchpel, about this phenomenon, and he shared a brilliant insight. He said that most Project Management tools are not useful for empowering grassroot communities, because they assume that people who take responsibility for a task will actually follow-through. What we actually need are tools that encourage people to do their best to follow through on tasks, but that also encourage others to take over those tasks when the original volunteers don’t or can’t follow through. This is simply a reality of life in grassroot communities, and tools need to support this. (N57)
The Project Management tool that comes closest to supporting this is Chandler. Obviously, I’m biased, but I think that Chandler does a great job of making it easy for anyone to see and take on tasks. Ironically, one of the ways it does this is by not having a task assignment feature. You can sign up for a task by adding your initials to the title or description of a task, and you can just as easily reassign tasks the same way. (N58)
In The Restaurant at the End of the Universe, Douglas Adams wrote: (MR5)
The major problem — one of the major problems, for there are several — one of the many major problems with governing people is that of whom you get to do it; or rather of who manages to get people to let them do it to them. (MR6)
To summarize: it is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it. To summarize the summary: anyone who is capable of getting themselves made President should on no account be allowed to do the job. To summarize the summary of the summary: people are a problem. (278) (MR7)
I recently watched Linus Torvalds‘s talk at Google on git, the distributed version control system he wrote a few years ago. There are a bunch of gems in his talk, and it’s well worth watching. My favorite had to do with git’s views on decision-making in Open Source communities: (MR8)
Maybe you don’t have this issue inside a company, but we certainly have it in every single Open Source community I’ve ever seen that uses CVS or Subversion or something like that. You have this notion of commit access. Because you have a central repository, it means that everybody who’s working on that project needs to write to the central repository. Which means that, since you don’t want everybody to write to the central repository because most people are morons, you create this class of people who are ostensibly not morons. And most of the time, what happens is, you make that class too small, because it’s really hard to know if a person is smart or not, and even when you make it too small, you will have problems. So this whole commit access issue, which some companies are able to ignore by just giving everybody commit access, is a huge psychological barrier, and it causes endless hours of politics in most open source projects. (MR9)
If you have a distributed model, it goes away. Everybody has commit access. You can do whatever you want to your project. You just get your own branch. You do great work or you do stupid work. Nobody cares. It’s your copy. It’s your branch. And later on, if it turns out you did a good job, you can tell people, “Hey, here’s my branch, and by the way, it performs ten times faster than anybody else’s branch. So nyah nyah nyah. How about pulling from me?” And people do. (MRA)
And that’s actually how it works, and we never have any politics. That’s not quite true, but we have other politics. We don’t have to worry about the commit access thing. I think this is a huge issue, and that alone should mean that every single Open Source system should never use anything but a distributed model. You get rid of a lot of issues. (18:12-20:13) (MRB)
Someone in the audience asked Torvalds whether the distributed model simply shifted the political questions of access rather than eliminated them, to which Torvalds replied: (MRC)
What happens is, the way merging is done is the way real security is done: by a network of trust. If you have done any security work, and it did not involve the concept of network of trust, it wasn’t security work, it was masturbation. I don’t know what you were doing, but trust me, it’s the only way you can do security, it’s the only way you can do development. (MRD)
The way I work, I don’t trust everybody. In fact, I’m a very cynical and untrusting person. I think most of you are completely incompetent. The whole point of being distributed is, I don’t have to trust you, I don’t have to give you commit access, but I know that among the multitude of average people, there are some people that just stand out, that I trust, because I’ve been working with them. I only need to trust five, ten, 15 people. If I have a network of trust that covers those five, ten, 15 people that are outstanding, and I know they’re outstanding, I can pull from them. I don’t have to spend a lot of brainpower on that question. (27:37-29:00) (MRE)
Power relationships exist everywhere there are groups of people. And if you don’t believe they should, you’re kidding yourself. Collective Intelligence, Collective Leadership, and more specifically, emergent self-organization are not about eliminating power relationships. They’re about empowering the right people at the right time. (MRF)
Thanks to next week’s Creating Space, Collective Leadership has been on my mind a lot recently. It’s also been a key element of the new Identity Commons. One of the issues we’ve been grappling with is decision-making. To understand why this is a challenge, you have to understand the underlying structure and philosophy of the organization. (M5R)
Ultimately, Identity Commons is a Community Mark that represents a set of values concerning Digital Identity. It’s a name bestowed on the community of folks who care about User-Centric Identity. If you care about this stuff, then you are part of Identity Commons. There is nothing to join, and you are free to use the name and logo as a way of demonstrating your support of these values. (M5S)
Why this is such a powerful and important construct is a topic for another day. What’s interesting about this particular community is that there’s also a corresponding legal structure, a nonprofit organization that is in the process of being incorporated. This organization consists of community “Stewards” — people appointed by the community to represent the interests of particular sub-communities (“Working Groups”) and who are responsible for managing the tangible assets of the commons. There are rules for becoming Working Groups and Stewards, but they are extremely lightweight. (M5T)
All of the Stewards comprise a Stewards Council. Each Steward has an equal vote on all matters. There is a Chair, but that position is mostly facilitative. There is also a Chief Catalyst, someone (not necessarily a Steward) who is responsible for handling the operational duties of the organization and catalyzing action in the community. (M5U)
It’s a fascinating, but delicate structure. The Stewards Council has an important leadership responsibility, but that role is distributed equally among all of the Stewards. How do Stewards exercise leadership effectively given this structure? Decision-making via voting is clumsy in many contexts, and yet that’s the only process that we’ve actually defined. (M5V)
We’ve had a number of interesting conversations on the topic, and the latest discussion recently surfaced a lurker, Martien Van Steenbergen, who cited an interesting reference on holacracy. Martien quotes the following excerpt (emphasis his): (M5W)
Another common question is about the “possible votes” in integrative decision making. At first it can sound like there are two possible votes on a proposed decision — “consent” or “object” — though that’s missing a key point. Consent isn’t about “votes” at all; the idea of a vote doesn’t make sense in the context of consent. There are no votes, and people do not vote.(M5X)
People do say whether they know of a reason why the proposed decision is outside the limits of tolerance of any aspect of the system, and then decision making continues to integrate that new information. This isn’t the same as most consensus-based processes — either in theory or in practice — although it does sound similar at first, especially before an actual meeting that seeks consent is witnessed. (M5Y)
This quote is keying on the difference between Collective Leadership and consensus leadership. They are not the same thing. With Collective Leadership, you are acknowledging the multi-faceted requirements of leadership, and you are empowering those best suited to meet those requirements to fulfill that leadership role. You are not voting on every decision, which would be a sure path to disaster. (M5Z)
One of the ways this manifests itself is by making decisions “without objection.” This is a technique from Roberts Rules Of Order that Joaquin Miller brought to our attention. Essentially, you empower people to act, unless someone in the group objects, at which point an alternative process kicks in. Everyone still has a voice in the decisions, but it is a proactive rather than a reactive style, and it encourages action rather than stagnation. (M60)
I believe that when you have great collaborative process, voting is a rubber stamping process, even when the topic is controversial. In other words, the actual decision-making process starts well before any vote happens. Healthy deliberation results in Shared Understanding, which in turn helps to surface clear courses of action that navigate through the obstacles of contradictory ideologies. When there is pressure for movement (another pattern of high-performance collaboration), then people will rally around those courses of action. (M61)