Good Personal Information Hygiene

Posted on Published by Eugene Eric Kim

Chris Dent and I were chatting about my recent forays into David Allen‘s Getting Things Done, which led to this classic line from Chris:    (KXN)

Someday someone, maybe one of us, will poop out a “collaboration requires good personal information hygiene” thing.    (KXO)

Consider this post a poop.    (KXP)

When we founded Blue Oxen Associates, we were supposed to be a place for those on the cutting edge of collaboration. I quickly discovered that most people who want or claim to be on the cutting edge are held back by poor Personal Information Hygiene. People need to start with themselves before they worry about the group if they want to improve their ability to collaborate. (This is a general theme that extends beyond Knowledge Management.)    (KXQ)

Signs of poor Personal Information Hygiene:    (KXR)

  • Not keeping track of action items. (Not delivering on them is a sign of poor work discipline.)    (KXS)
  • Constantly asking questions that have been answered before. (This is also a great sign of poor Collective I Q.)    (KXT)
  • Asking to resend an email rather than looking things up yourself.    (KXU)
  • Losing track of email (including not responding quickly).    (KXV)

I have good Personal Information Hygiene, with two exceptions: I don’t answer email promptly, and I have a poor paper filing system (hence my recent foray into GTD). My digital information repository, on the other hand, is excellent — well linked and decently refactored. I generally find what I’m looking for and sometimes even find things I’m not looking for. I’ve started collecting some of my habits on my public Wiki at Life Hacks.    (KXW)

(Bill Seitz has often strongly expressed a similar view — that good organizational Knowledge Management needs to start with good Personal Information Hygiene. See his Wiki page on PersonalKnowledgemanagement.)    (KXX)

Beating the Dead Horse of Collaboration: Thinking Versus Doing

Posted on Published by Eugene Eric Kim

My post on the dangers of professionalizing collaboration spurred some good thoughts from Chris Dent, which resulted in some good discussion over IM. Chris wrote:    (KP6)

What one does when collaborating is always more important than collaboration itself.    (KP7)

In the ideal situation, collaboration disappears into the background. If you find yourself enmeshed in the details of how your group should interact, you’ve missed a step.    (KP8)

This is so true, it bears emphasizing. Think about dancing. What could be more collaborative? If you’re thinking about your footwork or your next move as you dance, you are almost certainly not dancing well. On the other hand, how do you become a good dancer without thinking about footwork? More importantly, how do you improve if you’re not self-reflective? Obviously, actually doing it is crucial — and in the end, it’s the most important thing — but there’s still room for self-reflection and discussion. What’s the right balance?    (KP9)

The key is a cycle of reflection and action. You think and you talk, but when it comes to action, you forget all of that, and you simply do. All of that thinking, regardless of how good or how deep it is, is useless if it hasn’t been internalized, if it’s not actionable. If it has been internalized, then thinking or talking about it is not only unnecessary, it just gets in the way.    (KPA)

Chris’s point reminded me of something: People’s best experiences with collaboration often occurs when there’s a sense of urgency. Collaboration following disasters is a great example of this. A big reason for this is that people don’t have the luxury of overthinking a problem, and so if collaboration is good, nothing artificial gets in the way.    (KPB)

In my essay, “Everything Is Known: Discovering Patterns of Emergent Collaboration,” I talk a lot about William Langewiesche‘s book, American Ground and the emergent collaboration that occurred after 9/11. I didn’t get to talk in detail about what happened after the bulk of the recovery effort was complete, although I alluded to it in a previous blog entry. Langewiesche writes:    (KPC)

Safety restrictions were increasing by the day. Ken Holden was philosophical about it, and, as his father might have years before, he played a little word game — something like metaphor-cramming. He said, “When the smoke clears, the nitpickers come out of the closet.” And it was true: the regulators and auditors had arrived in force. Those from the federal safety agency called OSHA were most in evidence; they had been present from the start, and had been largely ignored, but were suddenly multiplying now and gaining the upper hand. They wore bright safety vests and had helmets equipped with red flashing lights. One afternoon, with about a dozen of them in sight, their lights blinking in the hole, Pablo Lopez said to me, “Look! The Martians have landed and they’re communicating!” A few days later one of them asked me to don safety glasses or leave the excavation site, and I remember my surprise when I realized that he was serious. It felt sort of silly, like being required to wear sunblock in a combat zone, but the truth was that the battle was over, and the hole had become a tame place. Lopez’s partner Andrew Pontecorvo explained it to me as a fact of life that he had observed before. He said, “The safer things get, the greater the restrictions.” He was a realist. He shrugged. (198-199)    (KPD)

How do we avoid this trap? One key is to build a frequent, regular cycle of intense collaboration followed by reflection into your design. You can’t do both at the same time, but you don’t want to do one without the other for too long. Deadlines are a pattern that facilitates this behavior.    (KPE)

If your team or community is aware of this cycle, then if someone’s self-reflection is preventing work from happening, you can call him or her on it. Chris suggested having a Horse Is Dead stick, similar in concept to a talking stick. I’m not sure exactly what you would do with the stick yet — beating the person over the head with it sounds right, but this may not go over well with management — but I think he’s on the right track.    (KPF)

