Steal these ideas

I spent part of last year building an open-source web application for story sharing and sensemaking in small groups. It's called Rakontu. This was a dream that began in 1999 (when I first started working in organizational and community narrative) and has been growing ever since. I used up years of savings to do it, and I was able to build far less than I would like to build someday, but I had a grand time and I'm glad I did it. I wrapped up the project about a month ago and posted an excerpt from a lessons-learned document for the project.

In my lessons-learned document I said that I'm more interested in the ideas from Rakontu moving on than the actual software surviving as is. Since then a few people have asked me to elaborate on that statement. So I've reviewed and thought, and I've come up with a list of six pieces of advice for anyone who would like to incorporate ideas from Rakontu into their own effort to support online story sharing.

1. Support sharing over performing

One of the biggest challenges in supporting online story sharing today is countering the performance problem. The web has developed into a grand marketplace for self-expression and self-promotion, and people shape their behavior on it accordingly. There is nothing wrong with self-expression, and surely all storytelling contains an element of performance. But I'm interested in supporting the kind of storytelling that leads to conflict resolution, perspective-taking, mutual learning, strong communities, and effective decision making. I call this story sharing to distinguish it from storytelling in which performance is a larger force.

Over about a decade of observing storytelling and story sharing on the web, I've developed a kind of loose metric for story sharing. I look at the comments posted in response to told stories, and I divide the number of comments that express gratitude or support (thanks, helpful, sympathy) by the number of comments that express value ratings (amazing, well put, ridiculous). From this I get a sharing quotient, or how much story sharing is going on relative to performance. The highest sharing quotients I've seen on the web have not been in the "tell us your story" collection sites, or the "I've got a secret" titillation sites, or the "budding novelist" self-expression sites, or the "I just had sushi for lunch" updating sites. They have been in the still, quiet pools where long-term, somewhat coherent social groups meet, and in which people help each other through difficult conditions and decisions.

The interactions in such high-sharing-quotient settings have a few consistent components. They are repeated many hundreds or thousands of times over periods of years as trust gradually accumulates. They are comparatively rich in content and context. And they are goal-oriented. Sites about everything or nothing, or about connecting for no reason except to connect, seem to lead to more story performing and less story sharing. The best story sharing seems to happen, at least on the web, when people know why they are talking.

How did Rakontu support this, and how well did it succeed? To begin with, I was not able to address this issue well enough to find out that much about it. Because of time constraints I had to make an "ugly" version of Rakontu first. It had almost no hover-drag-type interactivity and no support for the near-conversational elements I think would work best, like facilitated storytelling sessions using voice and chat, with story capture and question answering afterward. I was forced to use the standard, boring fill-in-this-form version of storytelling, which was pretty much guaranteed to produce performance from the start. I could find no way around this, and the outcome was predictable: even I, the staunch advocate of natural storytelling, performed most horribly. I found myself perfecting my prose on a daily basis. So any future efforts in this direction should make at least some attempt to get past the fill-in-a-box form of storytelling, in any way possible. Even something as simple as a drop-down box under somebody else's story (rather than a new page) would help make the exchange more conversational. In some ways I wish I had not even tried to use a basic fill-in-your-story form but had gathered stories only from chat sessions and the like. It might have been a better test of the ideas.

My other attempt to keep storytelling natural was to reduce rating by using a utility-based rating system. This failed miserably. The fact that I myself was the greatest failure at this is clear evidence that it could not work, because I was strongly motivated not to succumb to performance storytelling (and knew it when I was doing it). I've now realized that if you set up a rating scale, it doesn't matter what you call it. Your pitiful protests that it is all about utility, not popularity or quality, are simply lost in the massive explosion of instincts you have evoked. People evaluate everything, every minute of every day. It is what keeps us alive, and we can't stop doing it. It doesn't matter what you say about evaluating. It only matters if people can evaluate things and can see the evaluations of others. So, if I was to try this again, I'd keep the evaluation for utility, but I would remove it from view. I'd pull it deep down into the plumbing of the system and place it only in the questions about stories, which provide the same utilitarian mining capability but without the ranking capacity. If you want to use these ideas, my suggestion is to build in utility tagging (through questions) but build out visible ranking and popularity.

Even the Slashdot-like karma system I put into Rakontu didn't work out that well, because it just became another system of ranking. People could see who posted the most stories and comments and so on, and that became another form of evaluation. Don't get me wrong: for some online communities, doing some things, reputation and ranking are essential elements. They work great when people are sharing opinions and building encyclopedias. But for storytelling ratings are damaging because they draw attention to storytellers and storytelling events and away from stories. When attention is drawn too far away from stories, the experiences in them do not accumulate into useful aggregations. In some contexts, like the Olympics, experiences should separate and compete. But making a goal-oriented story sharing site work is more like building an Olympic stadium than using it. Everyone succeeds together or fails together.

2. Build a café in a library or a library in a café

Possibly the most important things I learned by designing, building and using Rakontu are that online story sharing is both a verb (storytelling) and a noun (stories); and that neither matters more than the other; and that they must intermingle for story sharing to work. I picture these as a café where people meet and recall their experiences, and a library where people browse through experiences previously recalled. Any software that supports storytelling needs to support both activities well, and it needs to support frequent and easy transitions between them. I had originally thought of this as a café and a library with lots of doors between them, but then I realized the metaphor was potentially damaging: there should be no wall between them to have doors in. The space should be multiple-use, and the café tables should sit among the library shelves, or vice versa.

