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.