If the reason for collaborating is more important than the collaboration itself, then what are the implications for metrics? Do you measure collaboration at all, or do you measure whether or not you’re achieving your mission? The example I often use for this are the 2000-2003 Kobe Bryant and Shaquille O’Neal Lakers. No one would point to those teams as models of effective collaboration, but who cares? They won three consecutive championships. Which metric is more important? Well, they may have won three, but they should have won four, and they had to break up the team because they couldn’t get along. The point is that you can’t measure one in isolation from another. You need to measure both, and consider one in the context of the other.    (KPG)

Angry Rant on Wikis

Posted on Published 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)

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)

Blogging as Knowledge Work

Posted on Published by Eugene Eric Kim

The process of writing my entry on community engagement and Dynamic Knowledge Repositories reminded me of Chris Dent‘s recent post on “Effective Reading.” He writes:    (KE4)

I proceed from the assumption that as knowledge workers our primary job is to communicate. Communication is not overhead, it’s the work. Things like writing code are reifications of previous communication. The quality of the code mirrors the quality of the communication and comprehension that precedes the generation of the code.    (KE5)

We often think of the act of summarizing as additional work. On one level, that’s true. But, if we reframed it as a critical part of the knowledge synthesis process, then it no longer becomes additional work, it becomes the work. Not only does it result in a useful artifact — what Doug Engelbart calls the “knowledge product” — but it helps us synthesize what’s already in our head. The synthesis is even more important than the artifact, because it’s what makes knowledge meaningful and actionable.    (KE6)

The payoff for writing this blog has been enormous on a number of levels. It offers a lens into my values, thinking, and activities, which has helped establish my credibility and reputation. It’s allowed me to have valuable conversations with others that would not otherwise have happened. It’s strengthened my professional social network. And because it’s public, it’s enabled some serendipitous connections (Leave A Trail).    (KE7)

All of these things are great for business, and so on that level, writing this blog has obviously paid off. But its biggest impact has been directly on me. The act of writing this blog has made me smarter. I know a lot more about collaboration, and I can articulate what I know much better. This alone has made writing this blog more than worthwhile.    (KE8)

As a Knowledge Worker, when I blog, I’m not doing additional work. I’m simply working.    (KE9)

Leave A Trail: Stigmergy and Effective Large Group Collaboration

Posted on Published by Eugene Eric Kim

One of the challenges with large group collaboration is keeping track of what others are doing. With a small group, the project manager or group leader can take on the responsibility of keeping others informed. If it’s a single organization, you can theoretically mandate a communication strategy from above, although in reality, this doesn’t work effectively when the organization is large and diverse. For large-scale collaboration between different groups, neither of these are realistic options.    (KCB)

How can large groups communicate most effectively? The answer is stigmergy, a term Chris Dent first introduced to me about four years ago. Stigmergy is a form of indirect communication where organisms react to signs left by others. Ants communicate by stigmergy. They leave a trail of pheremones that other ants pick up and react to. Stigmergy — not centralized command-and-control — is responsible for those amazing anthills.    (KCC)

There is an equivalent pattern in effective large group collaboration: Leave A Trail. I’ve called this pattern Think Out Loud and Visible Pulse in the past, but I like “Leave A Trail” better, because of its association with stigmergy. (Obligatory karma reference: I first heard this name from Peter Kaminski, who in turn credits Chris Messina for explaining it as a principle of Bar Camp.) MGTaylor calls this pattern Ship Product and often describes it in the context of Stuart Kauffman‘s work and patch theory.    (KCD)

The idea is simple. When you work, leave an artifact somewhere where others can find it. An artifact doesn’t have to be comprehensive; in fact, it’s often better when it isn’t. A brief meeting summary is usually more useful than a full transcript. A brief summary with links to specific instances in the transcript is even more useful.    (KCE)

When you Leave A Trail, you’re communicating to whomever wants to listen, which may effect how you express yourself. This can be disconcerting to some. People often point to the lack of response as a sign that tools like online forums, blogs, or Wikis aren’t working. That’s not necessarily the case. There may be a whole slew of lurkers who are reacting to the signs that you are leaving. (That said, Immediate Feedback is also an important pattern in Online Communities.)    (KCF)

This can also be difficult when determining what kind of trail to leave. Because you don’t know who will be reacting to your signs, you can’t target them. The solution is to Scratch Your Own Itch.    (KCG)

Emergence can’t happen without Leave A Trail. However, Leave A Trail is just one of many conditions for emergence. You can’t dictate whether emergence will happen, and when it does, you can’t control what actually emerges. The best you can do is create conditions for emergence and hope that good things happen. This is disconcerting to many, and folks often react by trying to assert more control, which makes things worse.    (KCH)

Leave A Trail and other principles are helpful in designing community spaces. For example, if you are trying to integrate blogs or Wikis into a community’s practice, the best way to do that is to apply the tool in such a way that it scratches an individual’s itch while also leaving a trail. For example, many good project leaders are good at doing meeting summaries. Instead of having them email a small subset of individuals, have them email a public, archived mailing list. Better yet, have them blog their summaries and email links to the blog. You’re not significantly changing individual behavior in these situations, but you are significantly improving your chances for large-scale collaboration.    (KCI)