In fact, I'll be so bold as to say that any story sharing system in which the telling and the keeping are not intermingled will not succeed. How do I know this? Well.... I guess it's an intuition gathered from years of watching people tell stories in person, in email, on the web, and now (for a short time) in Rakontu. In off-line (formerly called "normal") conversation, people are the cafés and the libraries in which stories live, and stories move fluidly from telling to remembering to retelling. When an old woman remembers a story she heard in 1923 and tells it to her great-grandchild, she doesn't type search terms into a web form or traverse a taxonomy tree. The passage of the story from memory to event is effortless and natural. In the online world, however, the wall between event and memory is high and strong. It's between your starred and recent emails and the rest of your massive "inbox"; between the "latest activity" and other stuff in your Ning group; between the first page of Twitter and the stuff you forgot about last month; between the context and the content of Wikipedia articles. These walls reduce the capacity of the collective narrative machine to churn its content, which is critical to useful story sharing.

I knew about this duality of event and memory before I created Rakontu, and indeed addressing it was part of the design from the beginning. In my 1999 presentation on the topic I included this quote from a 1993 paper by Masinter and Ostrom, which still applies:

The primary technology elements proposed for funding in the development of electronic libraries are in the areas of input (scanning, character recognition), retrieval, and presentation. The entire technology emphasis is on collecting material and making it available to individuals. 

However, a library is more than just a pile of books. Libraries are also social spaces. Treating the 'electronic library of the future' as an information repository ignores many of the roles played by current institutions, where library users interact with their friends, colleagues, and professionals to [find] material that is relevant for them.

A story sharing site cannot be just a pile of stories, but that is what I see happening on most sites that say they are for story sharing. What I see on the internet is either stories entirely absorbed in events and never transferred to memory, or stories stacked up in memory and never returned to the world of events. This is one of the central ideas of Rakontu and should be stolen as widely as possible.

One of the ways I tried to support intermingled event and memory in Rakontu was in my creation of roles as packages of commitment. I stole the idea from a 1996 paper by Richard Bartle, and it's still so interesting I'll repeat it here. The paper was about what people do in multi-user dungeons (MUDs), and it posits this framework to explain motivations:

(from Bartle 1996)

The vertical dimension compares acting on things or people (that is, changing things) and interacting with things or people (without changing them). The horizontal dimension compares social with environmental focus. When I first encountered this diagram in 1999, I got very excited about how it related to the roles people might take on in a storytelling environment. MUDs and story sharing sites have much in common, because people are both building something and living in it at the same time. (It also reminds me of my favorite quote from Stephen Crites that people live with mundane stories and in sacred stories.) So Bartle's framework has unique applicability for this purpose.

The roles I designed for Rakontu (curator, guide, liaison, manager) deliberately populate Bartle's spaces. Managers are the achievers of the Rakontu world, configuring the story sharing environment and shaping the story exchange. Curators are the explorers of Rakontu, mining the collection for stories, finding patterns, fixing tags, keeping the museum in order. Guides are the socializers of Rakontu, answering questions, helping people get started, leading tours. Liaisons are the - well, let's call them the social achievers - in Rakontu, bridging the most difficult divides between online and physical worlds and running storytelling and sensemaking sessions.

Even though I was the only one who really used the roles in the beta testing of Rakontu, I did feel that they matched the activities I carried out while using it, the hats I put on, if you will. They helped me set a frame for whatever I was doing in the system as I approached it each time, whether it was cleaning up tags, answering questions, adding collected stories in batches, or asking people to tell stories. So I think this is an idea worth keeping and using.

This trial of supporting the event-memory duality has an impact on technological options for continuing work on Rakontu. One of my strongest technology lessons learned was that I spent way too much time reinventing wheels related to social media. I had to implement many things that already exist in many web platforms, such as groups, permissions, private messaging, notification, management control, removing offensive material and spam, and so on ad nauseum. So one possibility in doing more with these ideas is to start with a platform that already supports much of what is required for social media. However, that is only the café part of the equation. Few social media solutions give much support to library functions. For that you need semantic indexing, taxonomy and/or folksonomy, simple and advanced search, typed linking, and all the other things that make a library work. I have yet to find any system I can build upon that combines the café and the library in equal proportions. Everything I see favors one strongly over the other. Wiki and other collaborative creation software favor the library, and discussion and social media software favor the café. In any system you choose as a foundation you will most likely need to reinvent some of the wheels of the other system. My advice is to think about your strengths: what do you know well how to build? If a café is something you can build in your sleep, look around for pre-built library components. If your experience is in library building, see what you can find to complement it in café packages. I'm better at library building myself, which is probably why the café building parts were onerous for me.

3. Embody knowledge about narrative

