Rakontu lessons learned

Well, I've finally done it. I've wrapped up the Rakontu project, updated the web site, closed down the beta sites, and written a lessons-learned document.

Rakontu is the free, open source software I wrote last year to help small groups share and work with their stories online. I finished version one of Rakontu in the fall of 2009. There were five beta test groups, but only one of them got to the point of having much content (mainly due to the people managing the other groups being too busy to use it or not finding it fit their purposes as well as they had expected). The group that did gather content was a spin-off from John Caddell's Mistake Bank on Ning. We had 40 members and collected about 45 stories, though most of these were from John and myself going back and forth. That story exchange turned out to be most of the beta testing Rakontu had, but it was surprisingly helpful.

Rakontu has been a labor of love, and at the moment I'm all out of love, so it's on hiatus until more funding comes along, or I make a fantastic amount of money doing other things and can fund it myself. The software is still available, and it works, and I may be able to come back to it eventually, but at the moment it's having a rest.

I thought I'd post a few excerpts from the lessons learned document here. The full document is available on the theory page at rakontu.org (scroll to the bottom) and contains more about the history of the project, the beta testing, and some technology-related lessons. There are also a few other white papers on the theory page on why I built Rakontu and why I think things like it are needed.

The social aspects of Rakontu - what worked

I loved the exchange that got going between myself and John Caddell on the Mistake Bank Rakontu. For a few months we were trading a few stories a week. We were reminding each other of experiences, and making comments, and using the system in the way it should be used. In a way, the interaction between the two of us, over that short time, was the only real test of Rakontu. Rakontu is not meant to work for groups of people who don't know each other already. John and I knew each other, but I didn't know any of the other people in the Rakontu, and those exchanges were awkward. Not because it was anyone's fault, but because things like ratings and comments and views have a different meaning when you know people and when you don't.

In my writing I often reference Harrison White's model of human interaction where he distinguishes between selection activities (meeting people, making choices), mobilization activities (building coalitions, gathering converts) and commitment activities (working together as a team towards some goal). What I saw was that Rakontu worked really well for commitment activities -- John and myself talking together about what we've learned about mistakes. Rakontu didn't work well for mobilization or selection. This is a good thing, because I had meant Rakontu to work for commitment. I chose Margaret Mead's quote in my first writings about it:

Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.

So that's a positive thing. I felt, in this tiny little test, that Rakontu did help a small group of thoughtful, committed citizens do something together, even if it was only a tiny thing. That gives me hope that it can keep doing that, eventually, on a larger scale -- or that its ideas can help with that sort of thing.

A surprising thing with relation to people and Rakontu -- I'm not sure whether to put this into what worked or what didn't  -- is that something like five or six people asked me if they could use Rakontu to collect some stories for short-term story projects. When I explained that it was meant to be used as part of an ongoing relationship and wouldn't work well for in-and-out story collection, they were disappointed. I suppose this is not very surprising, because my discomfort with the surgical nature of most story projects was one of the reasons I created Rakontu in the first place. It did make me wonder, however, whether I have been too purist about what should be created. For example, if Rakontu had the ability to do either short-term or long-term story collection, would the ideas spread more widely, and would it get more funding? Maybe. It's something to think about.

The social aspects of Rakontu - what didn't work

One of the most cringe-worthy moments while using Rakontu was -- and I thank this person heartily for participating, and mean no disrespect -- somebody sent me an email response saying something like "my story got three hits!" Sigh. So, in terms of people and social matters, the performance culture of today's storytelling, where people think they are on TV every time they open their mouths, was very much present even in the tiny attempts I made to try out story sharing. I wanted people to get away from the popularity rating that I believe precludes true sharing, especially of things as personal and emotional as stories, but I couldn't do it. You can't change cultural trends with software. I think any new work on Rakontu will have to confront that fact head-on and think of new ways to work through it.

The other thing that didn't work about people was that I have forgotten how little most people know about stories. There are several hurdles to getting people to understand why we are telling each other stories, what makes a story good or useful, what is a story, what isn't a story, what you do when you read a story, what you don't do, and why any of this matters. I tried to write succinct, helpful pieces for people just joining a Rakontu, but compared to typical social media applications, there is a much larger learning curve involved in storytelling.

One hope for getting people over this curve is that in a committed group, the people who are putting the energy into the project might be willing to explain the concepts in person and watch over things so that early misconceptions get put right. But that's a lot to ask. I was surprised how little the managers of the beta-test groups changed in the settings for their Rakontus. I set up Rakontu to be massively customizable. You can change what questions get asked, how activities are interpreted, what it looks like, what you tell people about why they are there, and many other things. However, I found that all the managers basically left everything the way I had set it by default. This is nothing against them, but it did make me realize that the hump extends all the way up to the people who are in charge of the thing.

I also think I had not realized how overwhelmed people are by all the software they have to contend with today. When I first started writing software, a typical user would have to make sense of only a handful of programs. Back then, it was not hard to find people eager to plumb the depths of your new software. But today, not only do people have dozens of programs on their computers, every major web site is its own program! No wonder people are worn out and don't want to learn anything. I realized this when somebody asked me if I wanted to start using Diigo to share web links. I wanted to, and installed it, but when I dropped down the Diigo menu for first time, I got this overwhelming feeling of too much, and I couldn't do it. I've come to realize that today, it doesn't matter if your software is good. There is just so much software out there, good or otherwise, that people need a very compelling reason to try it and learn it, before they can commit the time to it. It's a different world than it was.

