Last month I had the opportunity to give a 90-minute talk to 16 Silicon Valley CEOs in San Jose. They all believed in business storytelling and wanted to dig into the practicalities of the skill. One of the questions they had was, ‘How do you do storytelling with deeply analytic and scientific communities, both internally and externally?’
Here’s what I said.
There’s a little exercise I do at the beginning of my workshops. I ask people to pair up and share with their partner what they do for a living, for about a minute. Then I ask them to share a recent time when they made a difference for someone at work.
My first question typically elicits a list of characteristics and actions – bullet points. While the second question often triggers a story, an experience.
I then ask the group what they noticed between the two ways of communicating. They tell me the first way was boring, difficult and hard to sustain, while the second approach was interesting, easy, memorable, personal and sparked their own memory or similar events.
They have just demonstrated for themselves the effectiveness of storytelling and how natural it is for us to share our experiences.
Technical people appreciate research and science, so share with them some of the research experiments that illustrate the characteristics of storytelling. I have written about these experiments in my book, Putting Stories to Work, and I call out three story superpowers: they’re memorable, they convey emotion and they’re meaningful.
In 1969, two Stanford University professors, Gordon Bower and Michael Clark, set out to test the memorability of words embedded in stories against that of a random list of words. Participants in the experiment were asked to memorise and then recall 10 sets of unrelated words. One group remembered the words in any order they wanted, while another group used the words in each set to construct a separate story. When asked to recall the words, those who had constructed stories were able to remember 6–7 times as many words as those who had not used stories. Memory champions use the approach of constructing stories from lists to great effect—the world record for remembering a pack of 52 playing cards using this technique is currently 20.44 seconds.
Your techos might be thinking: ‘I just want the facts. I don’t have time for any namby-pamby emotions. And I don’t need them to get the job done’. This is how many technical and scientific people think, and it’s a mistake. The psychologist Jonathan Haidt explains this flaw of rationality using the memorable image of an elephant and a mahout. Picture an elephant which is being guided by a mahout riding on its back. Now communication is often about influencing behaviour, and this involves a struggle between rational, well-reasoned thinking and emotional urges. The mahout represents rational thinking: when she clearly understands where she needs to go, she directs her charge that way. The elephant represents emotional urges: while the elephant might be happy to go where the mahout directs it, if it decides to go in another direction, there is absolutely nothing the mahout can do about it. Stories help you communicate with the elephant in the room.
Did you ever hear an explanation for something that just sounded like gobbledegook, and so you said, ‘Can you give me an example?’ This simple question is likely to result in a story. When we hear that story, we inevitably feel more relaxed and in the picture. That’s because we are hardwired to seek stories that give the things around us practical, concrete meaning. This is why stories are so useful in making a point: the story is evidence of what you are proposing, and if it’s your own story it also highlights your experience. In fact, in the absence of a story that explains what’s happening, we often just make up one that does. This was beautifully illustrated by two American psychologists back in 1944.
Fritz Heider and Marianne Simmel created a three-minute, silent animation in black and white, consisting of a large triangle, a small triangle and a small circle. The shapes move around the screen in a way that suggests the story of a heroic little circle that saves the small triangle from the big triangle bully. At least, that’s one story people tell when they see this video. Sometimes people think it’s about a big dog protecting its territory, or a father chasing away his daughter’s suitor, or a workplace dispute. After nearly every viewing, the audience tells a story to explain what’s happening onscreen. Only rarely has anyone said: ‘They’re geometric shapes moving on a two-dimensional plane’. In a simple and clever way, Heider and Simmel showed that we just can’t help but make meaning out of everything we see. We are averse to uncertainty and ambiguity. We do all we can to create mental closure so we can get on with things, particularly if we feel threatened. And we bring this clarity to an experience by telling ourselves a story. And if you are sharing the story you want people to get, they are making up their own story and it might not be the one you want them to take away.
There is a false dichotomy we must deal with which is, on the one hand there are the facts and on the other there is the story. The reality is that a good story has facts. The facts give a story credibility. Knowing the dates, the names of people and places, the details, what actually happened, all add authority.
When a technical person is asked to tell more stories they often think they have to tell personal stories and they recoil. While personal stories are a great way to connect with an audience, there are many other types of stories which can be shared to avoid getting too personal.
Here are just a few possibilities:
I remember working with the scientists from Australia’s top government science organisation, CSIRO in their Mathematics, Informatics and Statistics Division. I was helping the scientists make their presentations more impactful. One researcher was working on chemical blooms in the Brisbane River. The first version of his presentation talked about taking measurements of regular chemical blooms in the river and how the chemicals morphed over time. He had developed a series of formulas to model the event. So, I asked what the blooms looked like. Like a purple stain across the water. When did they happen? Early in the morning, around 5am. Take me back to the first time you were at the river taking measurements, what was it like? He painted an evocative picture of what it was like to see the bloom for the first time and how he took his measurements. You must add that to your talk, I said. He did and we found a bunch of other places to bring his talk alive with his real-life experiences. His talk was a hit.
My client, Carrie Bengston, was the head of communications for that division. At her farewell morning tea years later, she was told that the storytelling work had an incredible impact and transformed how they interacted with customers and research partners both in their one-to-one conversations and in presentations.
OK, we now have most of the objections out of the way and made our case for storytelling. Now we need to shift to helping build technical and scientific people’s storytelling skill.
The first step is helping them be story spotters.
Another way to build you story-spotting skills is to listen to story-laden podcasts and see if you can spot the stories told based on our framework. Here are some of my favourite podcasts, replete with stories.
Once you have developed story spotting skills, you will start to see that the best science and technical communicators share stories to make their point, but they rarely use the word ‘story’. They call them examples, illustrations or simply something that happened.
A great example of someone who does this well is the biologist, oncologist and author, Siddhartha Mukherjee PhD. I was listening to the radio on my drive to work recently and heard him being interviewed. When he answered a question, he would start by making his point about the science and then wrap up his idea by saying something along the lines of, “Let me give you an example. A patient visited me recently …”, and he would tell a story to illustrate his point. He is a master science communicator. In 2011 he won the Pulitzer Prize for his book on cancer, The Emperor of All Maladies: A Biography of Cancer. It is filled with stories.
We were part way through a Storytelling for Sales workshop in Seattle for Microsoft, I was teaching their technical salesforce story skills, when one of the participants expressed his concern about influencing people based on a single event, a single anecdote. This is a common concern especially among the scientifically minded who have been taught that the plural of anecdote is not data.
A great way to keep using story skills and get all the advantages of the technique, but also incorporate statistically valid populations of data, is to tell stories about published experiments that draw on these types of datasets. Here’s an example.
Stories are memorable because they evoke pictures in our mind’s eye. The memorability of images was nicely demonstrated in a paper called Learning 10,000 Pictures. In the early 1970s an experimental psychologist, Lionel Standing, wanted to test just how much we can remember depending on the characteristics of what we are remembering. Earlier researchers in the ‘60s showed people were better at recalling concrete objects such as scenes, sounds and objects over abstract information such as letters, words and numbers. But they had only tested smaller sets of objects. Standing wanted to see what happened when participants were shown 10,000 pictures.
He used his students at Bishop’s University in Lennoxville, Canada. In groups of 5 they watched 35mm slides projected in a dark room. Each picture was shown for 5 seconds with about ½ second between slides. It takes a long time to see 10,000 images so the students were given regular breaks. When they had finished, they were brought back into the viewing room two days later. This time they needed to indicate the pictures they had seen from ones they hadn’t from two days earlier. The images were placed next to each other and they just had to record Left or Right.
Standing showed that, while there was a drop off in what they could remember compared to the smaller sets of images, at 10,000 images the participants could remember about 6,600 correctly. A pretty impressive feat.
You can read the published study in volume 25 of the 1973 Quarterly Journal of Experimental Psychology.
Our technical and scientific (including the engineers) folk can now see why it is useful to share stories, know it’s more than just personal stories and can see the importance of sharing experiments as stories. Let’s bring all this together for the practical application of presenting your product or service to customers.
Before my storytelling career I worked for Oracle as a technical sales person. We called it presales back then. My job was to present our products’ technical capabilities. It was 1988. Oracle version 6 was released in July. My job was to educate our customers and get them excited about the new version.
If I was to advise my 24-year-old self about a story approach to presenting Oracle 6 this is what I would say.
Start your presentation with a short anecdote on why you care about databases and the good they can create, especially if it’s high quality. I might have told the story about using Oracle as a research assistant at the Australian National University and how we managed a multi-census analysis of coal towns in Australia. We could rely on it. Back then Oracle was good for analysis but was getting its butt kicked on online transaction processing (OLTP) by Sybase. This new version was designed for OLTP.
This first story is a connection story designed to help the audience get to know me and what makes me tick. I care about quality and getting real work done, but I know we couldn’t do the heavy lifting of OLTP.
I would follow that with the big story. I call it a clarity story. It explains why someone should take action. In this case why should they invest in Oracle 6. The clarity story has a simple structure that is explained fully in my book:
In the past …
Then something happened …
So now …
In the future …
Here’s what that might sound like for the Oracle 6 example:
In the past online transaction processing was done by mainframes that were designed for high throughput work. Relational databases like Oracle were invented to analyse data from these systems. Our simple table structures really helped people understand the information and gain insights.
But then something happened. Relational databases using client-server approaches started to be used instead of mainframes. They were more user friendly, easier to maintain and cost substantially less than mainframes. As a result, transaction loads shot up with the popularity and relational databases were struggling to keep up.
So now we have brought in Oracle 6. Oracle 6 is focussed entirely on high transaction scenarios such as banking and airline booking systems, which were once only served by mainframe systems, but without losing our analysis capabilities.
So, in the future we see much more user-friendly systems being developed that can handle lightning fast transaction speeds. Your employees won’t need to learn esoteric keyboard commands and instead will enter and retrieve information from intuitive online forms. Development times will drop, user satisfaction will soar and your ability to respond to new business needs with be unparalleled.
With the big picture set we can now delve into the details. People need the gist before the details.
For each new feature I would briefly describe it then tell a story of how it would affect an end user. It is even better if the story is about the customer’s customer.
Take one of the features of Oracle 6, row-level locking. Now this wouldn’t mean much to a business person so I would need to tell a story about what can happen if you don’t have it. It might be something like this …
Row-level locking not only speeds up transactions but saves everyone from embarrassment. Imagine what can happen without row-level locking. An important customer comes to the bank to transfer significant funds into an investment account. A transfer is essentially a delete from one account followed by an update of another. Imagine that after the delete, another user updates the information you are trying to change and the two transactions get confused and the wrong amount is transferred. It’s unacceptable. In the past to avoid this problem, we would lock entire pages of memory containing hundreds of rows. This just slowed everything down. With row-level locking we lock just one row and it speeds everything up and ensures the integrity of the transaction.
For each major feature use this point-followed-by-story approach.
To finish, share some future stories that illustrate what the world will be like with the new system. Start with the line, “Imagine this …” and then tell a specific scenario of how people use it and how they feel as a result. You might finish with three “Imagine this …” scenarios.
That’s your presentation.
And, when you answer questions, make your point and then illustrate it with a story.
Technical people tell stories as much as anyone else. Once they realise that then they just want some very practical ways to find and share their stories. And technical people, like the rest of us, value experience. Storytelling is just a way to share experience to make a business point.
About Shawn Callahan
Shawn, author of Putting Stories to Work, is one of the world's leading business storytelling consultants. He helps executive teams find and tell the story of their strategy. When he is not working on strategy communication, Shawn is helping leaders find and tell business stories to engage, to influence and to inspire. Shawn works with Global 1000 companies including Shell, IBM, SAP, Bayer, Microsoft & Danone. Connect with Shawn on:
Send this to a friend