One of my most important discoveries about storytelling is that people vary in whether they think they tell stories and are good at telling stories. (That discovery was the subject of this post a while back.) Another dimension to the variation is whether people understand why people telling each other stories matters, and how to do that. The thing I learned before I started Rakontu was not to try to explain any of that, or at least not to make explanations into barriers. Systems that force people to understand something before they can enter them are empty places. The better solution is to shape the experience itself so that it embodies knowledge about stories and storytelling rather than trying to spread it.

Probably the best successes of Rakontu so far have been in this area. For example, one thing that seemed to work well was the system of typed, annotated links between stories. In Rakontu, when someone sees a topic, they can respond to it with a story, and that link, and their annotated reason for it, is kept and can be reviewed and searched. When someone reads a story, they can tell another version of the events it recounts, tell another story it reminds them of, or explicitly link it to another story for any (annotated) reason. As we built a base of stories using Rakontu, I found these links an essential tool for "getting around" in the library we were building. I often found myself clicking through the web of connections among stories to follow a sort of thought-path around. I can see how this sort of web-building could be much more powerful as the story collection grows and its interlinkings intensify.

By the way, I got this web-building idea from Roger Schank's work on case-based expert knowledge databases. More specifically, I got it from this interesting essay by Jorn Barger, who worked on Schank's team and revealed in it more about how these story databases were constructed. When I read this sentence back in 1999:

All the links from story to story in the Ask-Tom casebase had to be 'hand-crafted' or hardwired, which ultimately meant looking at every possible pair of clips and asking whether either would make an interesting followup to the other, and which of the eight CAC-links it made most sense under.

I realized that the human creation of such typed links (which the AI researchers working on expert systems found an onerous task and seemed embarrassed to admit was being done by clerical help) was a perfect sensemaking activity for people telling each other stories. Building a web of typed, annotated links helps people understand their stories as they tell them, and it creates something they can use later to explore the same issues when they have a need for them. That idea is a definite "keeper" out of what makes up Rakontu as it stands today.

Another keeper in terms of embodying knowledge is Rakontu's question-asking system. That part also worked out very well. When anyone tells a story in Rakontu, and when anyone reads a story, they are presented with several questions that capture their interpretation of the story. For example:

• How do you feel about this story?
• Why was it told?
• To whom did this story happen?
• How long will you remember this story?

Some stories will only collect one set of answers, but controversial stories are likely to collect many sets that represent varied interpretations. This question-answering mechanism has several benefits to the group using Rakontu. It gives people a way to voice their opinions about stories that can accumulate into useful patterns. Thus offending stories do not require a power structure to remove (though Rakontu has one anyway) because they can be dragged down by the power of collective voice. The reason I wanted this was because in natural storytelling, offensive stories can never be "deleted" from the community; they are just weighed down with so many annotations that they sink into oblivion. If anyone attempts to dredge up the offensive story again, it is immediately attacked with more attachments and sinks again. This is a closer analogue to what should and does happen to damaging stories "in the wild," and I think it's effective. I have no proof of this, of course, as there were only a few of us answering questions in the tests of Rakontu so far. However, even in that tiny test, I did notice differences in answers between storytellers and story readers in ways that would be instructive if they accumulated further.

One important component of the question-asking system, and this may be special to questions about stories, is that it has to be flexible. Many systems are available to attach metadata to collected items; but rarely can you change indexing schemes attached to live data. In Rakontu such after-the-fact redesigning turned out to be critical. When a group is forming, they can only guess at what questions will best serve their needs. Even in the small tests I did, I found myself mucking about with the questions often as the story collection began to form and newly obvious questions and answers emerged. Supporting flexible questioning means that it must be possible to modify existing answers - very carefully - to match a new indexing scheme. For example, if you find that people rarely choose the how-do-you-feel answer "stymied" but often choose "frustrated", you might decide that "stymied" is close enough and would make searching easier, so you may want to lump together the two answers. Or you might find that nobody ever picks "thwarted" and you have too many answers and just want to remove it. It also requires mechanisms for reviewing large numbers of answers and looking for gaps where metadata is scarce. This takes work, both on the part of the system builders and on the part of those maintaining the story museum. But it's worth it. I'd say that the ability to keep your questions relevant and useful as your storytellers and understanding and goals change is a requirement for a useful living story museum.

You might say that such flexible organization can be accomplished through tagging. Somewhat, and in fact I loved the tagging aspect in Rakontu and used it often. But tagging narrows the source of interpretation and reduces the utility of the story collection to support multi-perspective sensemaking. Few people (mostly curators) have the time and attention and willingness to tag stories. It's a nerd thing. Tags are tasks, but questions are conversations. Questions bring everyone in and increase the diversity of response and thus the strength of the story collection.

One thing I think Rakontu needs much more work on is diverse visualization of the collected stories and other data. The timeline view of stories I used as Rakontu's main interface was adequate for the café (though it had its problems, mainly related to point number one above). But as soon as we got up over a few dozen stories I found myself wanting to see many other views of the data: link maps, bar charts, tables, sorted lists, and so on. Granted, if I had been able to make the fancy high-mouse-interaction interface I had mocked up, some of these things would have been included. But still, I found that I wanted lots of ways to stroll around in the stories when I needed different things. So that is an area that would, I think, reward exploration.