I think this overload of web applications meshed with the "ugly" nature of Rakontu (I didn't have time to build in much mouse interactivity), in this way. I think people use the interactivity level of a web site -- its bells and whistles -- as a way of evaluating whether it is worth spending time learning. I do this myself. If a web site looks like somebody wrote it in 1995, I often move on. I'm guessing that when people looked at Rakontu and didn't see interactive graphics, they said "probably not that great" and moved on. I think the expectations for web software have increased so much that -- I should have seen this -- in the time I had available, by myself, I just had no hope of being able to make something as interactive and up-to-date as people have come to expect on the web today. That doesn't mean I think people are unable to see quality without adornment, it just means people are so busy they have to be very choosy. I was facing a bar much higher than I had imagined, and I should have backed off and chosen another path.

Building Rakontu - what worked

I built Rakontu for two reasons. I wanted to experiment with real working software in order to find out what would best support people sharing stories over the internet. I did that, if only in a small way. And I wanted to help other people think about how best to support people sharing stories over the internet. My hope is that the documents that have come out of the Rakontu project, if not the Rakontu software itself, will have a positive impact on the way people help other people share stories over the internet. So in that sense the project was a rousing success.

I think the most important thing that worked was that I got a chance to try out many of my ideas about story sharing in real software. I learned a lot building and using Rakontu. If I was to write Rakontu again, it would be vastly improved over what I could have done before because of all the things I have learned. My rule with building software, or writing books, holds for Rakontu: having done it, I'm ready to do it.

The other thing that worked was that I built something that works. I like Rakontu. I like using it. I would still be using it if I had a group that was using it. If I had written it for the desktop I would probably be using it for my own stories. (But watching over the web sites has taken too much time away from other things, so I can't really get back into that.) If I had more time to work on Rakontu, I would lean fairly heavily toward re-implementing it on the desktop and setting up some peer-to-peer or client-server capabilities on the back end, just to have more control over quality and reliability. (That's a hint of some of the technical stuff that I haven't excerpted, by the way.)

Building Rakontu - what didn't work

I wonder if I should have concentrated so much on building a working system. I only had a little time to work with, and I wanted to build something people could really use, but I probably still should have held back and written more of a proof of concept rather than a working system. In a working system there is so much more work to be done, on the help system, on testing, on talking to beta testers, and on and on forever. Prototyping frees you up to explore. So I wish I had prototyped more.

The other thing I learned, even though I had lovely support from some people (and many thanks to them, because they know who they are), I didn't have as much support as I needed. Bugs are disheartening. Disinterest is disheartening. Rejection is disheartening. It’s hard to keep up a project by yourself. You need moral support, and a lot of it, to keep going.

Still, I'm very glad I had the opportunity to do the project, and I'm glad I did it, and I learned a lot, and I hope to return to it, or to something similar, someday.

Story collection habits

Once in a while my six-year-old walks up to me with a tool he has found around the house and says, "Mommy, how do you use this?" My response is always the same: "Give it to me and let me use it, and then I'll tell you how to use it." For a while he thought I suddenly wanted to use the tool myself and didn't plan to give it back (which did not go over well). But now he understands that I can't tell him how to use the tool ... until I've watched myself using it. That is, some parts of me know how to use it, but other parts don't, and he's asking one of the parts that doesn't. Something similar happens when trying to explain how to collect and work with stories. So I've been watching myself "use the tool" the last few times I've helped people write questions for and about stories. A few posts have come out of it so far, and here's one more.

This post is about habits I've noticed, or maybe "things I seem to do that seem to help" while planning projects and writing questions. I'm not sure how any of these got started, but most of them probably arose from trial and error. The surprising thing, and something I never noticed before, is how much storytelling goes on in planning a story collection. (You'll see that as we go along.)

Please note that I'm going to talk here about what I do, not what you should do. My ways may not be your ways, and I'm nowhere near arrogant enough to believe that I know How To Do This Correctly. Still, hearing what I've observed about my own habits might be helpful as you observe and improve your own.

Planning the project

The first part of writing questions for and about stories is thinking about why you are collecting stories, about what, and from whom. I've written about planning your project, knowing your storytellers and knowing your topic in Working with Stories, and I do these things on every project. In addition, or as part of it, here are some consistent habits I've noticed myself following as part of the process.

Habit: Listening to the story of the project. I usually ask clients to go through the same exercises I talk about in the planning your project section of Working with Stories. I ask them to respond to questions about magical outcomes: What would you like to overhear people talking about? In what situation would you like to be a fly on the wall? Tell the future story of your project with it succeeding, and then with it failing -- what happened? That sort of thing. Of course the ideal preparation is to start the project with some real sensemaking, complete with storytelling and full-fledged exercises. Rarely is a client that willing or able (or knowledgeable about the group of interest) to do full sensemaking; but other things can stand in. For example, I try to absorb as much written information as possible about the project's official goals and background. Sometimes there is previous research or conversation I can look at -- a focus group, interviews, online comments, that sort of thing.

What I've noticed about this process is that by doing this I'm listening to the story of the project up to the point when I come into it. In every project there has been some plot development before I came along (as there will be when you start your project). Perhaps there have been other attempts to solve the problem and the client hopes for something different this time. Or this may be the first time the issue is being addressed. Sometimes the reason the client has chosen the narrative route is telling (I like to ask why they want to collect stories in particular). To make sense of the project's story, I've learned to pay a lot of attention to what people are saying between the lines. Like, maybe there is an official document, and in the official document they keep mentioning an issue over and over, and every mention says that the issue is trivial, but it's mentioned twenty times. That means something. Or, things that came out in the magical-thinking conversation are completely absent in the official goal-setting documents. Or, previous research skirts the issue. Or, nobody in the planning group is from the group they want to tell stories. Or, they are worried they won't get many stories. Or they are worried they will get the wrong stories, or people will say taboo things. And so on. All of these things help me understand the story I am fitting into.

Habit: Worrying. On purpose. You could call it the creative use of anxiety. One of the things I always seem to do on starting a new project is to visualize scenarios of all the myriad ways it could fail. To do this, I take what I know about the client and merge it with what I remember from the myriad ways in which other projects have failed. It's not hard to do this, because every project succeeds and every project fails. The mental image of a disappointed client, in a succession of flavors of disappointment, brings out the weak spots in the project in a way that straightforward reasoning cannot. Perhaps the client expects something I cannot deliver; or they want their storytellers to be more forthcoming than can be expected; or they want to find out things they are unwilling to ask about; or they don't really want to hear the truth; and so on. The story of the project so far mixes with these creative-worry fictions and helps to shape our approach to collecting stories. (This is probably what Gary Klein means in Sources of Power when he talks about people using "mental simulation" to troubleshoot upcoming events.)

The result of this creative worrying is a set of concerns that shape the project. Sometimes the concerns are not warranted, and I always check them with the client -- beware the wandering, self-reinforcing narrative -- but most of them lead to helpful guidelines when starting to craft questions. Perhaps we need to be careful not to use inflammatory terms, or we need to bring a difficult issue out into the light, or we should avoid a particular elicitation technique.

Do I visualize scenarios of success? A little, but it's like what Tolstoy said about families. The parts of projects that turn out well are usually similar, but each failed aspect of a project fails in its own way. I think I use scenarios of failure to map out the boundaries of acceptable space. The internal landscape of the space is all above flood level, so I don't need to map it out as carefully; and it's all safe, so I'm ready to be pleasantly surprised there.

Habit: Bouncing off the literature. A lot of the projects I work on (and a lot of the things you will collect stories about) have already been covered by academic studies in general. But that is not the same as covering an issue in the particular context of the organization or community you or I care about, which is why we are collecting stories in the first place. I've found that I often take a glancing look at the relevant literature in the connected area, but I hold back from doing more than that, for three reasons.

1. I rarely have time to do a full literature survey for a short project (though for a long one a deeper dip may be justified). 
2. When I allow myself to think about the mountains of research that have been done in any area, I get so intimidated by the academic hierarchy that I find myself unable to come up with any issues or questions at all, or I second-guess every question I write. It paralyzes me. All this story elicitation seems so sophomoric when compared to real research. But don't let yourself think that! What you are doing has value in context. The fact that it doesn't have value in general is true, but beside the point. (Reading about the goals of action research can help with these concerns.)
3. If I pay too much attention to an issue in general, it stands between my thinking and the needs and concerns of a particular organization in a particular situation. This is the most serious of the three reasons not to enter the literature too deeply. If a proper project on subject X should probe a particular issue, but in fact that issue has no practical use to the organization and the context of the work, you may waste your most precious resource (the time and attention of your storytellers) in seeking after it, while possibly missing something that does matter.

For these reasons, I often do a quick internet search on some of the main research findings in a field, say patient-doctor relationships or collaboration or citizen participation in local government, but I use what I find as inspiration for the project, not direction. Stick to what your particular project needs and don't be drawn (very far) into generalities.

Habit: Using scale as a scaffold. I find that scope, or scale, comes up a lot in projects that have to do with organizations or communities (and almost all story-listening projects do). The same issue can be examined at many levels, from the personal to the interpersonal, small group or family, tribe or clan, nation, and world or system levels.

To consider scale, I select in my mind a series of, let's call them, scale images with which to think about the issues of concern. For example, say the project is about treating customers well. I might visualize one employee sitting alone at a desk; one employee talking with one customer; an employee with their supervisor attempting to resolve a customer complaint; a whole team having a meeting about an issue that keeps coming up; and so on all the way up to large meetings where global issues are raised and global decisions are made. I draw these images mainly from my own experiences, but also from things I've heard or read about, movies I've seen and books I've read.

I superimpose the client's needs, wants, concerns, fears and hopes on this library of scale images. Perhaps the client mentions that employees want to help customers but have too much time pressure to give their full attention to each one. I carry this concern up through all the scales and think about the manifestations on each. How does each employee manage their time? How do employees help each other manage their time? How do they learn from each other? Why don't they have enough time? Who decides how many customers they should handle? How do different supervisors handle this? And so on. This bit of fiction informs the questions we will ask people about things that have happened to them, hopefully in such a way that patterns at all of the scales will come out in the stories and be amenable to exploration. We can consider the relevant issues at each scale, and we can pose questions and consider how stories told in response to them might play out at each scale.

I think I settled on using scales as a framework for issue exploration because it's omnipresent when dealing with organizations and communities, and because it's a value-free scaffold. It's a way to reflect on the manifestations of issues in multiple ways that won't distort the outcome the way other scaffolds, like say age or gender or personality or background, might. Also, the habit of thinking about different scales works across projects, so you can get better and better at it as you do more projects. It's one of the true universals in human endeavors.

Habit: Harvesting the chaff, then leaving it behind. This is such a standard practice that I hesitate to mention it, but I will anyway, for completeness. In the brainstorming phase of creation, quantity and diversity is the goal and the voice of the critic is rightly silenced. Early on, I write down anything and everything that comes to mind. I allow myself to blabber on about the topic, the storytellers, other similar projects, what the client said, what the client didn't say, stories similar to those we might collect: everything. I might pace around talking to myself, or keep a log, or talk to my collaborators, but I spew out anything that comes out and don't mind if it's pretty or correct. The editor comes in later, and I always expect to discard most of the early stuff. (It's usually pretty embarassing later, which is good.) At the end of the pre-questions period I usually have a fairly concise delineation of the project -- what we are doing, why, how. That gets shown to the client and checked and double-checked before we move on to creating questions. But there is a lot of chaff to be lost before we get to that, and I've learned to recognize the chaff for what it is: important to create and important to leave behind.

Writing questions

Here are some habits I've noticed when I'm writing questions. This stage normally happens after you've got a good understanding, and agreed-upon description, of what the project is for and what you hope to accomplish, and before you test your questions and start collecting stories.

Habit: Telling stories about telling stories. The process of moving from issues and goals to questions seems to go something like this (though not all of these questions are present every time):

1. What is the point of this question? Why are we asking it? What do we want to get out of it? What need are we trying to meet? How does it relate to our goals?
2. Does this question work better to elicit stories or to examine stories already told? What would happen if it shaped the story, and what would happen if it came afterward?
3. If I was talking to someone in person, in casual conversation, and I wanted to know about this, what would I say? If I was pondering the issue and ran into somebody in the hallway, what would I ask them?
4. How would I answer this question? How would some other people I know answer it? How would some people who disagree or have very different experiences answer it?
5. What would cause a person to respond to this question with a story? What wouldn't? What would work better?
6. What way of asking about this would turn people away? Why would anybody choose not to answer this question? How can we prevent that?
7. What sorts of stories are we looking to collect with this question? What sorts of stories don't we want to get? How can we improve the question so we get what we need and not the reverse?
8. What messages do I want to communicate to my storytellers with respect to this question? What messages do I want to avoid communicating?

If you read these questions carefully, you will see that each one of them elicits stories -- from you. The first question elicits a story about asking the question, getting useful answers, and using them. The other questions all elicit stories about things that could happen when people tell stories in response to the question. In doing this I am (you are) exploring the conceptual space around the issue by telling stories about it.

This is actually the observation that started this post. Last week I was working on some questions with a collaborator, and I realized how many stories we were telling during the process. Then I remembered other projects and how common this is. When starting a project I tend to look back into my own experience and the experience of everyone I know (in life and in fiction) for relevant touchstones. And I don't do that just once: I do it probably dozens of times as I work on the questions. If I'm doing it with someone else, we trade stories back and forth. Sometimes one of us knows something about the people we will be asking to tell stories, and we draw from what we know about them. Sometimes we actually have some stories that were previously collected, and we can look at them and ask ourselves questions, like: What question would this have been told in answer to? Or, how would they answer this question about this story? Or, how could we word this question to make sure this story is repressed? (And then avoid that.) We visualize people in the storytelling workshop, or looking at an online form, and come up with stories about how they will respond.

There is one serious danger involved in this narrative method of planning a narrative elicitation. If nobody in your project group has experiences similar to those of the people you will be asking to tell stories, you cannot do a very good job of telling these stories to yourselves. I've been lucky so far in that for most of the projects I've helped with, I've been able to plumb experiences of my own, or people I know well, that are relevant to the issues at hand. I've been sick and hurt and (moderately) poor and unhappy and angry and tired and grieving and proud and strong and stubborn and wrong. But I also know that there are projects where I would be hopelessly at sea. It's important to know where the limits of your experience lie and to get help when you are called to go beyond them. I can't imagine what sorts of stories people might tell about having loads of money, or loving sports, or being blind, or performing in musicals, or being Hindu, or building my own house from scratch, or not knowing where my next meal is coming from, or flying supersonic jets, or lots of other things I've never experienced.

When you come across one of these situations and you have no stories to offer, find stories you can use. Spread out. Gather. Either enlist someone on your team who has had lots of experience and listen to them (for hours if necessary), or gather stories in other ways. Read discussion boards, watch movies, do whatever you can to soak up "what it's like" to be one of the people you will be asking to tell stories facing what you want them to tell stories about. But even while you're doing that, recognize that this will not be as good as having actually lived through what you're asking about. When you know you are reaching beyond your experience, double-check more, trust your instincts less, and test more thoroughly.

By the way, this storytelling process doesn't work very well in writing. I like to talk through questions before I write anything down. If I'm crafting questions alone, I pace and talk to myself. If I'm working with a collaborator, I pace and talk to them.  What usually happens is that during this process some phrases jump out that convey especially well what we're trying to ask, and the question sort of crystallizes and takes shape. It seems to go through quantum leaps in utility, jumping to new levels of meaningful communication. For example, let's say I'm working with you and we're writing a question to elicit stories about the issue of burnout. As we explore the topic, we notice that the phrase "at the end of the day" keeps coming up. We realize that asking people to focus in on a time when they felt their energy was used up, perhaps at a natural turning point in their energy such as at the end of a workday, might communicate our need well. A question about end-of-day moments begins to form. 

What I've noticed is that when I forget this process and go straight to writing questions, which I do sometimes when I'm nervous or just getting started (chaff), the questions come out pale and devoid of emotional resonance. They sound like survey questions. But when I take the time to tell stories about telling stories and talk it out, I can find nuggets of connection that will draw out narrative responses.

Habit: Telling the stories of old projects. One of my favorite things to do when writing new questions is just to look back on old sets of questions from other projects. Often I'll open up old files and stare at the questions we asked then. What I'm remembering is not only why we asked those questions, but also how people responded to them. I'm remembering all the little stories that played out in the project. I remember a person who poured out their heart and thanked us for asking for their story; a person who took offense and stormed out of the room; a person who misunderstood the question and launched into a diatribe; two people who interpreted the same question in opposite ways; people who marked large "does not apply" slashes on all the questions after the one that offended them; people who wrote question marks all over one question; and so on. I remember the emotions I felt when I read the stories connected to each question and answer. The questions from old projects tell their stories, and those old stories help me anticipate what sorts of things might play out in the project I'm working on now.

As you do projects you are likely to develop a similar library of experiences. My advice is to help out your memory by keeping some traces of your previous projects. You may not be able to keep details, but it's usually possible to keep lists of questions you asked. Those can be strong enough memory triggers by themselves to do the trick. It's sort of like letting your eyes wander over your bookshelves to see if your well-remembered books trigger any new ideas. If you haven't done any projects yet, of course you won't have such a library, but you can talk to people who have collected stories or read about story collection projects as you get started.

Habit: Watching your story choices. The last habit I've noticed in writing questions is to keep a watchful eye on my own emotions while writing questions. Why? To check that the stories I am telling are the right stories to be telling. In Neustadt and May's excellent book Thinking in Time: The Uses of History for Decision Makers, the authors describe several ways in which people misuse analogical thinking and try to reason from analogies that don't match the current situation. This can happen when you are planning questions if the stories you have chosen for reference don't match the experiences of those answering the questions.

Neustadt and May mention three triggers that can lead to the wrong analogies being brought out.

1. If two situations are linked by a strong emotion, such as fear or remorse or sadness or pride, they might seem connected even though they are not. Say you are trying to write questions about power and control in an organization, and you can't get past your feelings about your current autocratic boss. In this case you won't be able to write questions that probe the entire issue, and you need to broaden the view.
2. What Neustadt and May call "folk memories," or memories close to your personal experience, can color your analogy selection. For example, if you are asking people to tell stories about their fussed-over cars, the connection to a car accident in your youth might distort the questions you are able to ask. Sometimes the issues are too close to your own life, and the volume and intensity of stories you can call up are too overwhelming, to make you a good writer of story questions. When this happens you need a less involved perspective for balance.
3. Some analogies that should come to mind are repressed because they are too painful to recollect. I've seen this myself; I sometimes realize during the question design phase of a project that I have been complicit in helping the client sidestep an issue that we all know should be asked about. When that happens I have to steel myself, bring the omission to the attention of my collaborators, and figure out how to make sure it stays in the project. 

At the group level, the selection of analogous stories can bring into play even more complications: groupthink, political maneuvering, oversimplification, doublespeak. The worst group-level pattern is when analogies are selected to advocate an approach or worldview, but presented as aids to reasoning. This can create a war of analogies as each person champions their favorite "blast from the past."

There are two approaches to reducing the dangers of inappropriate analogy selection.

1. Build diversity into your project group. If the topic is sensitive or the storytellers are anxious or the project is ambitious, it's a good idea to have several people collaborate on writing and reviewing the questions for a story collection. If you are just getting started and are planning a small project without heavy emotional baggage, of course you can prepare to learn from whatever mistakes you make. But when you need to work on something stronger, you need diversity in the group.
2. Develop group habits that increase diversity of thought and keep plans from solidifying too soon. I recomment devil's advocacy: what's the reverse of that, and what would it mean if we said that? What if our assumptions are wrong? How could this blow up in our faces? What if somebody had the same experience but saw it differently? And so on.

Don't forget the bad habits!

It would be silly to write about good habits in story elicitation without mentioning their counterparts. Of course we all have our bad habits, so it's important to map those out as well. I keep another library of all the mistakes I've made in story projects and the tendencies that led to them. (No need to tell you what they are!) A good sense of your weak points in story elicitation, as well as a sense of complementary strengths in your collaborators (and vice versa), is a treasure worth storing up.

One interpretation or two?

This topic came up in our Swimming with Stories group call the other day. Swimming with Stories, if you didn't know, is a Ning group whose primary purpose is to coordinate monthly phone calls where we trade ideas related to story listening. Anyone working in this area is welcome to join us.

So anyway we were talking about perfectionism, and we were trading methods for doing our best work in spite of it. At one point I mentioned that one reason for over-polishing is to avoid the unpleasantness of nasty reactions by those receiving the work. That led to talking about my rules about separating statements and providing provoking perspectives when looking at stories. These rules, together, were one of the biggest discoveries I've made about working with stories. I came up with these rules mostly for the betterment of the people telling the stories, since their stories are often interpreted by others. But the rules also protect the people looking at the stories from preventive self-censorship, which is damaging to sensemaking. The second rule, of including multiple interpretations of every pattern, is essentially a form of steganography, of hiding a signal in noise, which has the dual benefits of freeing expression and providing better raw materials for sensemaking. I thought I'd write some about where that rule came from here.

Coming up with competing interpretations is one of the hardest parts of looking at stories, but at the same time it's one of the best parts. It's hard because sometimes you have to kick yourself to find another intepretation (especially when the obvious one is so overwhelmingly obvious that anyone could see it). But it's also one of the best parts, because interpretation is the good stuff, the meat, what leads most directly to useful sensemaking and decision support.

I've noticed a pretty strong and consistent difference in how people react to single versus multiple interpretations of patterns in stories (and answers to questions about them). When people encounter one interpretation, you can see them taking sides: do I agree or don't I? Their attention is on the interpretation, not on their own feelings or beliefs or experience. They put on their armor and prepare to do battle. It's clear that the one interpretation they see is the interpretation held by the author of the report: why else would they write it? And as the interpretations build through the report, people build explanations about the whole report: it's biased, or the author doesn't know what they are talking about, or the statistics are flawed. All of this stops sensemaking short and destroys any hope of productive thought or discussion.

In contrast, when you give people two or more competing interpretations of the same pattern, they turn their attention away from attacking or defending the interpretations and toward exploring their own experiences. This is what you want people to do: you want them to dwell on messy ambiguities, to use them, until they resolve themselves naturally (or don't). If the author has written two interpretations, the reader can't tell which is the author's own, so there is nothing to attack or defend, and there are no larger explanations about bias or ineptitude to build. The report author essentially walks out of the picture and lets the reader think. The reader can put away their armor and get out their maps and spyglasses. They can explore.

You could visualize a single interpretation as a point in space, like a pinpoint of light: it's on (right) or it's off (wrong). There is no room inside that point for anyone but the author of the report to stand. And they can't be anywhere but there, can they? But two interpretations define a line in space, and three interpretations define a plane. Since the author of the report has not identified their position in the space but has merely laid it out and stepped away, the space is empty, thus inviting. The reader naturally enters the space, finds their way around in it, and perhaps expands it as well. This is what sensemaking is about: finding our way around the world in order to make decisions about it. And this is what organizational and community narrative, ultimately, is about as well.

Let me give you a more concrete example of how this works. Say I am looking at stories people told about their telephone service. Say I've seen a pattern that the younger the respondent, the more likely they were to say they felt disappointed by the events in their story. If I give people one interpretation -- that younger people are not happy with their telephone service -- people start turning their binary switches off and on. Yes that's right, no that's wrong. But what happens if I say that younger people might not be happy with their telephone service, or older people might not understand the question, or younger people might be more willing to admit to disappointment (whereas older people might feel more pressure to say everything's fine), or younger people might be more disappointed about other things and it drifts over, and so on? I've marked out a space for exploration and invited people on a journey instead of setting up a straw man to be knocked down.

A final point: not everybody is comfortable with competing interpretations. Sometimes you have to argue with people to give them what they need. Sometimes people want The Answers, not mental stimulation, even when nobody can give them the answers. Stories don't provide answers, and patterns in stories don't provide answers, because none of this stuff is scientifically verifiable in repeatable experiments. It's not meant to be. It's all food for thought.

Stories and patterns in stories are like seeds: seeds of answers, seeds of potential conclusions, resolutions, explanations, plans. They can't grow into those things without the fertile soil of open, exploring minds and the light of discussion. Answers aren't seeds and they can't grow, no matter what soil they fall into. They are not food for thought, they are food for use, for consumption. For some goals, like building bridges and designing telephone cables, answers are what is needed, and growing conclusions would be ridiculous, even dangerous. But for complex topics of human interaction, food for thought is the only type of food worth having.

Resolving tensions between storyteller and story elicitor needs

Here's another question-from-a-correspondent going-into-the-book post (thanks correspondent!). The question is: how do you write questions so that people don't latch onto the "right" answers instead of telling you how they really feel?


Tensions between needs

There is a tension in asking questions (both for and about stories) between what you want to know and what people want to tell you. These are some situations where the tension is greatest.

1. Dependence. If your storytellers are in some way dependent on you, their first priority will be giving you what they think you want them to give you (which is rarely what you really want).
2. Identity. If your storytellers feel that the topic of the questions taps into their identity, their first priority will be keeping the image they present to you positive, coherent and under control.
3. Conflict. If your storytellers are in conflict with you, their first priority will be either undermining whatever purpose they think you have in mind or promoting a different purpose. (Be careful here because what matters is whether they think they are in conflict. Sometimes it's hard to guess.)
4. Distrust. If your storytellers do not trust you, their first priority will be getting through the exercise without disclosing anything.
5. Disinterest. If your storytellers don't care about you or about your topic, their first priority will be getting through the exercise as quickly as possible without thinking too deeply about anything.

A great way to find out whether you have any of these situations is to run some pilot story collections and either observe people as they come out of the session (or finish telling a story), or simply ask them how they feel about what just happened. Then look at what they said, thus:

1. Dependence. A storyteller who feels dependent will finish the storytelling and say, "There! I think I did that right." Or, "Hope that was good enough!" If you hear people saying words like right and good and better and correct, you are probably dealing with dependence.
   
2. Identity. A storyteller who feels the elicitation touches on their identity will finish the storytelling and say, "There, I explained what it's like to be a doctor." Or, "It was interesting to think about my motivations in teaching." People accessing identity tend to use words like explain and inform and clarify, because more emotionally-laden words are too threatening.
   
3. Conflict. A storyteller who feels in conflict will finish the storytelling and say, "There! I guess I gave them a piece of my mind." Or, "That should shake them up." Here you want to look for action words, like give and take and disturb and bother and shake up and surprise, because their storytelling is an action. They hope to change something by it: either you or the thing you are trying to do.
   
4. Distrust. A storyteller who feels distrustful will finish the storytelling and say, "Can I see that transcript? I want to change something." Or, "Let me see that privacy policy again." Or, "I'm not sure I should have said that." People who don't trust you tend to replay the experience over and over in their minds, looking for problems and being retrospectively anxious.
   
5. Disinterest. A storyteller who is not interested will finish the storytelling and say, "Time for lunch!" Or, "I wonder what's on TV tonight?" Or, "I've got two more meetings today." In other words, the minute the storytelling session is over, it's gone from their minds. If you ask them about the session itself, they will either not respond, or they will say things like "It was all right" or "nothing to say" or "sure, great."

If you gather enough reactions to the storytelling event, you wil get some hints as to whether, and how much, any of these tensions is present. If you can't run a whole pilot project, just ask as many people as you can, of the groups involved, to tell you a story casually. Even as few as five reactions can be useful.

So let's say you have gathered some stories and you have surmised that one or more tensions will be involved in the storytelling you will be asking people to do. What to do next?


Your view, their view

What I do and recommend in crafting questions is to tack back and forth between meeting your needs and meeting the needs of your storytellers. Start with your needs first. Write the questions you would ask in an ideal world, if you could peek into the minds and hearts of your storytellers, if they had no inhibitions and were guaranteed to answer every question honestly and completely. Go ahead and write the questions that ask the things you wish you could ask. (Just don't show them to anyone yet!)

Now, tack to the storytellers' side. Here you need to do a bit of role playing. For each of the tensions you've discovered, look into your past and come up with a situation you remember well where you were asked to disclose information and that tension was important. Some ideas:

1. Dependence. Think of a particularly tense job interview, one you forced yourself to get through. To ramp up the emotions, think of one where you really, really wanted or needed the job, but where you didn't think your qualifications were perfect for it. (I think all of us remember some times like that, when we were stretching our claims of ability, just a bit.) Another one that works here is to think about a time when you were financially dependent on somebody or some organization. Perhaps during college you got a scholarship? Or you received a gift from a relative? It's okay to go all the way back to childhood, as long as you can get into the mindset you need. I remember asking Mrs. Masters up on the hill for a piece of candy and feeling her scrutinizing have-you-been-naughty eyes on me. That sort of memory.
2. Identity. Think of a time when you felt a great need to be who you said you were. One useful experience that comes up for me is when I've given talks at conferences: I feel on the spot, challenged to prove that I am who I say I am and that I know what I've said I know. Think of times when your position as a whatever-you-call-yourself was on display. Even non-professional titles can be useful: mother, sister, neighbor, grandchild. Tap into one of those times when that little voice in your head keeps joking, "Pay no attention to that man behind the curtain."
   
3. Conflict. Think of a time when you tried to tactfully get through a conversation with somebody you had to be nice to, but who said things you felt like screaming at them about. To ramp up the emotions, try to select a time when you wanted to get out of the conversation but couldn't for some reason; and look for a memory where the conflict was something you actually cared quite a lot about but couldn't say so without making a scene. I've had some useful experiences in narrative workshops with people cornering me and giving me lectures on whatever they think is wrong with the world (evidently I appear vulnerable to this), and where I felt constrained to not say, "That's ridiculous!" Not-about-the-weather conversations with relatives and neighbors can also be useful in this regard. 
   
4. Distrust. Think of a time when someone asked you something about yourself that you didn't think they needed to know, and that you didn't trust them to keep to themselves. Think of those little cards that come with some products that ask you how often you wash your hair or read the newspaper. In the U.S., the census is a good thing to think of, at least if you were like me and got the "long form" the last time (why does the government need to know how much money I make and when I'm not at home?). Look for memories when the distrust tension was not strongly associated with the dependence tension: it's probably not good to think of a time when your boss or employer wanted to know something. Go for somebody more distant, like a big company or the government. I remember one time I did an interview for a radio show, and I knew they were going to splice and dice what I said with what other people said, and that made me a little nervous. You can also use memories of personal interactions, like a blabby neighbor who asks more questions than you'd like to answer.
5. Disinterest. Think of a time when you were bothered by somebody asking you about something you didn't care about. A perfect example is telephone surveys about ordinary domestic things, like toothpaste or Coke or telephone service. Or remember a time when you were walking through a shopping center, museum, or other public place and were accosted by a person with a clipboard. (You tried to avoid them but they were endearing or looked unhappy and you felt sorry for them.) Bring back your tangential participation in the event; remember how you were about to hang up or walk away at every moment; and remember how you kept saying "does not apply" in a bored way. Or how you tried to make sport of the whole thing, just as a diversion on a rainy day. Or how you tried to make the interviewer break from their script, just to see if you could. Get into that silly I-don't-care frame of mind.

Okay, so now that you have chosen a bona fide memory -- and it should be something that really happened to you, else it won't be powerful enough -- place yourself into that memory and read your questions again. Pay attention to the emotions that surface. See which questions and answers jump out at you and flash messages. Some questions and answers will flash red -- danger, danger -- and others will flash green -- safe, safe. Both extremes are dangerous to your project's goals. The dangerous questions and answers won't collect any responses, even if they should; and the too-safe questions and answers will collect too many responses, even ones that should really be elsewhere.

Next, take off the memory and go back to being in your current situation of wanting to find things out. Remove the red and green flagged items, then find places where you've lost significant information as a result. Which changes jeopardized your chances of meeting your goals? Picture yourself looking at the collected data, and think about whether you will get what you need. Keeping in mind your simulated storyteller's reactions, tone down the questions and answers you need to keep, and try to arrive at something they will not run from (red flag) or cling to (green flag) but that you can still use. Then put your memory back on and become the storyteller again. Keep doing this. Keep finding flags and removing them until you get to a compromise everyone can live with.

At some point the pendulums you are swinging should come to rest, but at a different place for each question on the spectrum between what you want and what they want. For some questions you may have to face the fact that there is no way to get exactly what you want. For others you may decide to hold out for greater disclosure; but when you do that, make sure to provide a good non-response response to divert the flow and keep the true responses pure.

An example

Let me give a little fake example. Let's say I'm working on a project in which I wish I could ask a question about coping skills at work, dealing with deadlines and such. Let's say I've written this question: "Do you think your work skills cope well with deadlines?" And the answers run the gamut from, "Yes, I have great confidence in them" to "They used to work but things are getting worse and I can't keep up" to "I've never coped well with deadlines."

Now let's say I've gathered, through some casual story elicitations, that dependence will be an issue with this storytelling group. Here I would drag out some of my memories from college, when my ability to keep attending school depended on keeping my several jobs and keeping my scholarship. Now I read that question about "work skills" in my mindset as a dependent student. Immediately the "great confidence" answer glows green (safe) and the other two glow red (dangerous). Admitting any weakness or uncertainty is the last thing I would have done in that context. It's clear how I would respond.

Of course these are not the flags I would raise in my own mind today, outside of that memory context. Today, I'd just choose that I'm horrible with deadlines. I don't mind admitting it. Even if I am in a dependent situation, I'm comfortable enough and confident enough in my abilities that I don't mind saying I avoid deadlines by doing a lot of the work up front, because I know very well that I fall apart when things get down to the wire. Now some of the people in my storytelling group will respond as I did. Nothing will glow red or green for them. But that's not a problem. I said I sensed a tension, and that means I sensed that a significant portion of the people will be affected. Those are the people I am compromising with; the others will participate without any such compromise. That's why it's always better to increase the range of answers to give the people with tensions something to choose or a story to tell. But don't lose anything: enhance, don't narrow. Don't make it work for one group only to lose another.

So, having finished my memory-context reaction, I now go back to my project-planning self and see what other answers I can come up that suit my goal of helping people develop stronger coping skills without raising those red and green flags. Perhaps I'd add more answers, or perhaps I'd come with another axis of variation that would be less likely to raise flags but still give me useful information. It might be better to ask about what sorts of coping skills work best in what situation, or whether their coping skills have changed over time, or what they have learned about coping skills as they have been in their job. There is often a lot of terrain between what you want and what they want: you just have to explore the landscape and find it.


Test, test and test

The final stage, if you can do it, is to test your questions with some real storytellers before you start the larger project. If you plan to collect lots of stories, say more than a few hundred, this is very important, because the more stories you collect the more of a tragedy it is when you don't get the answers you hoped for. Play-acting with your memories as a guide gets you part of the way, but real storytellers will almost always surprise you, at least a little.

Natural storytelling V - bits left over

I found a bunch of scribbled notes that I had meant to incorporate in my last long post, but they got forgotten, so I thought why not make one more post-let and add them. (This is in reference to the long post that starts here so you may need to read that to make sense of this.)

Two of the notes had to do with the issue of narrative events (storytellings) versus narrated events (what goes on in stories), and how today's movies and television feature narrated events and obscure narrative events.

First, do you remember how Mister Rogers, Captain Kangaroo and Romper Room used to talk to you? (If you are too young to know, check the links to find out what these things are.) I remember feeling as though each of these people was talking to me, personally; but it was always clear that they were real people on a real stage (you could usually see the stage) and that we were participating in an event together, as real people. In contrast, I've been watching some assorted kid's videos with my six-year-old, and I noticed that today, it's not people who address the audience, it's characters. Dora the Explorer talks directly to viewers, as do the kids in PBS' Super Why series. This is a perfect example of how the narrated-event picture has enlarged beyond the narrative-event frame. The storytellers are gone from the picture; all we see is the inside of the story, as though it was the only real thing.

Second, I was thinking about the joke-after-a-joke when you tell about something funny, and people don't get it, and then you say, "You had to be there." I've noticed something lately, which is that people used to say that about things they had actually done, but I keep noticing people saying it about television and movies. I just took a look and verified that it's not just me hearing it in person; it's easy to find people making such references on the web. One person even said "You had to be there" and then, "thanks to YouTube you can." The question is: you had to be where? Because, where were they? Inside the story, I think. I had noted this down as yet more evidence that people are viewing stories not as narrative events but as narrated events.

Finally, the third note I forgot to include was about qualification and illness and stories. I said that Hans Castorp in The Magic Mountain became qualified to be a patient, with all its attendant rights and privileges, and then I said that was connected to people saying they were unqualified to tell stories. The obvious question is: if people don't believe they are qualified to tell stories, what do they think they are qualified to do?

My guess is that tellers of Good Stories and members of Good Audiences are exclusive categories. In other words, being qualified to be a member of the Good Audience automatically disqualifies you from being a teller of Good Stories. If you try to be both, you will tip over to one side or the other. This explains the problem I mentioned several posts back, in the one on whether people tell stories, that once people start working with stories professionally they have a harder time telling natural stories, because they slip into thinking of themselves as tellers of Good Stories. And, that people who think they never tell stories are probably very secure in their identity as Good Audiences for Good Stories.

In The Magic Mountain, while Hans Castorp is fully qualified to be a patient, he would never presume to claim that he was qualified to be a doctor. There is even a hint that Director Behrens is breaking the rules by having a touch of tuberculosis himself:

... [C]an someone truly be the intellectual master of a power to which he is himself enslaved? Can he liberate if he himself is not free? To the average person, the idea of a sick physician remains a paradox, a problematical phenomenon. Instead of being intellectually enriched and morally strengthened by his experience, may he not perhaps find that his knowledge of the disease becomes clouded and confused? He no longer stares down the illness with a hostile eye; he is a biased and hardly unequivocal foe. With all due respect, one must ask whether someone who is part of the world of illness can indeed be interested in curing or even nursing others in the same way a healthy person can.

It is not the role of the doctor to know the disease intimately, to be "battered" by it, to be "enslaved" by it, to live with it -- because it causes you to become "clouded and confused" as a good patient (in their obligation of passivity) should. It is the doctor's role to stand outside the illness, to be "free" from it, to stare it down, to defeat it from a distance; and for that doctors must be active as well as knowledgeable.

Again translating the metaphors, the reason people react as if they are unqualified to tell stories is simply because they are qualified to do something else, and they cannot do both, by the rules of the hierarchy. It is not their role to tell; it is their role to listen, and to listen well. Reviving community storytelling would be helped by reducing the exclusivity of the two roles as well as by reducing the draw of both extremes, thereby allowing people to range more broadly in their identifications with respect to storytelling.

So, as I said, just some scribbles I found that I forgot to include.