Several people from the Fall 2009 Foundations of Communities of Practice workshop have continued meeting every few months to catch up with each other, find out what people are working on, and swap stories. In a way it’s a CPsquare dream that people should connect so much during a workshop so that they would want to keep in touch like that afterward. Dreaming and wanting it is not enough, so we always try to plant the seeds, so when it does happen it feels great! And in fact it’s a valuable conversation, as this report tries to show.

During the Foundations workshop we try to establish the practice of using a teleconference to think together in a very open, self-organizing and relaxed way, allowing the conversation to turn in whatever direction seems to make sense. And we support that practice with MP3 recordings and a chat that captures the main point of our meanderings. It turns out that the logic of the conversation may not be clear at all in advance, but in retrospect you can always see how it makes a lot of sense. I personally have learned a lot about myself, how I facilitate or participate and how I interact with different people by listening to the recordings we make (primarily for the benefit of people who didn’t make it to a meeting). The chat transcripts are very handy for looking up ideas, getting URLs, or making a summary of the conversation. All of that collective context and experience is the base from which we could cantilever out.

At one recent meeting of this group someone was talking about using video for community meetings. We decided to hold a more focused meeting this last time where we experimented with one tool.

Last week we experimented with TokBox.com, a video meeting tool. It’s a free tool that sets up a “Hollywood Squares” kind of format where everyone can see everyone else who has a video cam. In a way *the way that we explored it* is was as interesting as the tool itself. Two people met on TokBox beforehand and found that they had some audio feedback problems, so we decided to use the CPsquare phone bridge for the session’s audio channel. Someone sent out an email invitation to all the workshop participants, (whether they’d participated in these interim check-ins or not). It named the phone bridge as the initial meeting point and the first thing each person had to do when they arrived at the TokBox meeting page was find the mute button so that anything they said (or heard through the TokBox audio feed) wouldn’t disrupt the conversation. One of the people who had explored the tool beforehand sent out session invitations during the call by email as people showed up on the phone bridge.

It’s obvious that to explore a social tool like TokBox you can’t do it alone. You need partners. But to find out how it supports a conversation, you need to have a conversation. So you need other people who share your language, are willing to explore the tool, and can connect (and re-connect when you fall off the call). In particular it’s helpful to have a back-channel, whether email or a Skype chat. Several back-channels are helpful, actually. Our phone bridge was a back-channel and the backbone of our conversation. We cantilevered out from there. And the standard against which we measured the tool was known to all: our previous conversations on the phone bridge.

In addition to the phone bridge connection, during the session several of us were also connected via a Skype group chat. Most but not all of us were on the TokBox site. Several people didn’t have a video connection (or maybe they were having a bad hair day?) and one just listened in on the phone (e.g., a mobile phone while driving). At different points we experimented with TokBox’s auxiliary tools like its chat tool, its etherpad, and some others. All of that makes for a very complicated group structure. All of us could hear, but what each person could see was not the same.

The conversation was very much about observing out loud what we were seeing, considering how it worked for us, and thinking about how it would work for the several groups that each of us work with professionally. Was there value in seeing other people’s faces via the group video? (Answer: for some, but not all.) How would the tool work for a lecture or for a more horizontal conversation? What were the set-up issues in terms of inviting other people to join on the fly? Was there a difference between using the TokBox email invitation tool and sending the URL by some other means? (Answer: not much.) Although some web conferencing software completely lock down the structure and shape of the interface, TokBox lets you float video windows around, open and close apps like etherpad, and much more. What are the benefits of that kind of malleability? Does it also cause problems? (One of us kept getting dumped from the video connection whenever we entered an etherpad window. We never figured out why.) We compared TokBox to others that we’ve been exploring, including:

• Google’s Open Meetings
• Adobe Connect
• Elluminate
• DimDim

(there are more tools mentioned on the CPsquare wiki)

From this example, I’m left thinking of three different overlapping questions:

• How does a community explore existing variance in the use of a tool?  What are the benefits of or problems with uniform competence in using a tool once a group has settled on it?  In this example, some people didn’t want to use video at all or found that it didn’t add much to their experience of closeness beyond what our phone bridge provides.  For others it added quite a bit of context and sense of closeness that was useful.
• Is it always clear what tool we cantilever from?  Does that matter?  Different groups might use different technologies and will have different amounts of trust or determination to explore.  In this example, we used email to get everyone on a phone bridge from which we all got into TokBox.  Stragglers got caught up via Skype chat.  This is related with the “one more tool” question that Patricia Arnold, Beverly Trayner and I asked in the paper we gave at the Networked Learning Conference 210 a few weeks ago.
• A final question is about what this process of exploration does to the group itself.  Can it be outsourced?  Can we leverage the experience of others?  What are the implications of having others do the exploration for us, be they experts in your company’s IT department or technology stewards or whomever?  In this example we were very much doing it for ourselves and that certainly colors our experience.  How important is first hand experience of exploration?