But having said all that, and even though Rakontu strongly featured widget-based question answering and other methods of tagging and so on, I'm not sure it needs to be as idiot-proof as all this. Do you know those emails you get from friends where you get a page of questions about yourself, and you are supposed to insert your own answers? Those are essentially semantic indexing sheets. I've been amazed by how few mistakes people make in doing this. Even people whose eyes glaze over when you try to explain flexible semantic indexing can paste their answers over Uncle Joe's and send the thing round. It's possible that a motivated group could run an entire Rakontu-like story sharing system through email or in a discussion group. All it needs is somebody putting some time into pulling apart messages with hand-filled templates in them. It would be a pain, but it wouldn't require any special software at all. For example, say you send out an email to your group that says "does anybody remember eating at that old restaurant on the corner, you know, the one that burned down last year?". And then when people tell stories about it, they remember to take the list of five questions and paste them in at the end along with their answers. Then some long-suffering secretary of the group takes all the stories and answers and puts them into a spreadsheet, and at the next meeting of the historical society everybody looks at the bar charts they printed out. Or everybody takes the printed stories-and-answers and puts them into little piles, which is the same thing.

What I'm trying to say is that you don't need fancy software to do useful things with information, and you don't have to wait until you get the fancy software (or the creator of the fancy software gets a big grant) to do what you want to do. Fancy software helps, but you can do the same things with fingers and paper, and I think people might be starting to forget that. (If you don't believe me, look at old records from a church or factory or port. We had complicated metadata long before we had computers.) Computers are useful for managing metadata, but they are still the smaller part of the equation. The important thing in supporting storytelling is to keep the connective tissue of story sharing intact. When we speak through computers, our conversations get broken up and put into little boxes, and the connective tissues don't get laid down as they should. Story sharing, and especially the interplay between event and memory, depends on connection far more than other conversation does. You can maintain connective tissue using fancy software, but you can maintain it using norms and practices too. In fact, the best fancy software doesn't supplant human norms and practices; it gets its power from them. The great advance that is Google came from a realization that the way people link up their web sites - by hand - is a resource that can power fancy software. You can do that with stories too.

4. Build for commitment

In the 1999 presentation that held the idea that eventually became Rakontu, I said that "stories thrive in groups of people in frequent and persistent contact in a shared culture." I of course know that stories also live in other environments, like in vast marketplaces where people choose products and services, and in the shifting sands of coalition building in discussion and debate. What I probably should have said was "the types of stories I am most interested in supporting thrive in groups of people in frequent and persistent contact in a shared culture." I'm still interested in supporting the same types of stories, and I still think they live in the places where small groups of people come together often. That is why I built Rakontu for small groups of people who already know each other, at least a little. It's where the gear-turning stories, the change-making stories, the life-improving stories, thrive.

The tests of Rakontu bore this out. It worked best when it was being used by people who knew each other. With strangers such things as responding to one story with another story, interpreting the stories told by others, and looking at patterns in stories together ... didn't happen as much, or they happened in a high-school-dance way in which most of the people watched as a few people started to dance. Of course, this same thing happens on all discussion groups, which may form for months before the really interesting conversations take place. But with something created for the express purpose of storytelling, the most fruitful interactions might have to be put on hold until the necessary trust is established. I'm starting to think that a dedicated story sharing site like Rakontu can't work unless one of two things happen: the Rakontu is "seeded" with stories gathered from conversation or a special in-person or chat story session, or the Rakontu is used for an existing group who can jump into the commitment-requiring elements without hesitation. Even in the latter case it may be necessary to supplement lower-intensity fill-in-the-form story collection with higher-intensity conversational elements periodically.

I've seen many story collecting web sites go up in which complete strangers post stories, and I've never seen one of these succeed - in the ways I would like to see story sharing succeed. They do sometimes succeed in the sense that people looking for information find what they need. I myself have received much needed help reading stories of medical conditions and life challenges. But for working towards a common goal that will benefit everyone in a group, this sort of story collection lacks the connective tissue to build something larger. In general I think web software has been wonderful for people finding and meeting people. It has been wonderful for people trying to draw more people to a cause. It has done a dismal job helping people who already know each other do anything but bring the most basic information together. In my opinion, Margaret Mead's small groups of thoughtful, committed citizens trying to change the world are still waiting for their internet. If there is one thing I think could not be stripped away from Rakontu without ruining it, it would be its emphasis on helping small groups achieve common goals. Because it's unique, because it's needed, and because it's what stories do best.

The other side of building for commitment is to keep it centered on continuity. Since I built Rakontu several people have approached me wanting to use it for one-time story collection. This would be a legitimate use of any such software, and with a few tweaks Rakontu could easily become a story-oriented SurveyMonkey. But I'm not excited about that possibility and have sent people off to other solutions for one-time collection. Why? Well, first, because SurveyMonkey and a whole raft of other surveying systems are already out there, and they work fine for story elicitation. And second, if Rakontu, or something based on it, did survive and get used and get popular, the last thing I would want is for people to think, rightly or wrongly, that it was just a data collection device. The whole point of the work is to build story habitats, not story zoos or story cages. If it gets away from that, it's not the same work at all.

5. Decomplexify

