Recently I finished a remarkably useful book: Mizuko Ito, et al. Hanging Out, Messing Around, and Geeking Out: Kids Living and Learning With New Media (Cambridge, Mass.: MIT Press, 2009). It has some common ancestry with ours, since the first authors of both Hanging Out and Digital Habitats were at the Institute for Research on Learning in the 1980’s. There are many overlapping frameworks and insights. Hanging Out has pushed my thinking by setting the idea of technology stewardship in a larger context of the book’s themes of friendship, intimacy, families, gaming, creative production, and work. In writing this review, I’m liberally quoting from it since the entire book is online. (All the page references in this post are to that book.) I’ve made up this diagram to help bridge between some of the ideas in the two books.

Hanging Out uses “genres of participation” with new media as a way of describing everyday learning and media engagement. The primary distinction that the authors make is between “friendship-driven and interest-driven genres of participation, which correspond to different genres of youth culture, social network structure, and modes of learning.” (p. 15) “Participation” is an alternative to an internalization or consumption perspective. It has the advantage in not assuming that kids are passive, mere audiences to media or educational content. “Hanging out” refers to friendships and social interactions that are oriented to local networks. “Messing around” refers to exploring, playing, cruising around, “finding stuff” – intermediate between the other two categories. “Geeking out” is participation that’s more oriented toward expertise, delving in a particular topic or technology. “Transitioning between hanging out, messing around, and geeking out represents certain trajectories of participation that young people can navigate, where their modes of learning and their social networks and focus begin to shift.” (p. 17)

Megan Finn was the lead author in the section that discusses the “techne-mentor” in depth (on pp. 59-60). A couple long quotes describes the techne-mentor concept:

“In conceptualizing the media and information ecologies in the lives of University of California at Berkeley freshmen, classical adoption and diffusion models (e.g., Rogers [1962; 2003]) proved inadequate. Rather than being characterized by a few individuals who diffuse knowledge to others in a somewhat linear fashion, many students’ pattern of technology adoption signaled situations in which various people were at times influential in different, ever-evolving social networks. The term “techne-mentor” is used to help to describe this pattern of information and knowledge diffusion…. Techne-mentor refers to a role that someone plays in aiding an individual or group with adopting or supporting some aspect of technology use in a specific context, but being a techne-mentor is not a permanent role.

“In the Freshquest study we found many cases of techne-mentors. The kind of roles they played varied from case to case and situation to situation. On one hand, the techne-mentor may simply make someone aware of a technology. On the other hand, he or she may play an integral role in demonstrating the technology practice or even installing the technology and ensuring its status as operational. Sometimes students we interviewed had one primary techne-mentor in their lives, but in turn the students would take on the role when they passed this information on to other groups. In fact, it is this constant flow of information about technology among a student’s multitude of social networks that accounts for the fluidity of the role of techne-mentor. In all these socially situated contexts, techne-mentors were an integral part of informal learning and teaching about technology and technology practices.”

Techne-mentors show up in all the genres of participation but their role is probably more visible at the geeking out end of the spectrum. That is, as technology becomes a more central concern, learning and talking about technology also becomes more central and so does mentoring. It’s really important that the way Hanging Out uses the concept, kids are involved both in being mentored and mentoring others.

A “tech steward” is a specific kind of techne-mentor, working on behalf of a community, mentoring and being mentored in the context of that community. A technology steward is influenced by their social context. In geeky communities such as the Ubuntu community that Andreas Lloyd studied, everyone is concerned with technology in one way or another, although some people are more influential than others. In thinking about the “hanging out” end of the spectrum it occurs to me that the job of technology stewards is partly to make technology disappear. People really want to be hanging out with each other, talking about hawks in Central Park or milking cows in Portugal. The more intuitive and habitual a community’s technology infrastructure becomes, the more authentic and direct the experience of being in the community.

As we wrote Digital Habitats and began focusing on technology stewards who we encountered in different communities, we were struck by the fact that they came from many different backgrounds. That as far as their role was concerned, they were not “trained” in any conventional sense. Looping back to Hanging Out, that makes a lot of sense:

“Sociocultural approaches to learning have recognized that kids gain most of their knowledge and competencies in contexts that do not involve formal instruction. A growing body of ethnographic work documents how learning happens in informal settings, as a side effect of everyday life and social activity, rather than in an explicit instructional agenda.” (p. 21)