TokBox came out looking really good! And it was great to see our learning companions!

Photo by Pete Lewis.

Tags: chat

Kathy Milhauser mentioned that she assigned Digital Habitats to students in a course on globally distributed project teams. That got me thinking about the difference between a project team and a community as far as their digital habitat is concerned. Of course there are many project teams that have spawned communities and many communities that have launched projects, so there are many connections. When a project begets a community it’s often because the sense of accomplishment that people have sparks that sense of recognition of each other’s expertise and people feel that they need to stay connected to each other. I was on a team at StorageTek in the ’90’s that designed and produced a big learning event; afterward we staid in touch, got together frequently and looked for more work along the same lines. When a community launches a project, it could be to produce an event, to explore a topic, to standardize a practice, or to provide the community with a technology advance. For example, when Beverly Trayner agreed with me to head a the project to hold a dialog in Setubal in 2002, there was a clear moment when she announced that “project team rules” would apply, not the discursive, relaxed, “let’s think and talk about whatever seems important,” and “everybody gets their say,” approach that had previously prevented us from meeting face-to-face.

But there are are also differences between the two. Quoting from the Table 2.2 on p. 42 of Cultivating Communities of Practice (Wenger et al., 2002) proposes these differences:

Sometimes the two blur and the difference may be more about a point of view than anything else. In fact, it may be useful to think of project teams as if they were communities of practice in some cases, especially when teams are globally distributed, learning is a fundamental component of their assignment, and project scope is to be discovered as the project proceeds. Here are some ideas about when a community perspective on technology such as we propose in Digital Habitats may be useful for a project team:

• There are many cultural and technological uncertainties that come up when a project team is global. A part of the project’s work needs to be focused on learning how to cope with differences in time zones, bandwidth, technology environment, language, customs regarding deadlines or commitments, etc., etc. All of those elements have technology implications. The improvisational, emergent, approach we develop in Digital Habitats, and the frameworks we develop such as the polarities in Chapter 5, help us think about how to get conversations to address tricky questions issues such as, “How do we work together?”
• Who is on a project team is not always as clear as we’d like. Sometimes a key resource or contributor will be part of the network or surrounding community but not part of the formal project team. When the knowledge and skills required for a project are very cutting-edge or very diverse, project team membership sometimes can’t be known in advance, much less specified. All of the discussion about permeable community boundaries will apply in those situations because team members may need to bring an expert into a few technology-mediated conversations, not involve them in the whole project’s work-space. During the project of writing Digital Habitats, Nancy White kept repeating “Technology is used collectively but experienced individually,” (or something to that effect) till Etienne and I could say it on cue. In my observation, communities are expert at dealing with the differences in people’s experience of technology and somehow inventing ways of bringing people together despite the obstacles.
• Even when a community isn’t sponsoring a project, sometimes the community is the critical sounding-board or peanut gallery for the project. Unless the project team pays careful attention to the larger community’s conversations, the project will fail. For a distributed, technology-mediated team that may require that project team members stay involved in the conversations or activities of that surrounding community (which have more fuzzy and ad hoc technology boundaries than what we normally think about as “the project area”).
• When you observe projects in real life they are quite diverse, not just the instantiation so many Gantt charts. If we look closely we might find projects that are oriented toward “meetings,” “open ended conversations,” or “access to expertise,” or “relationships” much like the orientations for communities that we propose in Chapter 6. If those orientations have technology implications, the surely the orientations in projects must also.
• Finally, when a long-running project team experiences member turn-over, there’s a need to bring new members of the team into the team’s culture and tell them the stories from the team’s history. That sounds like the time for community thinking to me. Bottom line, there is more self-selection going on in project activities than an “everybody is on task in this project” kind of perspective would suggest.

Of course there’s the question of whether project teams can learn more from communities or the other way around.

Tags: projects

You probably already know that Skype is a great tool – especially for community leaders. If you are a technology steward, you’ve got to know how to use it and talk about it, too.

To really talk about how to use a tool we’ve got to talk about all the buttons and about the user’s context and experience.  How we talk about the buttons and about people’s experience matters, given that we have so many tools to choose from, that we use them in tandem and that that the tools a community uses interact with each other in complex ways.   The experience using a tool and of talking about it affects usability, learning and collaboration.  This matters even more when we’re talking about technology at a community level.  Skype is complex enough to demonstrate the issues involved in understanding a community platform (even though we usually think of it as a personal tool). This post uses the language we developed in Digital Habitats to make sense of how Skype fits in the technology landscape.

First of all, Skype is not just one tool. It’s a platform with lots of different tools on top of it. The tools in Skype are essential for my work as a community leader. If you follow this discussion about how all of them work together, you’ll have a good example of the approach we developed in Digital Habitats to make sense of platforms in a way that brings out the issues around tool comparison, duplication, and integration.