I'm a nerd. I make things too detailed, too confusing. I write in a nerdy way, and I write nerdy software. I obsess over things some people don't even notice. If I was to ever work on Rakontu again, I'd hire some non-nerds to help me suck some of the nerdiness out of it. Even after a few weeks have gone by and I look at the Rakontu interface I've forgotten what some of the cryptic things mean. It needs better hiding of complexity for new users, and it needs much more eye candy. I used to think eye candy was just that, but I've come round to the position that at least some eye candy would be better named "learning curve smoothing devices." When icons are big and memorable, that's one less bump going up the curve, because you don't say "what the heck is that thing" after a week has gone by. When the available choices aren't always staring at you but appear only when you click on a Javascript arrow, that's one less bump going up the curve, because you aren't confronted with their complexity all the time. When you grab a Google map and it does what it would do if you grabbed a real map, and you didn't have to find the button marked "Shift 20 degrees to South" instead, that's one less bump going up the curve.

I skimped on eye candy and interactivity in Rakontu, and I believed I did it out of necessity. But after some reflection I wonder if I did it partly out of comfort with nerdy detail. And I wonder if I should have built something less powerful and easier to use. The functionality versus ease of use dilemma is always difficult, but it's useful to know yourself and know when you need somebody else to balance your natural proclivities. If you steal these ideas and you're a nerd too, watch out for over-nerdifying what you do (yes, this could happen to you). If you steal these ideas and you're not a nerd, do try to wade through the detail and find the good stuff mixed in. It's all in there, really.

6. Pay no attention to that man behind the curtain

My original vision for Rakontu was not just a web site where people would tell and store stories, like a Ning with stories in it. It was a suite of tools and educational aids people would use to support story sharing and sensemaking in both asynchronous and synchronous, on-line and physical sessions. In a way I regret using the little funding I had to build a form-based web application, because that is the weaker part of the vision, and I don't want people to think that is what Rakontu was supposed to be. I've come round to the view that my time might have been better spent writing small modular tools to support the interplay between event and memory.

For example, I could have written software that would help people take a thousand messages from an online forum, find the stories in them, collect answers about the stories (from their tellers and from others), and present the information back to the forum organizer in spreadsheet form so that they could report trends to the group and call up stories pertinent to future needs. Or, I could have written software that helped people take told stories and use them with sensemaking frameworks to come to new understandings about issues of concern. Or I could have written software that helped people copy stories found on the web (including in forums they participate in) to a personal storybase, with annotations and connections, and share that storybase with others in their group. Or I could have written an email add-on that highlighted stories in emails and popped up a "keep this story?" window with questions to answer. And so on.

The possibilities for supporting story sharing do not begin and end with creating story repositories and ways to fill them. There are many nooks and crannies where related tools could fit in the spaces between the ways we talk, online and offline, today. To anyone who is interested in pursuing these ideas, I'd suggest finding some of those. The point is, if you want to steal these ideas, which I hope lots of people do, don't look that hard at what I actually built. If you do look at it, look as carefully at my mistakes and regrets as you do at its architecture. And look at the ideas. Read the things I've written about why I wanted to build Rakontu, what gaps I'm trying to fill, what could go wrong, and what I'd like storytelling on the web to be like someday. These are the things worth stealing.

One more thing: if you'd like an accomplice in stealing these ideas, send me a note. I'll be your man on the inside.

What stories are for

Here is the state of things at the moment. The first in a series of blog posts on "limiting misconceptions about complexity in organizations and communities" has begun to peek out and explore its surroundings, but I don't have the time this week to help it get on its feet. Several smaller, weaker siblings, some with narrative stripes, some with complexity spots and some with both, tremble behind it waiting for attention. For now they must gather strength in the safety of the cave. So last night I was thinking about this feeble family while checking the news, and I fell onto something that will fill in the gap quickly. (The cave dwellers alternately rage and weep but have been thrown promises to eat.)

What I fell on last night was an article in New Scientist about Tomas Rokicki and "his team" having solved the problem of how many moves it would take to solve Rubik's cube from every possible starting arrangement. This number of moves is called God's number (or God's algorithm) because if God was to solve the cube he/she/it would do it as efficiently as possible. (My feeling is that God's number would be zero, or maybe a glance, but it's a fun name anyway.) This number has been long sought after by mathematicians with ever better algorithms and ever faster computers. What this group of people did was to finally and conclusively prove God's number to be exactly twenty.

(By the way, I hate it when people say "so-and-so and his team" so here is the full list of participants, from cube20.org:

Our group consists of Morley Davidson, a mathematician from Kent State University, John Dethridge, an engineer at Google in Mountain View, Herbert Kociemba, math teacher from Darmstadt, Germany, and Tomas Rokicki, a programmer from Palo Alto, California.

Note the alphabetical order.)

The interesting connection to narrative is in this part of the New Scientist article:

Previous methods solved around 4000 cubes per second by attempting a set of starting moves, then determining if the resulting position is closer to the solution. If not, the algorithm throws those moves away and starts again.

Rokicki's key insight was to realise that these dead-end moves are actually solutions to a different starting position, which led him to an algorithm that could try out one billion cubes per second.

A series of moves that was a mistake for one configuration was a solution for another, and the mathematicians stored the mistake for later use. They used stories to transfer knowledge, in the simplest way possible. (What an ingenious solution.)

The reason I got very excited when I read this was because I once worked in the world of simulation and animal behavior, and when I started working in organizational story I had in mind (but never found the time to create) a simulation exploring what I called "minimally storytelling agents." I wanted to find out what you would have to create in both the environment and the makeup of artificial life elements in order for them to start telling each other minimal this-happened stories. Of course, they would have to do it without you programming it into them, so the puzzle would be what would get them started, minimally, on that course. My intuitions about what might be required for storytelling in simple agents have always been mainly interaction (my fitness depends in part on your behavior) and iteration (we interact repeatedly). But I've always thought there must be something else, something about the nature of the environment, that must be in there as well. Something worth telling stories about.

It's one of those projects I'd still like to do when I get time. Has anybody else beat me to it? Maybe, I'm not sure. (Tell me if you've seen anything like it.) On a quick look I see that Kerstin Dautenhahn and Steven J. Coles published a 2001 paper in the Journal of Artificial Societies and Social Simulation describing a simulation in which simulated robots were given minimally self-storytelling behavior and were found to derive fitness benefits from it in some environments. But as far as I know nobody has yet watched storytelling "evolve" so maybe I'll still tackle it when I get a free block of time.