That’s a very polite way of saying that school is, in some important respects, irrelevant. It applies to kids as well as to grown-up technology stewards.

“One of the key innovations of situated learning theory was to posit that learning was an act of social participation in communities of practice (Lave and Wenger 1991). By shifting the focus away from the individual and to the broader network of social relationships, situated learning theory suggests that the relationships of knowledge sharing, mentoring, and monitoring within social groups become key sites of analytic interest. In this formulation, people learn in all contexts of activity, not because they are internalizing knowledge, culture, and expertise as isolated individuals, but because they are part of shared cultural systems and are engaged in collective social action.“ (p. 14)

Learning to learn about technology (in particular) from this point of view is a fundamental skill that results from hanging out, messing around, and geeking out. To me this suggests that people who learn about technology in school are cheated because they miss out on some fundamental hanging out experiences. In this sense, the “digital divide” between older people who have been subject to training and younger people who came by their knowledge more socially may be more of a “learning divide.” That makes a lot of classroom instruction about technology irrelevant.

Beware of any technology steward who tells you that they learned how to do it in school.

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.

I’ve been doing a  series of podcast conversations on my Full Circle blog about the use of social media in international development. As I was recording  this week’s with Gauresh Rajadhyaksh, I realized I was talking to a type of technology steward and I should cross post here on the book blog.