A phone

It looks like a phone

The most obvious thing to notice about Skype is that it works like a phone. (Another phone? I already have several! My phone call arbitrage is complicated enough: I pay a flat fee for my plain old telephone system (POTS) land line for local calls and for long-distance within the US. And I already have a pre-pay scheme for cheap international phone calls! And I have a cell phone in my pocket. Why do I need another phone?) Well, Skype is actually two phone tools that have useful features in and of themselves and are integrated with other Skype tools that I’ll talk about below. The two phone tools are different in that one is for calling a POTS phone with a number and another for calling other Skype users (with a Skype ID)

One-to-one interaction on-the-spur of the moment is ideal for reaching out to community members – to find out what’s on their minds or provide exactly the help that they happen to need at that moment. In my community work I make it a point to ask people for their POTS phone numbers or Skype IDs.

In this post I discuss several Skype tools (not all of them) in terms of how their features are useful, how they work with each other and how they work with tools on other platforms that people in my community might use.  In a way this puts to work some of the analytical framework we develop in Chapter 4 of Digital Habitats. The polarities discussed in Chapter 5 are a big help in organizing our thinking about these issues.  So I represent each tool with a screen-shot and a diagram below it suggesting how the polarities seem to me at the moment.  The phone diagram shown below indicates that I think the phone is on the participation end (unless you reify the conversation with a recording); you have to participate in real time, so it’s synchronous (exchanging voice-mails moves the red triangle toward asynchronous); and it’s a one-to-one experience, so I place it close to the individual end of the spectrum.  The placements in this diagram then determine the placement of the tool in a tool landscape at the end of the post.

My impression of Skype as a phone

Each of the two phone tools has its interface: the Skype-to-POTS interface has a keypad that looks like the keypad on a regular phone. When clicking on the keypad gets tedious, you can just type in the number you’re calling in a text box labeled “Enter phone number.”

Lots to do with a contact

Notice that the two tools are really different in cost and function: it costs a small amount to call someone on a regular phone and you can’t receive a call back from them unless you buy a POTS number from Skype. A Skype-to-Skype call is free and it’s very easy for someone to call you back if they miss your call.  Integration asymmetries between Skype and other platforms force different interfaces, so make me think that Skype has two different phone tools.

Contact list

You make a call to another Skype user using its contacts list tool. The contacts tool partly overlaps with my Outlook, Gmail, and mobile phone contacts tools, but it does things that the others don’t. One is to show who’s currently “available,” indicated by a green dot with a check-mark in it, so it works like a global “presence indicator.” Also, you can group contacts, rename them, send them to other Skype users and perform various other actions.

Your personal contacts list is available whenever you log onto Skype – from whatever machine you use. (Surprisingly, the same account can be logged on from two different machines.) When you click on a Skype contact, you have the choice of calling their regular phone, which will cost you but is more attention-getting, or calling them on Skype which only “rings” on their computer.

In my opinion the most polite way to reach someone is to first check if they are available using the text chat tool (discussed next) and then call them on Skype or by regular phone only after the other party has responded that it’s OK to call. If we’ve made an appointment to talk and the other party doesn’t respond, I may call them on their regular phone, which rings loudly (and may be a mobile phone that they carry with them).

Chat: SMS and alert

Like the phones, Skype’s text chat tool is complicated: it’s the same on the front end, but different on the back end.

I'm running late

The text chat with other Skype users is a full-bore chat tool: like an instant message tool but better because it’s integrated with other Skype tools. For me it is the most frequently used of all Skype’s tools. Messages can be long and replying is easy. The interface is clean and it’s very robust: people are not dropped off a chat and they receive chat text even if their machine crashes. Skype keeps the chats on your machine since you installed it and you can search through them.

You can send a 160-character SMS text message to a mobile phone from the same window you use to call a POTS number (provided the number goes with a mobile phone). That’s handy but asymmetrical because a reply message from a mobile phone can only go back to another mobile, not to you on Skype. So it works more like an alert than a conversation tool.

Skype alert

Nancy White and I regularly use the Skype text chat as an alert – to drop notes off on each other’s desks. Often the drop-off is a URL and the message is no more than “Hey, look at this!” A direct message on Twitter or the inbox feature on http://delicious.com would be obvious alternatives, but on a windows machine Skype blinks so it’s visible and hard to miss. No response is required but an alert can lead to extended conversations.

Chat is one of the most versatile tools we have. A chat is useful for alerts, for sharing, for conversations, for negotiating meeting times, and on and on. It’s ironic that there are so many different and incompatible chat protocols and tools. Once you have a chat connection with someone the possibilities for collaboration increase dramatically.

A profile that gets used