At any rate these connections may be useful to people thinking about what stories are for, especially those looking at narrative from the perspective of evolutionary psychology. I have been enjoying Brian Boyd's book On the Origin of Stories, and this whole thing fits right into his ideas about why people tell stories at the most elemental level, especially what he writes about play.

Another relevant link is to an article I saw a few months ago on sciencedaily.com about memory and stories. It describes experiments done by a group of researchers in which they placed electrode "hats" on rats as they ran around in mazes to watch them telling stories to themselves.

Says the article:

The hippocampus, a part of the brain essential for memory, has long been known to "replay" recently experienced events. Previously, replay was believed to be a simple process of reviewing recent experiences in order to help consolidate them into long-term memory. 

Replay meaning storytelling, if internal. So, by watching the firing patterns in the brains of these rats, the researchers were able to find out not only where the rat was located but also what locations the rat was thinking about as they ran about (or didn't). The presence of "cognitive maps" in the brain, in which "place cells" describe the animal's current location, have been researched for a few decades already. But this is the first time I've seen it linked to storytelling (not that I'm up on the neurological cutting edge so I may just be ill-informed). Here was the bit I found most interesting:

[The researchers] found that it was not the more recent experiences that were played back in the hippocampus, but instead, the animals were most frequently playing back the experiences they had encountered the least. They also discovered that some of the sequences played out by the animal were ones they had never before experienced.

This reminds me of Gary Klein's work (described in Sources of Power) on naturalistic decision making: that people make decisions by recalling cases from the past. However, as I recall it, Klein's firefighters did not recall (replay) their great masses of mundane experience; they compared what they were sensing mainly to the extremes. My strongest memory from Klein's book is of a firefighter entering a room, feeling a hot floor, remembering a time when a floor gave way because there was fire beneath it, and ordering everyone out just before the floor collapsed. Now I don't believe naturalistic decision making replaces the rational, normative model; I think they coexist and commingle. But still, these things connect. People tell stories (to themselves and others) -- in part -- to explore the areas of their worlds that hold more danger, because it is only there that it is worth the time and trouble. Stories about rules are valuable, but stories about exceptions to rules are either equally or more valuable.

This also links to the Dautenhahn and Coles paper I mentioned above. The environment in which self-storytelling produced an adaptive advantage was the more variable one:

We can speculate that minimal mechanisms in the "first story-telling animal" survived because the animal was better adapted to a dynamic environment, story-telling increased its survival chances.

So, when the environment included broader extremes between safe and dangerous territories, storytelling conferred a greater advantage. Which links to the rat-place-cells finding and Klein's work.

In practice, what does this all mean to people working with stories in organizations and communities? Well, first, it gives credence to the view that stories of best practice are not as useful as stories of worst practice. However, it balances that by pointing out that when positive stories are "encountered the least" -- exceptional -- they hold special value. This also connects to Stephen Crites' wonderful distinction (in his excellent chapter "The Narrative Quality of Experience" in Memory, Identity, Community) between sacred and mundane stories. My favorite quote on this (and I think I've quoted this before) is:

Such [sacred] stories, and the symbolic worlds they project, are not like monuments that men behold, but like dwelling places. People live in them....[They] inform people's sense of the story of which their own lives are a part, of the moving course of their own action and experience.

People live in sacred stories, while they live with mundane stories. If stories map our worlds, those at the outer edges are the ones we can least afford to lose. (The outer edges of what is a valid question for another time.)

The other gem this series of linked observations contains, to me at least, is that if anyone doubts the value of storytelling for knowledge transfer, we can go back to the very basics of cognitive function and problem solving to provide examples of utility. That's useful all by itself.

What to expect when you're expecting stories

After the detour into sensemaking represented by the last few posts, while still "growing" a few posts on complexity and all that business, I'm ready to get back to seriously finishing the rewrite of Working with Stories. (If you didn't know this, reader, much of what's up on this blog, under the Practice and Observations topics mainly, is going to end up in the third edition of WWS.)

There are four remaining gaps to close in WWS, based on what people have told me:

