(And then, in the fourth of the series of eight, this is the fourth in a nested series of four: telling stories, making stories happen, listening to stories, and herding stories.)
Herding stories
This observation is about getting stories to where they need to go when it isn't you they need to go to. It's about helping people experience the stories of other people for a reason you care about: helping, educating, persuading.
When I look back over the story projects I've done ... the fact is that I haven't actually done many projects in which I helped people pass on stories. More often I've helped stories disappear into a black hole.
It wasn't that way at first. Early on, most of the projects I worked on had a strong distribution component. I remember helping consultants prepare CDs containing hundreds of stories to be distributed to hundreds of people. But somehow, and I can't really put my finger on when this happened, the story projects I was asked to help with underwent a sea change to the distribution of reports and conclusions rather than stories.
Bigger, better, faster, cheaper
If I think about the factors for this change, I can come up with three: size, ambition and distance.
- The earliest projects involved relatively few stories compared to what came later. I think our first-ever proof-of-concept "narrative database" had 35 stories in it. As the number of stories collected grew, first to a few hundred than to over a thousand, it became more difficult for people to take in all of what had been collected.
- The projects got more ambitious as time went by. They began to address larger, more difficult, more intense, more emotional, and more potentially damaging information that clients didn't want to spread around too much. They began to address not just issues of tactics but of identity. The more consequential the projects became the more people felt they needed to be kept private.
- The projects moved further into understanding the minds of people in other groups. Most of the earlier projects were about "things we say to ourselves" (or "things we say to ourselves about them"), while most of the more recent projects I've worked on have been more about "things they say about us."
So, for these reasons and probably a host of others, the projects I've worked on have migrated into an area where herding stories means collecting them in a pen and never letting them out again, or only letting out a carefully selected few. Of course this is a useful approach for many big, ambitious, distant projects. If the goal is to recommend policy improvements to a huge government agency, it is more productive to have twenty or fifty policy makers work with the stories in a three-day workshop than it is to distribute the stories to thousands of people. And it's a lot simpler and cheaper too.
But still, something has been lost. It seemed like in the early projects there was more diffuse organizational learning, more cultural change, more energy generated than there has been recently. So many people were exposed to the raw stories that the stories entered into the life of the organization in a different way than they do now. I miss that.
Shrews and pandas: Story project habitat diversification
This distinction reminds me of something I said a while back about how some stories are like tiny animals, some are like cute fuzzy big animals, and some are like slow-growing funguses that cover acres. Maybe story projects are like that too. Maybe what happened is that I started out helping with shrew projects and slowly moved into panda projects. But the shrew projects still need help, and so do the giant fungus projects, and those are not as well supported by the field, at least not from what I see people doing.
I don't think it's wrong to support one type of project rather than another. Not at all. What I'm saying is that the ecosystem of organizational and community narrative can only be healthy when a wide range of story (and story project) habitats is available. The ways in which such habitats are available can and should be diverse. The optimal habitat for tiny story projects used to be the kitchen table or the community center; but that habitat has been undergoing massive fragmentation.
It was in response to these sea changes - both in the organizational narrative field and in natural story habitats - that made me want to build Rakontu. (If you don't know already, Rakontu is my free and open-source story sharing web application.) Projects that use Rakontu are shrew projects, though I suppose funguses could grow there too, in time. Certainly I'm not so arrogant or stupid as to believe that my solution is the solution to habitat diversification for story projects, but I do humbly hope that the ideas in Rakontu can help to move that process along.
In practice
To balance things out, here's what I'd like to see more organizations doing. Discover the energy that comes from having more than just the people in the policy-planning team engage with collected raw stories. Here are a few fictional scenarios.
Say you want to improve customer service. You have collected stories from the customers who hate you the most and love you the most. Rather than bottle them up and distill "strategic insights" from them, let the stories run loose all over your organization. Invite people to talk about them and tell their own stories about them. Invite people to suggest new policies that will change the way customers see you. Don't be afraid that the stories will "get out" - tell people what you are doing and why, and you'll gain by demonstrating that you are confident enough to take your faults seriously. (The story that you take negative stories seriously is a great positive story, by the way.)
Or, say you want to help your merger succeed. You have collected stories from both merging groups. Instead of having a small number of people give you a report on "signals" in the data, create a common forum and place the stories there as conversation starters. See what conversations take off. Ask people to use the stories to find opportunities to work together.
Or, say you want to guide government policy about an issue that affects millions of people. You have collected stories about how members of the public see an issue. Here's a crazy idea: show the stories to other members of the public, and ask them to respond with stories of their own. See what impact it has, not on what goes in behind closed doors, but on what people say to their government representatives.
I can hear something ... all right, somebody out there is sniggering. Yes, of course doing these things may produce mayhem. Of course the results will not be clear or reliable. Of course people will post all sorts of useless crap. That goes without saying, but it's not the point. What I'm trying to say is, the way of "finding out important things in order to change important things" is not the only way to improve things with stories. There is also, sometimes, merit in simply building pathways for stories to travel on that weren't there before.
I know I'm way over my metaphor limit for this post - but - it's kind of like, if the ants need a bridge, you can spend lots of money and bring in lots of big machines and build something important and correct and permanent. Or you can put little crumbs in the right places, and the ants will build a bridge of their own. The ant bridge won't hold heavy equipment or even stay in place for very long, but the ants will get something out of it. If what you want is to help the ants be ants, that might be exactly what you need to do.
And one more thing: please, if you are already collecting stories and making them available to other people, stop categorizing them by location and date. Give people some meaningful ways to find stories. Ask people how they feel, or why the story was told, or who would be helped by it, or when it can't be told, or who will be most likely to retell it. Take a look at the ideas behind Rakontu and copy them for your project. I don't mind; I'm dropping crumbs for the ants. I want to help them be ants.
2 comments:
Love this post. Absolutely love it. On the projects I've done, I've always found that the raw anecdotes get to people more than the graphs. They are what people remember.
As to volume of stories, assuming the scope of a story project is well defined, I've seen a lot of repetition, and few new insights, after 100 or so stories. Perhaps groups would be better served by focusing on the texts of the 50-100 stories than, as you write, looking at lots of reports.
I've also found that different insights come up from story texts vs. metadata. For example, a group found on one of my story projects (stories from sales calls), that a "customer confusion" pattern emerged. It was clear from the dialogues that this was happening, but it did not emerge from the metadata at all.
The client's insight was: "Wow, it is easy to confuse our prospects, because our products are complicated with lots of options, and our reps don't always explain them well. Oh, my--we are about to launch a new set of products that will give customers EVEN MORE options! We need to talk to the marketing folks right away!"
Thanks, John. More thoughts about numbers of stories: Fifty stories is minimally tolerable but will get only the low-hanging fruit. I get nervous with so few stories. A hundred stories is a great number for getting most of what's useful without being overwhelmed.
But there is sometimes merit in pushing it up above 100, because doing that tends to sort the very important from the less important; you get more definition in your themes and patterns. I'm happy when I see 120 or 150 stories, especially if more than one issue is being explored. But at the same time, as soon as you get much over 100 stories you start hitting difficulties in distribution. The range between 100 and 150 is a sort of "sweet spot" for getting enough without getting overwhelmed.
When you get over 200 stories you get into dimishing returns for most projects. I've never seen a project with more than 200 stories (and I've seen some as high as 5000) do more than heap up more patterns of the same thing. If your goal is quantification or strong proof, or your topic is very broad or ambitious, heaping up patterns MAY be important. But for most projects it's just not worth it. And huge volumes close off other possibilities such as keeping within a scale that works for distribution. Collecting something that everybody in the company can read in a half hour may be more important than collecting large patterns, in some cases.
I like your point about insights that don't come out of the metadata. That's true, and it may be part of what saddens me about the shift in projects. Questions about stories should ADD to the insights gained from reading stories, not replace them. One could even say that collecting questions about stories and counting them up, without reading the stories themselves, is just another way to look into the looking glass without climbing through to the other side.
Post a Comment