How many profiles have you grudgingly completed in your life, imagining that someone you really need to be in touch with will find you? One for each community tool you have ever used, perhaps. If you’re like me, you’ve completed dozens of them and probably most of them are now out of date! Our likelihood of keeping them up-to-date depends on how frequently we use a tool or how close at hand the profile tool is. I keep my Skype profile current because I consider it an interaction tool, not just a publication. Skype’s profiles are in a proprietary format and not available outside of Skype.  However you can send a profile to another Skype user.

The Skype profile tool is an example of a tool that’s mostly an individual’s public description of themselves. But when you use the “mood message” to let people know where in the world you are or what you’re doing, it’s an interaction kick-off.

Hello world

Skype makes other people’s profiles useful by letting you modify or add to the information that they provide. Skype lets you edit other people’s names, which I find is handy if people haven’t completed their profile. Also, if you have a private phone number for someone that they don’t post on their profile, you can add it to your copy of their profile.

Skype would be a useful platform just for its one-to-one phone calls and text messages, but it becomes indispensable because the audio and text tools work in a many-to-many mode. Skype as a conferencing tool makes it a real community platform, especially given how all the other tools are integrated on the platform. Here again the user interface masks differences on the back end. A group chat is extremely robust, working in a point-to-point fashion: any one of those on the chat can drop out (e.g., turn of their computer) without affecting the others. And when Skype comes back up, the intervening text messages that were exchanged among the other parties to the chat magically appear on the machine that dropped out.

Group Chats

Chat is the workhorse

Audio conferences (not shown in a screen shot) are different: all the audio signals go through the computer of the “host” who initiates the call. If the host drops, the audio call ends for everyone. It’s important for an audio conference to be initiated by the person with the fastest and most stable Internet bandwidth: if the host is on a dial-up connection or an overloaded wi-fi network, it will impact everyone.

Another difference between audio conferences and text chats has to do with scale. A large number of people can be on a text chat, but an audio conference starts getting noisy and unstable well before running up against the Skype maximum of 9 callers.If everyone is on Skype, conference calling and group chat are nicely integrated. You have a “call Group button” to launch an audio conference from a text chat and a chat transcript appears automatically when you are on a group chat.

When a group is working on a project over a long period, for example, a long-running Skype chat is a great way to keep everybody connected and focused. Ten weeks is the record in my experience. When you turn on your computer in the morning, all the conversations between people in different time zones pop up.  The flexibility of chat makes it an ideal tools for coordinating work on other platforms.

Contact groups

Which list are you on?

Over time you accumulate a lot of contacts in Skype and it’s very helpful that Skype lets you organize them into Groups. Skype automatically creates some groups, such as “recently contacted” or “requests from new contacts.”  But you can create as many groups as you want.  Adding people to or removing them from a group is easy and you can put people in multiple groups.

The groups tool is useful in combination with other tools.  For example, when you select a group, you can easily see who is currently logged on to Skype.  What that means depends on whether being logged on to Skype at a given point is a norm in that group of people or not.  A Skype group makes it easy to start a group chat or a group audio conference.  One advantage of using a group to set up a chat is that you include people whether they are logged on or not; when they do log on, the chat messages will pop up on their computer.

So what?

Classification a tool using these polarities always seems debatable..  We developed them as a natural way to help a technology steward take a step back from the hands-on level and think about the experiences that enable a community to be together and to learn.  This tour of Skype is not meant to prove anything: it’s more suggesting a way of making sense of a technology.   Here are some parting thoughts:

• The polarities and how they play off of each other are intuitive  and practical. They are most useful as a stimulus for conversation.
• Tech stewards need to understand what it’s like to use a tool and to be able to talk about the experience and the tool separately.
• Preferred, ignored, duplicate, or competing tools all make sense within this social and technical mix we call a digital habitat.
• Each software feature makes sense within the context of a tool, and each tool is framed by its position on a platform, which has meaning in the context of a configuration that’s shared by a group of people.
• In a way it’s all circular because you can’t see a community’s configuration (or digital habitat) directly or simply.
  • You can’t stand outside of your own digital habitat
  • You can’t really see a community unless you’re participating in its habitat
  • Seeing a community’s habitat as members see it requires relationships and access to their practices, habits, and cultural context
  • Understanding the role of a tool in a habitat involves a sense of shared timing and even group improvisation

A provisional placing of Skype tools on the digital landscape

What do you think?

(Cross-posted on the Digital Habitats blog.)

Tags: chat, skype

Face-to-face conferences aren’t what they used to be and that’s ok with me.   How many times have you gone to a face-to-face conference in another city where you rub shoulders with a lot of strangers, listen to a bunch of talking heads with obscure PowerPoint slides in cold dark rooms, make a few acquaintances at the reception, give your talk to a group that may or may not get what you’re talking about, and come home with a printed proceedings that goes on the bookshelf?

My days of passive participation are over and done with:

• For me, the reason to go to a big conference is the small group conversations with people I already know somewhat or with whom I share a common interest
• We have the tools to coordinate and connect before, during and after the event — to keep the conversation going (it starts before the conference and goes afterward as well)