1. People need more details on the practicalities of collecting stories in various settings, such as what to do when obstacles arise.
2. The exercises (for story gathering and sensemaking) need more meat to them so people can get started using them more easily.
3. The book needs a better "what's this all about" section that communicates the value of the approach (including why it differs from and complements other approaches).
4. I need to interject more real stories of real projects. This can be difficult due to client confidentiality, but I will try to fit more (strongly anonymized or fictionalized stories) in here and there where they make a good point. That will mostly happen off the blog, however. (I also have two more case studies coming from colleagues, and by the way folks the old case study offer - four free hours of consulting for your case study and permission to publish it - is still in effect.)

I'm also planning to do a book-wide jargon-reduction operation in order to reduce barriers further (so for example generation versus integration becomes story gathering versus sensemaking). I'm going to have to introduce a new piece of jargon for the title (Participative Narrative Inquiry, as I mentioned a while ago), because "Working with Stories" is just not a clear enough communication of the intent.

Writing about collecting stories

So I've been going back and forth on what is the best way to write about gathering stories. I thought about writing "vignettes" or combined stories of all the things I've done and seen other people do, and how they turned out; but that didn't seem right, and I was afraid I'd inadvertently embarrass or offend people. I thought of answering questions in the manner of a frequently-asked-questions list; but I don't know, when the questions aren't real those always seem pathetic.

Then I thought of What to Expect When You're Expecting, which for those who don't know is an essential book on pregnancy. What I liked about that book when I had occasion to use it was that it listed lots of things that could happen and what you should do if they do happen. I liked that a lot. I like to prepare for the worst when I'm facing the unknown.

It's interesting, though. I looked up WTEWYE, just for fun, and found some pretty strong negative reviews about it on Amazon. Those comments read like perfect cautionary tales for anything I might write (yes again I'm looking to prepare for the worst). This review was a good example:

To make a long story short, after getting about 120 pages into this book, I called my best friend nearly in tears. I told her I was reading the book, and before I could go into details, she said "oh for goodness sakes, don't read THAT! It's all about what you can't do and what can go wrong."

But others disagreed:

Honestly, I have no idea what all those people mean when they say that the tone of the book is condenscending and that the book is designed to scare you by pointing out everything that can go wrong... This is just not true!

What I think it comes down to is that some people are like me and like to hear about all the awful things that could happen in advance, so that if those things do happen they can say, "Ah, I know what to do." But other people find preparing for disaster puts the whole thing in too negative a light and drains their energy.

Another reader said:

Clear and easy to understand, I felt the authors did not speak down to the reader, rather reassured me that none of my concerns are silly. They had a great way of keeping me CALM (as I am a fact seeker, and often read a little TOO much and scare myself!).

Yep, that's exactly what I do. I'm a fact seeker too. But it's important in writing this book of advice (not about pregnancy, thankfully) to keep both ends of this range in mind, as well as the middle.

The great thing about gathering stories, which like being pregnant is an augmenting process, is that people tell and listen to stories all the time. We already know how to do this, just like women already know how to have babies. For that reason being pleasantly surprised by what happens when you are gathering stories is just as likely as its opposite. So I think my plan will be to think of situations I've seen happen, but to try and come up with as many pleasant as unpleasant surprises, and to talk about the dangers and opportunities in every situation.

