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)

Community Engagement and Dynamic Knowledge Repositories

Posted on Published by Eugene Eric Kim

One of the benefits of working on the Hyperscope is not just working closely with Doug Engelbart, but also with many of his long-time colleagues, not the least of whom includes Christina Engelbart, his daughter and former business partner. Christina and I recently had an off-the-cuff exchange on community engagement and maintaining a Dynamic Knowledge Repository (DKR), and it’s started to evolve into a full-fledged discussion. Rather than continue it over email, I thought I’d post some of my thoughts here, especially since they relate to my recent post on Leave A Trail and stigmergy.    (KDW)

On the surface, maintaining a Dynamic Knowledge Repository and community engagement would seem to be two separate actions. Christina suggests that the former is a more tangible entity, whereas the latter is a process. I agree with this distinction, and I would also note that the artifacts of community engagement are part of a DKR. So you’ve got the engagement itself (process), and you’ve got the artifacts of the engagement (part of a DKR).    (KDX)

The distinction starts to blur when the engagement occurs over a digital medium. If I exchange email with someone, then is that community engagement or is it part of maintaining a Dynamic Knowledge Repository? It’s both, because the act of engagement also results in an artifact!    (KDY)

Why is this important? Because when we think of the two as distinct actions, then doing both means double the work. When we think of the two as having significant overlap (via relatively minor shifts in work practice), then we get (at least) twice the benefit for half as much work.    (KDZ)

This conflation is central to methodologies like Dialogue Mapping. Jeff Conklin talks about the importance of Shared Display as being part of the conversation. When the screen is physically part of the conversation, then participants engage with the screen as if it were another participant. That creates shared ownership over the artifact, which makes the artifact far more valuable than a meeting summary that some guy in the corner scribbled onto his laptop and emailed out afterwards.    (KE0)

The benefits multiply even more when you take into account Leave A Trail and scale. Having a closed DKR for a small team is valuable, but opening that DKR up for the entire world to see increases the potential for serendipity and emergence.    (KE1)

I would argue very strongly for folks to think about community engagement and maintaining a knowledge repository as part of the same bucket, because they should be very closely tied to each other. For example, when I add content or refactor the public Hyperscope Wiki, I consider that part of my community engagement strategy. That said, these two concepts are not identical. This is important to remember also. Simply dumping information into a public repository is not a very effective community engagement strategy. However, proactively reaching out to people and encouraging them to interact in the public repository is a great community engagement strategy.    (KE2)

Jeff’s framing is probably the best way to think about it: Your knowledge repository should be thought of as a participant in your collaborative process, not just something external.    (KE3)

PurpleFS

Posted on Published by Eugene Eric Kim

Paul Visscher announced PurpleFS:    (KCN)

PurpleFS is a FUSE filesystem that allows you to transclude Purple Numbers.    (KCO)

In other words, PurpleFS is a filesystem interface to the Purple library. Super coolness.    (KCP)

(This, by the way, is an excellent example of Leave A Trail. Paul is part of the Church Of Purple, and there were any number of public places he could have announced this tool. I didn’t happen to be on any of the ones he chose (although it’s also possible that he just hasn’t posted to any of those places yet). And that’s perfectly okay, because he blogged it, and I follow his blog. He left a trail. It’s nice and efficient for all involved. It’s loose coupling, but it’s tight enough to maintain a sense of community and to enable tighter collaboration in the future.)    (KCQ)

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)