I always want to know who else is attending an event, what they’re thinking about, where people are staying, and where we’re going to eat.  During the conference, it’s useful to eavesdrop on parallel sessions that I’m missing by watching the twitter stream.  And it’s helpful to be able to look at people’s slides right away, and to find related materials that’s mentioned or written during the conference.   And it’s nice to see photos of the event afterward, too.

Tagging before, during and after a conference is a key tool for using a big conference as a kind of host system a smaller group that wants to connect.  The economics of face-to-face meetings leads to big conferences.  The economics of meaning-making require smaller, but not closed, conversations.

Apart from email, forums, teleconferences, mobile phones, and other technologies, tagging is useful for enabling a small group to use a large conference as a platform for its own purposes.  It’s an example of a technology that allows the integration across tools by means of a practice and a protocol (as we discuss in Chapter 4 of Digital Habitats).

Using CPsquare’s “sidecar” participation in the AoIR Conference (which coincided with the EPIC conference) as an example, here are some observations of how tagging can play a role in supporting a subgroup’s participation at a big conference.

• Emergent intention.  Early on nobody knows for sure who will be there and therefore whether it’s worth going.  Email discussions about who’s going are key to establishing that there will be some kind of quorum which would make a long trip worthwhile.  But at a certain point, tagging the resources that emerge is essential.  Four months after tagging the AoIR conference, for example, we noticed that the EPIC conference was scheduled the same week.  That coincidence turned out to be a key to the dynamics of the conversation.
• Fuzzy social boundaries.  Tagging is open in the sense that anybody can use it and it’s visible to everyone. Tagging prospective participants or presentations is a way of encouraging participation.  Looking at the tagstream, for example, you can see that Sus Nyrop, who did participate, was hoping that Christina Costa would join us (although she couldn’t make it in the end).
• Identification of relevant resources .  Being together at a conference may focus on a particular topic, but you have to identify a lot of other relevant resources like where to stay.  We used the lodging page from a previous conference in Copenhagen to figure out where our group might stay.
• Multiple outputs. Active participation generates a lot of different outputs. Tagging is the ideal way to keep track of them.  Delicious links are here. Flickr photos are here.  Not much video produced at that conference.
• Distributed leadership. Although I used the “cp2oir08” tag more than anybody else, others used it as well.  The goal is to coax people to contribute, whether it’s a tag you came up with or not.

Tips

• Propose a tag early.  Announce it by email or by other means to get the word out.
• Tag should be as intuitive and descriptive as it can be but as short as possible.
• Weave tagging into group practice and tagged resources into the conversation.  Mention what’s been tagged by you or what you’ve found in the tagstream that others should know about.
• Think of the tagstream a community-building resource. A tagstream is the accumulation of tagged materials contributed by everyone, which  is stored on a tagging platform such as delicious, and which retrieved or monitored via an RSS feed (but which can also be viewed as a web page).
• Identify related or parallel tags (such as “ir9” that was used for the AoIR conference as a whole on Flickr, delicious, and Twitter).
• Think of the tagstream as an ideal research tool, when you’re going back to figure out what happened or when.

Photo by Bev Trayner.

Tags: face-to-face, tagging

A perennial question in supporting a community is how to focus conversations.  How to dig deeper into a topic, explore new perspectives, or move a conversation forward over time.  Those are questions that a community insider may be able to answer but may not be answerable by people who are not members, not involved in the conversation, not “initiated,” not “hip.”  The bottom line, of course, is whether people participate and learn from the conversations in the community.  And of course you never really know in advance.

But I think that “uniqueness” is a good proxy for working purposes.  In other words: could (or should) a conversation we’re proposing for your community be happening elsewhere?   Why here?  Why now?

I’ve admired CHI-FOO because its programs have been thought through a year at a time.  That takes a lot of work and a lot of focus.  That kind of planning is likely to force a community to ask those questions about uniqueness.  But have a look at this bit of the 2010 program description:

The 2010 CHIFOO program series will arm you with fundamental design leadership skills and inspire you to flirt with the edges of possibility. In monthly presentations throughout the year, experienced practitioners and speakers will explore how you can:

• Navigate through power structures and create momentum for interaction design initiatives
• Ensure that your message reaches a broad audience and produces a sense of urgency
• Take calculated risks that will further the discipline of human-computer interaction
• Stir positive change in the world through design thinking

Couldn’t you insert accountants, administrators or anthropologists into that statement without changing it much?

Some other warning flags:

• I know it’s a much honored practice, but when community announcements state “at the end of this talk you will know” x, or “you will be able to y,”  I get skeptical.
• When a topic is someone’s book, like tonight at CHIFOO, take a careful look at whether the presentation is more serving the community or the speaker’s needs. The fact that I could catch that speaker at Powell’s tomorrow night or watch him on TV (or on a video of his TV appearance) does not suggest that I’ll learn much about human computer interaction at tonight’s session on “Confessions of a public speaker.”

