Fri, May 01, 2009
Words and Reputation #
Over at the BlueOxen blog, I wrote about how I've incorporated ContextualAuthorityTagging (your reputation in context) into my work. (N5Z)
In the piece, I started using myself as an example. I listed three words that I would use to describe myself in a work context. I then started to contrast this with words that my colleagues might use to describe me. Then I stopped, thinking, "Why make up words that others might use to describe me, when I can get actual words?" (N60)
Enter Twitter (and by extension, Facebook): (N61)
Please help with an ad hoc experiment. Reply with three words that describe me. Will blog an explanation and the results. (N62)
In retrospect, it was an incredibly self-indulgent thing to do. When I do this exercise with groups, it's anonymous, and all of the participants are doing it for everyone. Neither was true in this case. No one was going to voluntarily say something critical for me, especially without understanding the purpose. Furthermore, I'm usually doing the exercise in a specific context, which is a big part of the point. The beauty (and challenge) of Twitter and Facebook is that my networks there cross all sorts of boundaries. (N63)
All that said, the exercise was still instructive in many ways: (N64)
Most words were only used once. The larger words were repeated one other time. This distribution makes sense, given the multiple contexts of my friends and colleagues. One of my friends wrote, barbecue, something that most of my colleagues probably don't know about me. A few of my colleagues wrote, wiki, which probably wouldn't come up first for most of my personal friends. (N66)
No one repeated any of my words, which surprised me. (Can you guess which three words were mine? See my other post for the answer.) The words that folks did choose certainly paint a fuller picture. (N67)
I love how a few words can tell a rich story. GabeWachob contributed "Eugene Lee doppelganger," is a reference to the parallel lives that EugeneLee, the CEO of SocialText, and I seem to lead. (I'm younger, but Eugene has more hair.) My friend, Elizabeth, wrote, "wicked scary smaht," an oblique reference to our shared ties to the Boston area. (N68)
EugeneChan wrote, "curious, competitive, cunning," a few days after I talked trash with his six year old son in a vicious game of Uno. The good folks at WikiHowl called me "myopic," hopefully a reference to my eyesight and not my vision. (They are also my new favorites for calling me, "cute.") (N69)
Which brings me to my final point. There were a few cheeky comments (Cindy and Scott, that means you!), which made me laugh, and there were a lot of incredibly nice comments, which... well, which felt good. I'm a fairly well-balanced individual with a strong sense of self ("confident" was one of the words that was repeated), and I don't need to hear this stuff to know that my friends and colleagues care about me. Still, it's nice to hear. It made my day that much better. And that's probably the greatest thing about the exercise. If at worst, all it does is elicit a few nice comments from your peers, well, that's a great thing. We don't do that often enough. (N6A)
Many thanks to all of you! (N6B)
/collaboration | Posted at 8:52am
Sun, Apr 19, 2009
MediaWiki Plugin for Laconica v0.1 #
I've been playing with Laconica for a while now, mostly on Identi.ca but also on some self-hosted sites for various projects. For the GrantsFire project, we thought that Laconica would be a great way to keep others updated without flooding our inboxes, so I installed the latest version. I noticed that there's now a plugin API, so -- with encouragement from EvanProdromou -- I decided to scratch an itch I've had for a while and write a LinkAsYouThink MediaWiki plugin. (N5W)
It wasn't too bad. My main challenge was figuring out PHP. I've looked at a lot of PHP code in my day, but I've never written a line of it until today. I thought I could skate by without spending too much time understanding PHP's idioms and idiosyncracies, but -- as is often the case -- trying to skate by ended up taking more time than learning how PHP worked. The Laconica codebase is relatively clean, and I learned a lot by reading it. (N5X)
Many, many thanks to EvanProdromou and all the Laconica hackers out there. It's an awesome tool, and it's enabling me to do some cool stuff that wouldn't otherwise be possible. (N5Y)
/collaboration/tools | Posted at 3:49pm
Mon, Mar 02, 2009
How Project Management Tools Empower Communities #
I recently posted an entry at the BlueOxenAssociates blog on Obama, Wikis, and CollectiveLeadership. The crux of the post was simple: CollectiveLeadership happens when it's clear who's in charge. (N51)
In other words, powerful communities empower their participants to lead by giving them PermissionToParticipate. 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 PersonalInformationHygiene and even better GroupInformationHygiene. The path to enabling good GroupInformationHygiene is transparency. (N53)
Good ProjectManagement tools encourage good GroupInformationHygiene 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 ProjectManagement 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, SteveKetchpel, about this phenomenon, and he shared a brilliant insight. He said that most ProjectManagement 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 ProjectManagement 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)
/collaboration/tools | Posted at 12:00pm
Thu, Feb 05, 2009
Straying Off Point #
Meeting Best Practices #1 and #2: (N3K)
The meeting facilitator's challenge is to keep the group on point and to finish the meeting on time. That's where the agenda comes in. (N3N)
Here's the problem: What if the agenda is wrong? (N3O)
We decide to the best of our abilities what the agenda should be, based not only on the goal but on the makeup and state of the group. The latter factor tends to be the trouble-maker. Everyone may agree that the goal of a meeting is to come up with an action plan that everyone stands behind, but what if the people in the room all speak different languages or have different understandings of the problem? You have no chance of creating that action plan without SharedUnderstanding and SharedLanguage, and so an agenda focused entirely on making a plan is doomed to failure. (N3P)
The challenge is knowing your group well enough to make these decisions. That's why I often say that good design is more crucial to a meeting's success than good facilitation, because you are tackling these questions before you even step into the meeting. (N3Q)
What happens if the goal shifts? This happens often when the problem is complex enough. Everyone agrees before the meeting on what the problem is, then in the course of collectively drafting a solution, you suddenly realize that you don't understand the problem after all. Now the facilitator's role is critical, because he or she needs to decide whether to stick with the agenda or revise it on the fly. (N3R)
The reality is that agendas are important, but they need to be fluid. As a facilitator, you need to reserve the right to stray off point if you feel like the situation merits it. This is one reason that I feel so strongly in hiding the agenda, especially with the kind of highly emergent meetings that I usually design. People tend to cling to the agenda like a life-preserver rather than risk swimming into the unknown, which is certainly scarier, but is often necessary. It's better to trust the facilitator to stay on point and stray off point when the situation merits it. (N3S)
This is also why I like DialogMapping so much as a facilitation technique. With DialogMapping, the emergent structure of the conversation along with the key underlying questions are explicit and apparent to all of the participants, so that you can effectively leverage the CollectiveIntelligence of the group rather than rely on the facilitator to be the sole driver. (N3T)
/collaboration | Posted at 5:36pm
Thu, Dec 18, 2008
The Unexpected Pleasures of Open, Transparent Processes #
Every project has a team. How those teams form is an interesting question. For the most part, the "leader" of a project decides who is on or off a team, and then they go off on their merry way. (N2B)
If that work is done openly and transparently, then that opens up the possibility of attracting other contributors. This is the essential goal of movement-building, where the desire is to get other people to act. It's also what makes OpenSource software projects and Wikis work. (N2C)
The question is, how open and transparent should the process be? Being fully open invites distraction. When the ChandlerProject was first announced, list activity went through the roof, and the signal-to-noise ratio was very low. People were galvanized by MitchKapor's involvement and, of course, everyone had an opinion. It was a dangerous time for the project, because the goals were not concrete, and the process for how to reach concreteness had not yet been established. (N2D)
How do you balance the desire to be open (and attract outside contributors) with the need to get things done? The key is clarity of vision and process, as well as a realistic assessment of the risks and rewards. (N2E)
When DougEngelbart asked me to lead the HyperScope project in 2006, I knew that it was imperative that we deliver. (Visionaries have a sometimes deserved reputation for never actually delivering a product.) At the same time, we really wanted to spread the core ideas widely and galvanize the community. (N2F)
We had already decided that the project would be OpenSource, which meant that some of the processes would inherently be open -- open source code repository, open mailing list, open Wiki, and so forth. We also instituted good practices -- regularly posting summaries to the community, carrying on much of our activity online (a key principle of the Apache community), and so forth. (N2G)
I also decided that our weekly face-to-face meetings would be open as well. This was the biggest risk for a few reasons. Doug was going to attend the meetings, and there was a possibility that people would come just to meet Doug. This, in my opinion, was actually a good thing, as long as we weren't overwhelmed with people and as long as guests did not prevent us from getting things done. I reasoned that we wouldn't be for two reasons. First, Doug isn't as much of a household name as he should be, certainly not as much as MitchKapor for example. (This is sad and the topic of a future post.) Second, neither was I. I have a large social network, but it's not enormous, and it's fairly intimate with lots of trust. I didn't think a huge number of people would see my announcement, and I trusted those who did to do the right thing. (N2H)
I was confident in my ability to tightly facilitate the meetings, and I also felt strongly that the rewards of openness, in our case, far outweighed the risks. I was also prepared for the possibility that no one would show up, despite the openness. (N2I)
I was blown away by who did show up. We had a lot of folks from the old AugmentationResearchCenter, which was an absolute delight. Many people told me afterwards what a delight it was for them to have us pepper them with questions about their 50-year old work. We had many friends and friends-of-friends visit, all of whom greatly added to the conversation. (N2J)
Before each meeting, I welcomed our guests, but I also explained that it was a working meeting, and I asked that they respect our need to get things done and participate accordingly. For the most part, that's all the facilitation I needed to do. I occasionally had to reign people in, but I usually found myself actually encouraging our guests to participate. (N2K)
At our launch party, I gave special T-shirts to each team member. Two of the people on the team and on the T-shirt were people from the community who found out about our work on their and dropped in. One was JohnDeneen, a long-time fan of Doug's, who videotaped and photographed all of our meetings. The second was CraigLatta, a SmallTalk guru who had worked on a variety of old-school hypertext projects in the past and who ended up helping us tremendously on a variety of technical challenges. (N2L)
When I work with groups, I often encourage them to challenge their own assumptions about openness and transparency. Extra effort is required, and sometimes, the hoped-for benefits do not occur. However, more often than not, folks are pleasantly surprised -- sometimes even amazed -- by what emerges. (N2N)
/collaboration | Posted at 12:07pm
Mon, Oct 06, 2008
High-Performance Knowledge Work: Practice, Practice, Practice #
I talk a lot about the goal of being a "high-performance" knowledge worker, of achieving "high-performance" collaboration. I'm certainly not the only one. But what does it truly mean to be "high-performance"? (N24)
One way to answer that question is to think about fields where the answer is more clear, such as sports, music, and medicine. Last year, I wrote: (N25)
Medicine is a great model for what's in store for other types of KnowledgeWorkers in this rapidly changing world. I know very few KnowledgeWorkers who spend as much time learning and honing their skills as doctors do. Can you imagine what we could accomplish in this world if we did? T (N26)
My friend, LisaChu, founded a violin school for kids, and she often blogs about the discipline required to achieve greatness. Recently, she quoted Brian Johnson, who wrote, "The higher the greats climb, the GREATER the need for practice." (N27)
Think about the work that world-class athletes, musicians, and doctors put in to stay on top of their game: the discipline, the training, the emphasis on fundamentals. Do any of us KnowledgeWorkers really apply the same standards to our crafts? (N28)
/collaboration | Posted at 11:08pm