Gauresh works with the Development Prospects Group (http://www.worldbank.org/prospects), a central think-tank unit within the World Bank. The unit monitors economic indicators, analyzes developments in real and financial markets and produces World Bank forecasts for the global economy (http://www.worldbank.org/globaloutlook)
Much of the group’s work relies on collaborating with colleagues situated across the world. This collaboration is much more than email exchanges — so they have developed a web-based system: “iSimulate @ World Bank” — http://isimulate.worldbank.org — that allows users to access and execute simulations on some of our simulation models. This is an attempt at leveraging Web 2.0 features to increase collaboration and create a “community of practice” of economists. They have a blog that has some more background information: http://isimulate.worldbank.org/blog. The blog is a great place to start to learn about iSimulate. I’ve also embedded their “how to” YouTube video below.

Gauresh’s role has been in managing this system creation and its strategic planning as a tool for collaboration and communication. He also build some of the actual economic models that have been added to the system.

In the podcast Gauresh talks about how iSimulate was created, adopted and plans for the future. As I reflected after the conversation, Gauresh has been serving as a technology steward for this community of practice of economists in and outside of the Bank, noticing what is needed, developing a prototype that blends with the way people are already working, then takes things to the next level. Take a listen!

Gauresh_Rajadhyaksh_Sept14 (about 18 minutes MP3)

“The opinions expressed in the podcast represent those of the speaker and do not necessarily reflect the view of the World Bank Group, its Board of Directors or the governments they represent.”

Gauresh wrote in advance of our conversation:

We intend to use iSimulate in two ways:
1. Provide an environment for the creation of a global community of practice for economists.

Though we are currently focussing on an internal World Bank community, we hope to use all the “collaboration” features of the system to reach out to a much broader audience. We see this as an avenue to engage in a much more meaningful two-way dialogue with our colleagues and clients.

2. Provide real-time access to data and simulation models.
The iSimulate system is the first-of-its-kind in allowing users to execute “custom simulations” on World Bank models. While most systems provide simple data-access with some visualization features, iSimulate allows a lot of flexibility in experimenting with the assumptions, etc. We see this as a crucial step in increasing transparency and disseminating our work in a more effective manner.

Here is a video tutorial of the iSimulate platform.

Gauresh’s Bio

Gauresh Rajadhyaksha is a Research Analyst with the Development Economics department at the World Bank in Washington, DC. He is primarily involved with macro-economic modeling and manages some of the Bank’s development data systems. Gauresh has been a part of the team that set-up iSimulate @ World Bank and he is currently the Project coordinator / Program Manager for the initiative. Gauresh holds a B.E. in Telecommunications Engineering from the University of Mumbai and a M.S. in Electrical and Computer Engineering from the University of Texas at Austin. He is also currently an MBA candidate at the University of Chicago Booth School of Business.

More podcasts!

I’ll have an additional podcast with Gauresh talking about how he got support for this project within the Bank, a large, fairly traditional organization. That will be part of my next series, “Why Web 2.0?” So stay tuned. The next podcasts in this series will be from Dr. Steve Eskow and Sarah Blackmun on the cultural and gender related aspects to bringing external (web 2) technology to communities in development contexts and Simon Staiger on planning and facilitating online e-consultations. I was hoping to get transcripts of all of these, but ran out of time. So if anyone wants to transcribe….?

Previous & Related Podcasts:

• Social Media in Intl. Dev: Podcast with Bill Anderson on Twitter
• Social Media in International Development Podcast: Bill Anderson

• Simon Hearn on Online Community Facilitation
• Sam Rose on the Social Media Classroom
• Howard Rheingold on the Social Media Classroom
• Blended Facilitation Podcast from Matt Moore (with Ed Mitchell, Matt and I)
• Using “the clock” on telecons

Yesterday I noticed an interesting webinar format that solves one of the persistent boundary and participation problems that I see with this kind of software. Intronetworks held a webinar on “community management as a job.” I was late to the presentation, so when the GoToMeeting screen first came up, the first thing that caught my eye was that Twitter IDs were used to identify the speakers:

Like many such webinars, the audio channel was really the main thing. But I realized that a twitter stream with the hashtag “introchat” was the main visual. There were some slides, but visually the audience was asking questions, making comments, inviting others into the session. In the course of an hour there were almost 500 tweets. Huge audience participation relative to what the sages on the stage were offering.

It felt like the beginning of a community of practice of community managers. At least a drop-in jam session of one.

Two years ago I wrote about the Intronetworks software and was kind of critical about the hard boundaries between “inside” and “outside” their application here and here. (That may be because people want those boundaries, however.) Interesting to see them innovate by using webinar software in such an open way.

(Cross-posted from my blog on LearningAlliances.)

I was cruising through my blog reader, hopelessly “behind” in reading (my own construction – I know I can “mark all read!”) and came upon a post from Vic Desotelle who pointed to a TED talk on Compassion which somehow lead me to a Garr Reynolds post about a TED Talk by Evan Williams of Twitter. (Talk about the network!)

The post had a quote that resonated with my experience as a technology steward to various communities.

Presentation Zen: TED talk: Twitter & the power of the unexpected

You never know how users will end up using your technology. Sometimes they end up using your product in creative ways that you could not possibly have thought of on your own.

As I work with NGOs attempting to roll out intranets and collaboration tools, I preach two things:

• technology is designed for groups, but experienced by individual
• users are creative – use that as a powerful positive force rather than trying to get them to conform with rules and limitations.

These two tenets have significance for technology stewards. It means that they cannot assume that the members of their community will have the same experience they do with any particular tool or platform, and that over time, the community will continue on a predictable trajectory of use of that technology.

It is about a dynamic evolution of practices and applications of the technology, not about the installation or the simple availability of the tool. So here are some practice hints.

• Role model your experience and practices with tools, but don’t present them as the only options.
• Watch for experimentation and amplify new, useful practices. Better yet, encourage community members to talk about and share their practices.
• When members ask for tool adjustments based on their experimentation, work hard to accommodate rather than block innovation. This may mean going to bat with “higher-ups” to gain permission, or to allow the experimentation to fly “under the radar” until you can make a case for the value of the changes.
• Encourage the fringies – the people who push the limits of a tool. Make them allies rather than enemies. Their pushing of your buttons may also create the innovation that you need to foster wider adoption.

What are your suggestions for technology stewardship that involved unexpected uses?

And… you never know where a link will lead you either.

Photo credit: Alex Osterwalder on Flickr

A couple of people have asked me for more materials related to the Community Orientations Spidergram activity. I have embedded them into some slides now up … Digital Habitats Community Orientation Spidergram Activity.

Here is a hint I should have shared earlier. The “context” orientation is a bit odd on the spidergram. You need to decide if internal orientation is in the middle/exterior towards the outside or reversed. I tend to use internal towards the middle, but I realized my instructions weren’t so clear.

Another way to do it is to ignore the “context” spoke from an internal/external perspective and then do one layer on the spidergram around your internally focused activities. Then with a different color, do another layer on externally focused activities. I’ve done this with a few test cases and it quickly showed that some communities which have both internal and external contexts have very different internal and external activities.

My friend Sue Wolff generously lent me two books recently. The first, Marie Winn’s “Red-Tails in Love” captured my heart and mind. It is the story of a community of birdwatchers in Central Park in New York City and how they observed, loved and obsessed over a family of Red-Tailed Hawks that raised a family on an apartment ledge just of Central Park.

If you have ever hankered to read a “real life” story about an organic community of practice, one free from the business pressures of CoPs manufactured inside of corporations, read this book. The narrative is compelling, but the lessons about community life are at once simple, effective and profound.

I thought it might be fun to look at this community, as best an outsider can do (which is usually not very well) from one of the CoP perspectives Etienne Wenger, John Smith and I use in our upcoming book, Digital Habitats: stewarding technology for community. This work builds on what Etienne has been doing for years. In our research of CoPs we noticed 9 general patterns of activities that characterized a community’s orientation. Most had a mix, but some were more prominent in every case. By looking at orientations, we posit, you are in a better position to understand how to support them with tools and processes. They give you a lens to reflect on how your community is doing and where you might want it to be headed.

Here is a brief glimpse of the orientations:

• Meetings – in person or online gatherings with an agenda (i.e. monthly topic calls)
• Projects – interrelated tasks with specific outcomes or products (i.e. Identifying a new practice and refining it.)
• Access to expertise – learning from experienced practitioners (i.e. access to subject matter experts)
• Relationship – getting to know each other (i.e. the annual potluck dinner!)
• Context – private, internally-focused or serving an organization, or the wider world (i.e. what is kept within the community, what is shared with the wider world)
• Community cultivation – Recruiting, orienting and supporting members, growing the community (i.e. who made sure you’re the new person was invited in and met others?)
• Individual participation – enabling members to craft their own experience of the community (i.e. access material when and how you want it.)
• Content – a focus on capturing and publishing what the community learns and knows (i.e. a newsletter, publishing an article, etc.)
• Open ended conversation – conversations that continue to rise and fall over time without a specific goal (i.e. listserv or web forum, Twitter, etc.)

Spidergram examples of the Central Park Birdwatchers - click for larger image

We have been using a little “spidergram” as an assessment tool, again building on Etienne’s work, but each of us has been creative in how we use it. Sometimes it is for looking at technology choices (like in the Digital Habitats book), sometimes for community assessment and planning. So I decided to see what orientations were strong in the Central Park birdwatchers “Regulars” group chronicled in the book. Here is the image I came up with:

Would you like to try the Spidergram activity for your community? You can find a little cheat sheet and template here.

If you try it, I’d be interested to hear what you observed or learned about your community by doing this exercise.

And yes, the book is coming SOON!

So Chapter 5 is getting a quick rewrite to talk more carefully about the togetherness / separation and reification / participation polarities.  We hope the rewrite won’t affect the final publication date, but it’s an example of the complications and risks on the way to press.

Coincidentally, I’m reading a thesis from CPsquare’s research and dissertation fest titled “A system that Works for Me – an anthropological analysis of computer hackers’ shared use and development of the Ubuntu Linux system” by Andreas Lloyd.  He gives a precise and insightful observations of how a community of practice deals with the polarities through their technologies and their relationships at the same time. Referencing the thesis or discussing it is out of scope because that would delay publication!  But Lloyd’s work is a good reminder that seeking to be precise about the polarities in Chapter 5 is really worth the risk of taking extra time. The following extended quote starts on page 55:

The Jargon File describes how the importance of not being interrupted is deeply engrained in hacker etiquette:

… if someone appears at your door, it is perfectly okay to hold up a hand (without turning one’s eyes away from the screen) to avoid being interrupted. One may read, type, and interact with the computer for quite some time before further acknowledging the other’s presence (of course, he or she is reciprocally free to leave without a word). The understanding is that you might be in hack mode with a lot of delicate state in your head, and you dare not swap that context out until you have reached a good point to pause.

I experienced this several times in my visits and interviews with Ubuntu hackers, whose partners and friends over time have come to allow room for and be forgiving of these programming­ related eccentricities. In turn, the hackers themselves often take care to balance their time on the computer in relation to their family’s needs, when they reach one of those “good points to pause.” I have found that this duality is also very characteristic for the way that hackers interact with each other on­line where you can’t assume that people are communicative at any given moment. As Ellen Ullman points out, this inability to be interrupted makes hackers somewhat asynchronous to one another – at least in the short term (Ullman 1995:132). This is reflected clearly by the fact that all of the Ubuntu hackers’ preferred on­line communicative means are textual and thus – at least to some extent – asynchronous. Email, newsgroups and web forums postings and bug tracker comments are all based on users reading and replying asynchronously. Even real time communications such as IRC chat channels and Instant Messaging bend to this rule as developers “ping” each other, and if there’s no immediate response, they can ask their question and let the other answer when he has time or attention to spare:

…
09:00	carlos	pitti: ping
[...]
09:07	pitti	carlos: pong
09:08	carlos	pitti: I did a mistake yesterday night and latest Edgy export has the plural form bug (bug #2322)
09:08	Ubugtu	Malone bug 2322 in rosetta “Truncated plural forms” [Critical,In progress] http://launchpad.net/bugs/2322
09:09	carlos	pitti: I’m exporting a new version with that fixed, but it would take around 23 hours
09:09	carlos	am I late to have it in the prerelease version?
09:09	pitti	carlos: ah, then I’ll rebuild the edgy packs this afternoon
09:09	pitti	carlos: it won’t go into RC anyway
09:09	carlos	ok
09:09	pitti	carlos: the plan is to upload the final packs tomorrow
09:10	pitti	carlos: thus I’d like to have today’s in perfect shape
09:10	carlos	I see
09:10	carlos	ok
09:10	carlos	pitti: I will ping you when the new version is available

Here, Carlos needs to notify Pitti of a new bug which he needs to take into consideration when building a group of packages for upload. Since Pitti is busy, the conversation doesn’t continue until Pitti is able to respond and they can coordinate their work. Most of the Ubuntu hackers’ day-to-day interaction takes place on IRC where they can pick up on interesting discussions and be available if someone needs to ask a question. The hackers deftly navigate back and forth between conversations, fluidly participating as the IRC client automatically notifies them when someone “pings” them or even just mentions their online moniker. And even if they miss something, they can always go back to check the chat logs or mail archives as all interactions within the community are recorded and publically archived online. At times, IRC is such an easy and non-intrusive way of quick communication that it supersedes conversation even when developers are in the same room. Mark Shuttleworth enjoys relating the story of how he went out to buy beer during one of the first gatherings of the core Ubuntu developers at his London flat. When he came back he found 18 hackers sitting in his living room, working in silence, exchanging textual information on IRC. [20] This anecdote illustrates how the work environment provided by the system takes precedence over face-to-face discussions simply to avoid breaking the flow state afforded by the computer. [21]

[20] I saw the same trend again and again at conferences, one time even witnessing two hackers quietly sitting in opposite ends of a conference room, having a furious argument on IRC about who should be responsible for fixing a troublesome piece of software, and it didn’t end until one of them looked up and saw the other hacker sitting at the far end of room and contentiously shouted: “Stop being such an arsehole!”

[21] This asynchronous sociality is not only a norm well suited to hackers’ mode of collaboration, but it is at times also a necessity as the Ubuntu hackers are spread across the multiple time zones, mostly in North America, Europe and Australia, making exchanges such as this common:

15:56	mdz	good evening
15:57	zul	afternoon
15:58	ajmitch	morning
15:58	mdz	good UTEvening

It is easy to forget that the Ubuntu community spans the entire globe, since it mostly becomes an issue when it comes to finding IRC meeting hours that fit all members of the community, and meetings typically rotate between being early morning, late afternoon, or late evening to accommodate as many time zones as possible.

We’re designing the workshop to support:

• Getting to know each other, each other’s communities
• Creating “a workshop as laboratory”
• Exploring real communities, from an insider’s perspective to see community orientations & technology integration
• Considering the role and activity of the technology stewards in authentic situations
• Exploring the uses of social technologies to stay in touch as well as for sustained inquiry
• Experiencing the design of learning agendas and then configuring technology to pursue those agendas
• Articulate strategies to introduce new social technologies to a community

• Communities of practice theory glimpse
• Community technology stewardship
• Tools and their Integration
• Scanning the Technology Landscape
• Orientations: community experience and configuration of tools
• A More Distributed Future
• A Learning Agenda

Connected futures workshop starts April 28: http://www.cpsquare.org/edu/CP2W2/

| View | Upload your own

Apart from the way that Etienne’s classification scheme has been modified slightly to be relevant to the issues on the table, the fact that they’ve gone to the trouble of updating the diagram is a good reminder of how difficult it is to think systematically about all the tools that are out there and how they might work in practice.