Maybe I should flirt with Toastmasters instead?

Tags: CHIFOO

A key story in Charlotte Linde‘s Working the Past; Narrative and Institutional Memory (New York: Oxford University Press, 2009)  is about an insurance company that was having trouble getting its agents to sell certain policies.  The company’s management wanted to know whether the problem was a learning problem (e.g., so you’d “solve it” by having the training department ramp it up) or a motivation problem (e.g., so you’d solve it by changing the compensation plan or contract between the company and the agents?).  It turned out that the new sales strategy didn’t really fit in Bob’s story:

“He started from scratch, worked nights and weekends, did thousands of cold calls to build up his book of business.  And you’ve seen him now.  His efforts were so successful that now he’s driving a BMW, and takes every Wednesday off to play golf.”

Bob’s story didn’t include selling the new policies or making big changes when the company’s management decided to change direction: it was a story about arriving.  Bob’s story was invisible because it was never told as such: it only existed in snippets, as an unspoken but potent reference point in people’s minds that shaped career expectations and choices.  It came into explicit existence when the ethnographers from the Institute for Research on Learning constructed it as part of a massive ethnographic project in the 1990’s and presented it to the company’s management.

I recommended it to a rather bookish consultant friend who wrote back that he couldn’t see what was actionable or practical about it.  I’ve been wondering about that comment for a while, even as the book continues to influence how I think about storytelling in organizations and communities.  Why, exactly, do I think this book is so practical and relevant?

At this particular point in history, if you doubt that it’s important to understand what’s on the minds of people who sell financial instruments, why sales agents sell (or don’t sell) something, I would suspect you’ve been living a very sheltered life. Misreading or misunderstanding organizational culture brings systemic risks.

One reason this book is not hugely popular with the storytelling or organization development communities is suggested by the fact that the story about Bob is not in the index under “Bob.”  You can find it under “discourse unit, paradigmatic narratives as, 148-49”.  So the book is a long hard slog unless you like that kind of stuff.   For better or worse I read it twice.   After I finished it the first time, I left it on a plane.  When I started over, with the idea of skimming it to re-construct my notes, I found that it was worth reading slowly a second time.  The book is chock full of big and small insights.

A fundamental point is that “remembering” is a human activity that’s situated in time and space.  Talking about “memory” as a disembodied and abstract entity is problematic and misleading. Remembering (most frequently through storytelling) is something we can observe and therefore influence if we understand what’s happening:

“A story not having a proper occasion on which it can or must be told exists in an archive if it exists at all…. If there is any place where the process of institutional remembering can be deliberately altered, it is the creation, maintenance, or abandonment of narrative occasions.” p. 222.

You have to be listening at the right time and place.  In fact Linde has a scheme for classifying narrative occasions on p 47:

Whether this is the frame you want to use or not (where exactly would you place my story of reading Linde’s book twice?), it seems to me that having some frame or other is really useful.  The situation matters: where a story is told, when, with what purpose, to whom, and how it is varied to fit the situation are fundamental to making sense of it.  A frame like hers does a lot of work, like helping you detect repeated stories, commonplace stories that anybody can tell (e.g., you can tell it in some situations even its about events you yourself did not witness), or even detect stories that are not told (I think detecting meaningful silence is a big deal: “Just listen for it” says Linde).

Linde’s emphasis on the situated nature of storytelling connects with another fundamental with practical implications: stories are social, jointly produced by teller and listener.   Telling stories that make sense is a social obligation:

“This creation [of narrative coherence] is not a light matter; it is in fact a social obligation which must be fulfilled in order for the participants to appear as competent members of their culture.” p 4.

If we live in times of change, then this should be a good time for telling stories and for understanding what we’re doing when we’re telling them:

“Times of change are rich in occasions when the past is invoked.  The past is used to reaffirm a sense of identity, to provide a ground form which to assess the effect and meaning of changes, and to provide a basis for critique of changes.  It is at times of change that a particular way of being is constructed as the past.” p. 43

When you think about how many books on storytelling come down to endless bullet lists and instructional bromides, it makes you appreciate what a huge accomplishment it is that Linde’s Working the Past is actually a good yarn about storytelling.

Last week at the KM4Dev conference in Brussels, I struck up a conversation with Joseph Sikeku, who talked about community leadership and technology stewardship in a radically different setting: a radio station in Tanzania.  Sikeku’s project uses an interesting mix of technologies:

• 5,000 Watt FADECO radio station
• Small blue “sensor” or integrated circuit audio recorder
• Mobile phones