So, I thought I'd start by coming up with some situations that arise in group storytelling sessions. I started by looking back over old notes from sessions I've run or observed (luckily I'm a great note-taker). I'm already up to fifty situations and still have lots more notes to review, so this is going to take longer than I expected and won't make it into this week's blog post.

Instead, as I was looking back through old notes I found a batch of notes-to-myself on how people respond to being asked to tell stories in groups. It seems helpful so I've cleaned it up for general consumption.

Interaction styles in story gathering workshops

These are some styles of interaction I've seen in story gathering workshops, or ways people respond when asked to tell stories in a group setting. I give the styles character names as though they were whole people, but really they are simplistic caricatures that describe motivations. Any real person would be a mix of these, and the same people might react in different ways in different contexts or when confronted by different behaviors of those around them.

Busy people don't have time to tell stories. They won't listen to a long introduction, won't participate in any exercises and won't read anything. They constantly remind you that you are wasting their valuable time and are the most likely to walk out of the session. To get busy people to contribute, show them what they will get out of helping you by telling stories. Maybe they'll have an easier time doing something, or people will stop bothering them with questions, or an issue they care about will be improved. Busy people want to believe their time is not being wasted, and they need to be sure of a return on investment for every minute they spend with you. Show them how their time is being used effectively.

Backgrounders know enough about the issue to be good resources, but they don't want to participate. They might not trust you, or they might not want to talk in front of particular people, or they might consider the topic too private. They try to fade into the background and get through the session without saying anything, and are close to the busy people in their likelihood to drift out of the room and disappear. To get backgrounders to contribute, make your privacy policy expressly clear, and communicate your need to hear a diverse range of experiences. Explain how you will use the resulting stories and connect to goals the backgrounders might have. Ask for their help; reassure them; get them on your side; rouse them to action. If you can't get them to talk, ask if they might be willing to talk in another venue. Having an online story collection or private, anonymous interview opportunity after the workshop is over sometimes helps to give backgrounders a way to contribute in a safer way.

Gurus know so very much about the issues you are exploring that they feel threatened by the session. They might feel it decreases their store of knowledge or spreads it around too much, or they might feel you are trying to get something out of them for nothing. But while gurus feel threatened, they are also drawn to the session since the issues it explores are things they feel they have authority over. Their stories are prepared and purposeful, with strong hints that they know a lot more than they could possibly tell. They might view stories about mistakes or feelings to be trivial and inferior to what they have to offer, so they might inhibit others from talking. To get gurus to contribute and tell useful stories, and to give others room to talk, make it clear that your purpose is not to capture what they (alone) know but to understand the experiences of people of all levels of understanding and skill in the subject. Gurus need to know that their knowledge asset will be respected. Show them that you are not after what they are guarding, and that what you need is something they can share freely without losing anything.

Questioners have heard that people are going to be exchanging experiences in the session, and they want to use the session to learn from others, perhaps even to gather some secrets that only the gurus and busy people (those in authority) know. So they ask a lot of questions. I've seen people find the most knowledgeable or highest-status person they can and grill them about the subject, essentially ignoring your goals. Questioners don't tell stories, and they prevent other people from telling stories as well, since they are looking for facts and advice, not unimportant ramblings about mistakes and feelings. If questioners and gurus get together it can ruin storytelling, because questioners can lead gurus easily into lecturing. (This is less true for busy people, because they don't have time for questioners and send them to other sources of information.) To get questioners to tell stories and leave the gurus alone, remind them that your goal is to learn about diverse experiences, including theirs, and that they can ask direct questions at another time. If your topic is one you think people will come wanting to learn about, have some resources on hand that questioners will find valuable. By giving questioners valuable answers you can meet their goals first, and then ask them to help with yours.

Old hands know a lot about the issues, but they aren't in a position to guard or value that knowledge. They understand what you are doing and are usually happy to help, and they actively come up with useful stories. However, old hands tend to step aside when the gurus start to talk, because they have no interest in what the gurus want. Questioners don't ask old hands questions because they don't publicize or prepare their knowledge. So even though the old hands know a lot about the issues, they may be the least likely to tell the useful stories they have to tell. To get old hands to contribute, make room to let them talk. But do it without disparaging your gurus (who will outshout the old hands) or drawing the attention of your questioners (who will grill them). The best way to give old hands room to talk safely is to make sure everyone has room to talk; that way you are not seen as privileging anyone. Also, if you can quietly identify the old hands to yourself, see if you can follow up with them to gather more stories outside the workshop, for example in interviews.

Venters come to the workshop with a list of problems or messages fixed in their minds that they have a great need to deliver. They might know about your goals, but they are more concerned with their own. Venters pour out energy about the issues they are upset about, but they often aren't interested in telling stories because it seems like a less direct and effective way of voicing their concerns. Venters sometimes buttonhole the busy people or gurus in the workshop because they think (rightly or wrongly) that those are the people in charge, so those people must be brought to listen to their complaints. To venters, collecting stories might seem a polite way of avoiding the issue, which they will not tolerate. To get venters to tell stories, convince them that you do want to understand their perspectives and feelings, and that in fact is exactly why you are asking them to tell stories. Venters want to believe they can have an impact. Show them how they can do that by telling stories. If you expect a lot of venters in your workshop, come prepared with a special complaint line or other method by which venters can speak their piece outside of the workshop. This will help them reach their goal so they can turn their attention to helping you reach yours.

Over-compliers. These people might know some valuable things, but they want to help too much and try too hard. They do exactly what you tell them, and they are worried about following the instructions perfectly. If you slip up and say the story should involve three people, all of their stories will involve exactly three people. Over-compliers don't bring out very much of their real experiences, because they don't think you could actually want the boring facts of their humdrum existences. Their stories are even more purposeful and distorted than those of the gurus, because they see the session as a test they are desperately trying to pass. To get over-compliers to contribute, help them understand that you really do want to know about the mundane details of their lives. Explain that what you want is just what everyone does naturally and that there is no need to perform; just talk about things that have happened. They want to do the session right. Show them how so they can.

All of these styles can tell great stories, and a storytelling session can mix them all together and still succeed. They are not pathologies of storytelling as much as markers on the landscape: knowing how to recognize them puts you in better control of getting where you want to go. They can help you detect signs of danger and opportunity and react to them quickly to nip a problem in the bud or capitalize on a potential.

This graph shows where the styles fall on two dimensions: how much people know about the issue you are exploring and how eager they are to tell you things about it (though not necessarily useful stories).

This graph shows the same thing, but with interactions between the styles overlaid. Note that the old hands and backgrounders are in danger of falling out of the conversation and need to be kept in. Questioners, venters and over-compliers (those where the arrows start) are the most likely to set off less-productive patterns, so those tendencies are likely to need the most attention to guide the conversation towards the sharing of raw stories of experience.

So, hopefully that's helpful to some people planning to gather stories in groups. Look for more practical advice in these areas in the weeks (hopefully not months) to come. Please do comment if you would like to point out gaps, mistakes, unseen opportunities, arrogant blasphemy or transcendent wisdom!