Permission To Participate – Eugene Eric Kim

How Project Management Tools Empower Communities

Published March 2, 2009 by Eugene Eric Kim

I recently posted an entry at the Blue Oxen Associates blog on Obama, Wikis, and Collective Leadership. The crux of the post was simple: Collective Leadership happens when it’s clear who’s in charge. (N51)

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)

Entangled in all of this are notions of trust and transparency. One of the simplest ways to build trust within a group is to have good Personal Information Hygiene and even better Group Information Hygiene. The path to enabling good Group Information Hygiene is transparency. (N53)

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)

Tools and Culture

Published November 25, 2007 by Eugene Eric Kim

Tools reinforce power relationships. If you want a more emergent power model within a group, you have to make sure your tools support that. Git is a beautiful example of how a tool can support the right power relationships. (MRK)

However, just because a tool has affordances doesn’t mean people will pay any attention to them. Linus Torvalds alluded to an example in a software development context: Giving everyone commit access to a centralized repository. He refers to this happening in companies, but there’s precedent for it happening in Open Source communities as well. For example, TikiWiki gives commit access to anyone who asks. The underlying philosophy behind this policy is very Wiki-like: Empowering everyone to make things better offsets the risk of giving everyone the opportunity to screw things up. By not imposing a power structure, the right model can emerge. (MRL)

In the case of git, the tool explicitly supports an emergent power model. In the case of the TikiWiki community, the tool’s inherent model is overridden by the community’s culture. (MRM)

What can we learn from this? Tools have the potential to transform culture, but transformation never comes easily. In the Wiki community, the classic case of this is when users email an administrator about a typo in a Wiki rather than fixing it themselves. We in the Wiki community use this behavior as a leverage point to explain that they have Permission To Participate and can change the content themselves. Once people start modeling this behavior, transformation becomes a possibility. (MRN)

When I saw Michael Herman last month, we talked about how tools do and don’t encourage emergent models of behavior and how often we need to catalyze this process by other means. Michael brought up the phenomenon of a few people gathering at a circle of movable chairs, then sitting on opposite sides of each other with many chairs between them rather than moving the chairs they needed into a tighter circle. Even though the environment was adaptable, people chose to go with the default rather than optimize it for their needs. (MRO)

I saw a similar phenomenon a few weeks ago at TAG, where I sat in on Eugene Chan, Lucy Bernholz, and Suki O’Kane‘s session on Web 2.0 and philanthropy. They had a very interactive design, which in the context of TAG (a very traditional conference format for a very conservative community), was highly unusual. They kicked things off by doing a spectrogram. (MRP)

(MRQ)

Not only did this establish a sense of self-awareness and Shared Understanding among the participants, it also got people moving (and laughing), which was especially important since the session was right after lunch. Without saying anything, it was clear that this was not going to be your traditional talking heads session. Smart, smart, smart. Then they led a discussion. They gave people Permission To Participate by explicitly setting expectations, catalyzed the discussion by asking broad questions, then held space and exercised self-restraint whenever there were awkward silences. Again, very nice. (MRR)

But they also did something dumb. Look at the space: (MRS)

(MRT)

Whereas the leaders of the session were saying, “Please talk! Participate! Learn from each other!”, the space was saying, “Look at the leaders! Keep quiet! Check your email while pretending to listen!” And the space was really, really loud, much louder than the leaders. (MRU)

In fairness to Eugene, Lucy, and Suki, it would have been a major pain in the rear to rearrange the space, and there were strong disincentives to doing so (specifically, the wrath of Lisa Pool). But space makes a huge difference, and even super smart people don’t account for this as much as they should. Even people who are in the business of collaboration and are constantly preaching about this sort of thing (i.e. me) make these mistakes all the time. Old habits and thinking die hard. (MRV)

The online tool space is rampant with these examples. How often do you see Wikis where the “Edit this page” button is impossible to find? (MRW)

Tools can encourage or discourage certain types of behavior, and it is in our best interest to choose and adapt our tools to encourage the behavior that we want. That’s not always enough, but it’s generally a good start. Eliminating obstacles can be as much of a catalyst as a good kick in the pants, but a combination of both is even more effective. (MRX)

The Future of Intelligence, Part 2

Published September 27, 2006 by Eugene Eric Kim

In my last post, I wrote: (L8D)

Transforming national intelligence is not enough. We need to transform the relationship between intelligence and policy. (L8E)

First things first, though. For the past two days, I and several esteemed colleagues participated in a CIA workshop on blogs and Wikis, organized by Mark Oehlert at Booz Allen Hamilton. The intention was for people within the CIA to learn more about blogs and Wikis from us, but the learning was decidedly bidirectional. We got a glimpse of how the intelligence community works, and we got a chance to further guide the CIA’s thinking on how to improve the way it collaborates, both internally and with others. (L8F)

I spent both days listening closely for patterns of effective collaboration. Given my previous experience with government work, I wasn’t optimistic. These folks surprised me. There were certainly horror stories, but they weren’t significantly worse than stories I have heard and experienced in other organizations. More importantly, there is a small group of vocal, committed champions who believe strongly in how some of these tools can improve the way the organization works and who are actively trying to make this happen. (L8G)