Of course the key to making all of this work is the network of people around his project in terms of friends and collaborators, farmers who participate via recorded interviews or mobile phones.  (A lot of stories about innovation in Africa were floating around my head from the special report on telecoms in emerging markets in the September 24th 2009  issue of The Economist: Mobile marvels).  One thing that was striking about Sikeku’s project is that it’s sustainable because it’s so local, so passion-driven, and has a long time horizon.  Not that external help wouldn’t make a difference, but it’s important that his project that’s not donor-controlled.  Its beginning and end is not timed by an external donor.  Here’s a 7 minute interview:

Sikeku’s story got me to thinking about the polarities that we discuss in Chapter 5 of Digital Habitats:

• Radio broadcasts are a remarkable technology for bringing people together across great distances.  It’s so prevalent as to be unremarkable.
• But radio is a very group-oriented tool, so tools like an audio recorder or a mobile phone pull the community’s configuration toward the individual end of the polarity.
• An audio recorder supports the asynchronous side and the mobile phones (either as audio devices or for text messages) support the synchronous.

It seemed to me that the technologies that Sikeku mentioned all balance each other nicely when you consider that we developed these polarities studying communities that are quite different from his. That’s one of the exciting things about this project: finding out whether the ideas we’ve developed apply (or can be extended to) very different settings.  And the final question: will these ideas be useful?

I captured the interview on a little Flip camera, since I’ve been exploring video and social reporting for the last several months.  I used the interview the very next day in a “huddle session” about technologies and local development, gathering a small group around my laptop to look at the video, without editing or uploading it anywhere (there wasn’t really enough reliable bandwidth to upload a video file at the conference).  The huddle conversation had been difficult because of all the different meanings and instances of “technology,” of “local,” and of “development.”  But having one instance to focus on helped the conversation get much more concrete and much more productive.  A conference on the role of media in the agricultural and rural development that’s running right now suggests just how much is going on out there in this area, so the benefits of being able to focus on Sikeku’s specific case make sense.

The next day we had an open space session on business models for learning communities.  Sikeku participated in the discussion, which tied some of the issues from his experience to other examples where donor funding for a community had turned out to be quite problematic.  At the end of that, Sikeku remarked to me, “As a result of these conversations, I don’t feel so isolated.”  That was very gratifying.