One problem I often see in organizations are claims that certain silos are necessary, claims that tend to be unfounded. Well, these claims are mostly true in intelligence. Given this constraint, how is effective collaboration possible? How can you build trust and traceability when there are different levels of classified information and when anonymity is critical and necessary? How can you have a conversation with someone who doesn’t exist, as far as the CIA is concerned? (L8H)

We can divide these challenges into three areas: collaboration with folks within the organization who share the same security clearance, collaboration with folks in other organizations who share the same security clearance, and collaboration with folks on the outside who do not share the same security clearance. The first two scenarios are relatively straightforward to address. The third is incredibly difficult. (L8I)

The notion of an Intimacy Gradient came up on multiple occasions. An Intimacy Gradient is an important concept in the design of collaborative spaces (both online and face-to-face), but it is a concept rife with problems when implemented online. You can create an online space where people feel comfortable sharing information and leaving artifacts, but that comfort can be completely misguided when it comes to digital artifacts. Blogs are a good example of this. Blogs feel like private spaces, and so people share information on them as if they were private, information that can bite you in the butt later on. (See Whine In Private.) (L8J)

A more subtle example is the Wikipedia visualization that Fernanda Viegas and Martin Wattenberg demonstrated at Wikimania last month. The two were able to show all sorts of personal information about users inferred solely from their editing behavior, which is all publically available. I’m quite certain that none of these users had any idea that such revealing visualizations were possible, and that many would have thought twice about participating if those visualizations were available. Viegas and Wattenberg have been struggling with the ethics of making such visualizations available because of privacy concerns, but the reality is that someone less thoughtful can come along and do the exact same thing. (L8K)

The intelligence community can’t afford to deal with these issues after the fact, so they must think very deeply about these issues ahead of time. The line between FUD and caution is a thin one, and it must be tread carefully. (L8L)

That said, there are still lots of more straightforward things that the CIA can do to improve the way it collaborates, and they’re already exploring many of them. There are several active bloggers within the CIA, including several senior-level people. There is also a Wiki for the intelligence community called Intellipedia. Of the 40 participants at the workshop, more had used Intellipedia than blogs, and I suspect that many more will try it after the proceedings of the past two days. Change is happening, and many participants even argued that change was inevitable. Whether or not it will happen quickly enough is the question. (L8M)

Although the focus of the gathering was on tools, the conversation returned over and over to culture and incentives for collaboration. Many of the ideas centered around ways to encourage blogging or Wikis, but most of these were misguided. I think rewarding people for using a tool is generally a bad idea. What you want to do is reward people for collaborating. (L8N)

Booz Allen Hamilton, for example, has an employee review process known as the 360-degree appraisal. When employees are reviewed, management not only interviews the employees, they interview their colleagues and their clients. The end result is a holistic picture of their employees’ effectiveness. This kind of review process naturally rewards collaboration, even though there is no formal metric. (L8O)

Another way to encourage collaboration is explicit Permission To Participate (one of the patterns that Wikis are so good at facilitating). It’s wonderful when senior level people actively blog and encourage others to do so, but sometimes, Permission To Participate needs to be even more explicit than that. (L8P)

It’s hard to extrapolate too much about the state of the CIA from what happened at the workshop. For starters, the participants were obviously self-selecting. However, the fact that there were 40 people who self-selected was itself significant. There seems to be an impressive amount of savviness within the organization, and if it can ever figure out how to leverage that savviness, many good things will happen. The participants asked good, good questions throughout the two days, demonstrating a high-level of thoughtfulness and introspection. (L8Q)

The most significant outcome for me was the opportunity to put a human face on the CIA. It’s an opportunity that most people will never get, because the CIA will never be a transparent organization, and it will never be able to fully leverage the notion of Markets Are Conversations. But perhaps I and others can act as a proxy. (L8R)

I enjoyed meeting many people, including Calvin Andrus and the team behind Intellipedia (who I hope will attend RecentChangesCamp in May so that they may experience WikiOhana firsthand). I especially appreciated the thoughtfulness of those who were present, which included both champions and skeptics. Most importantly, I appreciated people’s hearts. The CIA point person for the workshop closed the gathering by remarking that the commonality between the guests and the participants was passion, then told an emotionally wrenching story about his son and about watching the plane crash into the Pentagon on 9/11. These folks are smart, they’re human, and they care. They care about doing their jobs well, and they care about improving this country. (L8S)

The CIA has had a checkered history, and many challenges lie ahead. Change will not be easy. But they are doing some things well, and we should continue to engage with them, so that we can continue to learn from each other and improve. I came away from this workshop more optimistic about the CIA itself, but less so regarding its relationship with other intelligence agencies and with its customers, the policy makers. But, first things first. Baby steps lead to big changes. (L8T)

Angry Rant on Wikis

Published May 30, 2006 by Eugene Eric Kim

Earlier this month, Jonas Luster invited me to speak at WikiWednesday. I didn’t have anything prepared, and I didn’t feel particularly motivated to prepare anything, so, I told Jonas that I was just going to rant. Jonas, being Jonas, loved the idea. So after IIW wrapped on May 3, I headed up to Palo Alto. I promised folks at IIW that I was going to give an angry rant on Wikis, and so several people decided to come watch, including Phil Windley, who blogged it. Feedback was great, except for a few complaints that I wasn’t all that angry. I promise to get more worked up next time, folks. (KK2)

I’ve made all the points I made in my rant before in some form or another, often on this blog. Nevertheless, it was the first time I shared these ideas as one semi-cohesive thought, and so it’s worth rehashing the points here. (KK3)

Overview (KK4)

There are two things that make Wikis cool: (KK5)

Open access (KK6)
Shared Language (KK7)

Lots of folks have latched onto the open access part, and there’s been some interesting exploration in this area. Very few folks know about or understand the Shared Language aspect. I think this is a huge loss, because it’s what makes Wikis truly transformational. (KK8)

Open Access (KK9)

Since I had just come from IIW, I started with digital identity. First, I said that all Wikis should support some form of distributed Single Sign-On, be it OpenID or something else. Implementing Single Sign-On does not imply loss of anonymity. Most Wikis give you the choice of logging in or not; implementing Single Sign-On would give you the additional choice of using a single identity across multiple sites. (KKA)

Why would this be useful? Consider Wikipedia. As my friend, Scott Foehner, commented in a previous post on this topic (to be visible again when I turn comments back on), Wikipedia actually consists of a number of different Wikis, one for each language plus a number of special Wikis, such as its community site. Each of those Wikis require a separate user account. Not only is this a huge inconvenience, it effectively prevents you from having a single digital identity (along with your associated reputation) across each of these sites. (KKB)

Simply having Single Sign-On across all of the Wikipedia Wikis would be valuable. More importantly, the identity community has converged to the point where it doesn’t make sense to roll your own protocols. There are several good existing protocols to choose from, and many of those are in the process of converging. (KKC)

Reputation is closely associated with identity, and it’s also been one of the most popular topics in the Wiki community over the past year. However, most people have a misguided notion of what reputation is and what we should do about it. Reputation is what others think about you. Reputations exist in every system, whether or not they are explicitly represented. Reputation cannot be quantified. However, you can identify the factors that determine reputation and make those factors more explicit. (KKD)

In Wikis, this could manifest itself in a number of ways. For example, one way to determine the quality of a page is to view the number of people who have edited it. You could make that number explicit by subtly changing the background color of that page — slightly yellowed for a page with few contributors and bright white for a page with many contributors. (KKE)

The important point here is that you are not making a value judgement on reputation. You are not saying that a page that has many authors is better than a page that does not. All you are doing is making it easy to see that a page has many authors. Readers can determine for themselves how much weight (if any) to place on this factor for the reputation algorithm in their heads. (KKF)

The most important button on a Wiki page is the Edit button. That button implies Permission To Participate. It should be one of the most visible buttons on any Wiki. If a Wiki looks too good, that discourages participation. Who wants to edit something that looks like a finished product? Ward Cunningham used to suggest sprinkling typos across a Wiki page to encourage others to participate. (KKG)

At this point in the rant, I plugged both Ward and MeatballWiki. The Wikis success is no accident. A lot of the fundamental design features that make Wikis powerful were completely intentional, a testament to Ward’s brilliance. Additionally, most of what I ranted about is not new to the Wiki community. A lot of it — and more — has been discussed on the venerable MeatballWiki. If you really want to get a deeper understanding of how to improve Wikis, you should be on Meatball. (KKH)

Shared Language (KKI)

Last September, I wrote: (KKJ)

What really makes the Wiki’s LinkAsYouThink feature special is that it facilitates the creation of SharedLanguage among the community that uses it. As I’ve said so often here, SharedLanguage is an absolute prerequisite for collaboration. The lack of SharedLanguage is the most common roadblock to effective collaboration, be it a small work team or a community of thousands. T (KKK)

It bears repeating over and over and over again. Wikis are transformational because they facilitate Shared Language. This is a feature that should be propagated far and wide, both in Wikis and other Collaborative Tools. (KKL)

I noted two possible convergences. The first is Wikis and tagging. They both share a similar principle, namely namespace clash, and we should look at ways of combining these two concepts. For example, where’s the tag cloud view of a Wiki’s page index? Another idea: Clicking on a tag should also return Wiki pages of the same name. Technorati should be indexing Wiki pages and treating their titles as tags. (KKM)

The second is implementing Link As You Think in all tools. Blogs that are built on top of Wikis (such as TWiki and JotSpot) have these features, but you don’t have to build a tool on top of a Wiki for this to work. This blog runs on blosxom, but it has Link As You Think. Chris Dent‘s blog runs on MovableType, and it has the same feature. It shouldn’t just apply to blogs, either. It should work in web-based forums and other Collaborative Tools. (KKN)