(Cross-posted to our Digital Habitats blog at http://technologyforcommunities.com.)

Tags: km4dev, video

Last May’s CHIFOO presentation was a great talk about reading by Cathy Marshall. Here are Marshall’s slides from which I’ve borrowed some images to talk about her work in this post.

Marshall read (out loud, from the slide on the screen) that:

“Nothing is more commonplace than the experience of reading, and yet nothing is more unknown.   Reading is such a matter of course that at first glance, it seems there is nothing to say about it.”

She went on to argue that many of our commonplace assumptions about reading are wrong.  As an activity, we may think that reading is:

• stationary
• information-centric
• passive
• immersive
• individual

Instead, Marshall argued that and illustrated how reading is really:

• mobile – where we chose to read something matters hugely and we tend to take our reading with us from place to place.
• material – our physical circumstances contribute to the experience of pleasure or attention.
• interactive – we annotate pages and act upon them.
• interrupted & variable – we skip, skim, circle around, re-read and act upon reading material according to the circumstances.
• social – we share, forward, save, refer, discard and burn books and magazines in our invisible but very real social context.

There’s no problem having naïve assumptions about reading unless we’re intending to design an electronic replacement for the printed page, in which case we have to look a lot more carefully at what’s going.  That’s exactly what technology stewards need to do because, whether we’re configuring technology or planning to add a tool to a community’s overall configuration or even just supporting it on a day to day basis, we need to understand the experience of use, not just “how to use the tool.”

So we can learn a lot from the different ways that Marshall and other ethnographers have devised for getting at these commonplace experiences.  We take the ordinary as strange.  Nothing is more common than participating in a community, but a community’s configuration has a significant effect on the experience of community.

“It is also worth noting that solitary reading always was, and still is, inherently social: how we read is ultimately determined by social conventions and community membership”

You can learn a lot by observing. One piece of research that Marshall reported on examined just how complicated it is when someone reading an article in The New Yorker turns a page.  They peek forward, check an advertisement, read the cartoon, go back to verify what they last read, etc., and then continue.  There’s a lot happening that we may not bother noticing on a day-to-day level but which matters a lot when we’re thinking about designing a new electronic device.

Use a framework. One point we try to make in Digital Habitats is that it’s useful to have some framework to organize our observations. Marshall uses the CSCW matrix (that we call a polarity in the book) to look at some different instances of reading:

One interesting point she made was that people often feel like it’s creepy when they are observed doing something so simple (and personal) as reading.  As technology stewards we often have to enlist people’s cooperation, sometimes as fellow-researchers and observers of their own experience.

Compare (lots of) individual instances. In one of her studies Marshall bought multiple copies of a popular textbook and compared how students had annotated the text.  Turned out there was a lot of variation in what was important to different readers, but also convergence on the main point.  But the key idea is: how can we find ways of seeing how different people see?

This is similar to a tech steward’s practice of observing how different communities use the same software, or how they might configure it differently, or how they might even decide upon using it for quite different reasons.

One interesting thing about Cathy Marshall as she spoke to a group that’s mostly concerned with design was that she always spoke as a researcher — not venturing to speculate widely, but reporting on her own rigorous research.  Even though she committed apparent faux pas such as reading her slides aloud and there was very little (if any) “how to” in Marshall’s talk, the CHIFOO folks hung on her every word. It reminded me that professional, hands-on communities like CHIFOO are very sophisticated when it comes right down to it.

Tech stewards as ethnographers. Of course there are big differences between tech stewards and ethnographers.  Front loaded education is the norm for people who call themselves ethnographers, whereas most tech stewards come to their craft almost by accident – pressed into service and learning as they go.  Having Microsoft and other companies fund your observations like Marshall has enables a great deal of care and depth; most tech stewards are in a hurry and have to act on their hunches. And yet, the opportunity for observing change in human experience and contributing to its evolution (over shorter- or longer-terms) is common to both.  What tech stewards have lacked is a common literacy to talk with each other and the community context where their conversations can add up.

Tags: CHIFOO, ethnography

I’m organizing the fourth year of CPsquare’s shadow the leader series. We’ll be visiting with Josien Kapma, a Dutch dairy farmer living in Portugal every month for a year.  She’s a member of CPsquare and the leader of “Melken Over De Grens” or “Milking on the border” — http://www.melkenoverdegrens.nl. It’s a global community for expatriate Dutch dairy farmers that’s developing its learning agenda and trying to find its legs at the same time (in terms of organization, business model, funding, and learning activities).

If you are really interested in communities of practice, you should join us as we consider questions such as:

• In what ways is diversity and a global diaspora a resource for a community? In what ways are those characteristics a challenge?
• What individual and group interests are served by the community? How are they balanced? What leadership is needed and can leaders be compensated for their work, apart from learning as a leadership benefit?
• What activities make sense and what publications are useful in the development process?

The goal we set for ourselves in Shadow the Leader is to meet and reflect with a leader of a community of practice over a sustained period of time, getting to know a lot about one community.  It’s an opportunity to consider what we really know and really understand in terms of theory, of technology and of leadership.  From the very beginnings of this field, starting with Lave and Wenger’s Situated Learning, we have made progress due to scrupulous observation that took into consideration what we think we knew about learning but questioned our assumptions at the same time.  The “Shadow the Leader” series has operationalized that systematic scrutiny and reflection in the life of CPsquare.

In considering whether to take the Foundations of Communities of Practice workshop, a PhD student in the healthcare field wrote asking whether the workshop would be useful to her, given what she was doing:

I am going to examine what [communities of practice are already there in an academic health care setting] …. or as I suspect the lack of of them… and hopefully determine what those challenges [to their development] are, using an institutional ethnography approach.

I wrote back that …

Detecting silence or absence is huge, and they are only visible with careful ethnographic observation informed by theory.  Last week the keynote at the http://epic2009.com conference was Gillian Tett, an anthropologist who ended up working for the Financial Times and noticed that there was an awful lot of silence around the global debt markets in 2007, despite the fact that they were much larger than the equity markets. There were a lot of reasons to not pay much attention to the debt markets at that time.  Careful ethnography that paid off in the most unlikely setting.

I can’t resist asking whether you’ve bumped into Charlotte Linde, Working the Past; Narrative and Institutional Memory (New York: Oxford University Press, 2009) http://isbn.nu/9780195140293 … a fellow-alum of the Institute for Research on Learning with Etienne. She’s using a vast ethnographic study of an insurance company, she sets up a powerful analytical framework and one of her chapters is about silence and “stories that are not told”… Well worth the read.  (I reviewed the book in more depth here.)

Contact with Etienne is an important part of the workshop experience. He’s great to talk to —  and he has a great way of sharing access to current practice in many different settings. But it’s also really important to participate in a wider conversation of people who are exploring and applying these ideas in all kinds of settings. The practice of cultivating communities takes more than research.

While I’m at it, I’m hoping you’ve connected with this group (or at least read their stuff). Fung Kee Fung, Goubanova and Crossly are 3 of the authors who’ve all done the Foundations workshop (at one time or another):

http://www.implementationscience.com/imedia/1788022150101911_article.pdf

A final thought: if part of what you’re looking for is absence of communities of practice (partly with a view of suggesting change to enhance learning in a complex system), you need to develop a pretty sensitive eye for the diverse kinds of communities that are fully functional out there.  This workshop can’t be the last word on that subject, but it does bust some of the stereotypes that many of us adopted from reading about the “Turbodudes at Shell” in Cultivating Communities of Practice.

Tags: cpsquare, foundationsworkshop