Stories are second nature to humans. Somehow, stories in work life were pushed into the corner by supposedly scientific models and “objective” data. By rediscovering the power of Story Telling and working with it in companies and teams, we can help transcending boundaries in companies enforced by silos and hierarchies and finally improve understanding and collaboration in every day work.
Stories Have Always Worked
When you think about it, the concept of a novel is really strange. Some 80.000 or 330.000 words, a few hundred pages of written language. That’s not even a MB of information. Storing that information costs roughly 0,00003 EUR. Even if I did a miscalculation and the cost would be ten or hundred times that, it simply wouldn’t matter. Even if the novel comes with lots of fancy pictures, the information density is still low. That are the facts.
But what a good novel does to us it quite different from what the numbers say. If the novel is really captivating, this little piece of information allows us to go through deep emotions and thoughts, live with people, enter a different world, become someone different. Until we put the book down, back to its little place next to our bed or sofa and we wake up, emerging back into our real world.
Something strange is happening and we don’t quite know how and why this is possible, but to a degree we can all do it. This is the power of Story Telling. A power that we somehow developed during evolution. It helps us tell and understand complex context information without telling everything. It allows us ask questions for gaps that still exist in our understanding and the other side filling exactly those gaps.
Something funny is going on, when good novels are being made movies. The movies make the content of the novel more concrete. And what often happens is that the result of making things more concrete is disappointing. Directors have huge respect when having to make a movie out of a novel. They know that they compete with every individuals optimized understanding of the novel. And that’s tough competition. As we all are quite good in filling the gaps. Humans are Story Telling and understanding machines by nature. And if we know this, we can work with this capability.
There seems to be a ‘reason’ in evolution for Story Telling to emerge – and I guess it is enabling collaboration in groups. There are simply things weher it helps to be more than one person. Having the same understanding about a thing in context enables us to come together and to part away while working on the same thing. If we don’t have common understanding, collaborating on anything is hard, not fun and in the end prone to failure.
Netflix & The Industrialisation Of Story Telling
I guess one of the more advanced approaches and uses of Story Telling emerged in the film industry. The explosion of TV content, especially TV series, is enabled by advanced collaboration techniques around Story Telling.
We often complain how hard it is to write good software. Software is a seemingly volatile thing. Customers want different things all the time. They don’t even know what they want. But if you ask them, they will tell you something about it. If you take that wish at face value, you will be screwed. (“Had I asked the clients, they would have said ‘faster horses’” as Ford’s saying goes that he actually never made). And so on.
Well, if you think software is hard, think about what all the studios working for Netflix and amazon are doing now. All the time, they are coming up with new content for TV series. Uncounted series, several seasons per series, each season quite a lot of episodes and that week after week after week. And each episode sends you up and down an escalator of feelings. You actually live together with your favorite character, you despise his opponent. You suffer, you hate, you love, you laugh, …
To be able to deliver that amount of content, the concept of the lone genius artist, simply is not enough. An industrialized approach to content creation is required. The answer is the Writers Room. In the Writers Room, the original ‘inventor’ or ‘owner’ – the Show Runner – of the series collaborates with a group of many other writers. The show runner sets the playground for the series, the tone, the main plot, the main characters. But he would be lost in trying to write all the episodes on his own. It would take too long and also he would soon be out of ideas.
There is a sequence of group brain storming (or ideation) and then doing the finer work individually. First, the group works on the bigger twists and turns. Then more details are worked on. When the plot seems mature enough, the group breaks apart and every one is doing his homework by detailing the assigned scenes individually. After that, the team joins again, reviews the material produced, hones edges and does the fine work until the whole circle starts again. It is a fine line of aligning on the bigger plot and just enough details and delegating detailed work to individual story writers. Lots of trust is involved in the delegation. And that trust is only possible by the alignment that is happening in the group before, during ideation. The team is sure that everyone knows the spirit and context of the story.
It is now nearly boring to come up with the parallels to our work. But there are some opportunities I want to point out.
Stories Are Like Lossless Information Compression
The wonder of stories is that they help to encode really complex things such as emotions, values, directions, conflicts and goals in little data. There is a mathematical parallel – the Fourier Transformation. The Fourier Transformation is the basis for de- and encoding relatively complex things such as music in relatively simple and sparse information without losing anything. Without going into detail, Fourier Transformation is the basis of the magic of Shazam, compressed information on how components of substances and much more. Most things that have to do with lossless compression are actually based on Fourier Transformation. To keep things simple, look at the picture below. You don’t have to remember the details on the left. The information to the right is enough and lets you always restore the more complex picture on the left. You really don’t lose anything. And you can switch back and forth between the different representations.
It is the same with stories. We tell stories to explain something really complicated in its context with few words. As described in the example of the novel: 300.000 bytes are enough to create worlds and dimensions in our minds. And then we tell the story differently and change it over generations and still the main content remains the same. Gilgamesh, the Odyssee, Star Wars. From the professional story tellers at Jemaa El Fnaa in Marrakech to your kid on the school yard telling his friend.
Embracing Stories Can Be Hard
Stories have huge opponent in quantitative data. And, to be honest, as powerful as stories are, there is a reason why data came into play. Stories trigger the best in us, but also the worst. The most powerful stories actually triggered wars. Religions are all based on huge collections of stories which can be used to rile people up against each other and result in war. With Enlightenment (Aufklärung) came science and data and objectivity (and vice versa). Which is also a good thing.
The problem is that when objectivity completely supersedes subjectivity, Story Telling is lost and we lose our main tool for communicating complex knowledge. Somehow this happens to society especially in formal environments such as work. And thus subjectivity, opinions, stories and so on are looked at as inferior to objectivity and data. (Although with power comes freedom to be really opinionated and subjective, it just does not really help without power: “Stop being so emotional about it, let’s come to the facts! Be professional!”
As a result, whenever Story Telling is used in companies, most of the people get suspicious about the emotions, subjectivity and possibly fun involved. In fact when Story Telling is happening in my workshops, it often starts of really facts-based and generalized and thus a bit dry rather than engaging. People have to first get used again to conveying opinions and emotions in a formal context. It is hard to get people back to a place where emotions dominate stories.
Hint: If you need to encourage Story Telling, make it apparent and explicit. Set the stage and model the behaviour as a facilitator.
The problem with that duality is that we think that we are a rational being while in reality we are mainly emotionally driven. Huge parts of our behaviour are still an emotional animal listening to our reptile brains. The number of decisions we take rationally is minimal compared to the number of the decisions we takle by instinct. Also, the influence of emotions and biases on our interpretation is really well known. But still, we think we are rational beings. Especially the industry that I am part of is still dominated by the belief that it is a) possible and b) best to be rational at nearly all times, especially business. And don’t get me wrong: I am not against data and objectivity. We just have to know about the full picture and the other side as well and find the balance.
In the late 20th century, a new enemy to stories emerged. The (absolutely revolutionary, necessary, well intended) idea of scientific management was invented by Frederic Winslow Taylor. The task at hand at the time was industrialization of manual (not knowledge) work. The main problem at the time was the lack of wide spread education. There were few people with lots of knowledge and lots of people with little knowledge. The idea, following from this, was to divide labor between thinking and doing. And this was how division of labor and the idea of efficiency were industrialized. The art of the time was to divide labor into repeatable steps that could be explained without much talking. The ideal would be not having to talk at all. Exchanging a little piece of written information (process, task description) would be great. And this can work in manual labor. Loading or unloading a truck needs little context description. The more people are specialized in their work, the more the context gets to be natural. Efficiency is the cure all in industrialized manual labor.
Sadly, in knowledge work, things are different. To be able to work together as a team, we need a common understanding. We need time to talk, have the same idea of the context, align on problems, then find solutions, build them, and so on. Often, the result of our work is abstract and intangible unlike a loaded truck. And this makes things hard to judge and talk about. Specialization can now actually be in our way rather than help. But most of all, efficiency is now not the only ideal: We can not think arbitrarily fast in good quality. Finding and doing the right thing is now also an important task in a group, not by the lone genius in the corner office. This means, we need time to align to get a common understanding. And we know the tool: Sharing stories. Which can finally lead to effectiveness – doing the right thing.
What Hollywood has already understood: Collective Story Telling as the basis for productivity in knowledge work is something our industry only starts to understand. Stories are the glue in abstract knowledge work. And the metaphor of the Writers Room is much more helpful than the metaphor of the linear production line.
All I am saying until here is: Stories are useful. We should use them. But they have natural (equally important) enemies, which go by the name of data, objectivity and efficiency.
Let’s look at some areas where Story Telling can help us.
Stories Help Crossing Boundaries In Companies
Somehow humans create hierarchical systems. And division of labor added specialisation and silos to that. We end up having several dimensions of separation in companies. I want to make a point of not judging this. I have no objection against hierarchies. I observe that most people see hierarchies as something natural and useful. Also, I see people actually suffering when hierarchies get destroyed. I am fine with hierarchies. Silos also are natural – they can give us meaning and a feeling of being good in something special.
Still, hierarchies bring vertical separation to companies and silos add horizontal separation to that. To create anything valuable for our clients, we often need people on several levels of the hierarchy and several “departments” (or silos). Because, now no hierarchical level on its own and no department can deliver anything meaningful to our clients. A database engineer, even while working himself tired, can not deliver value to the client all by his own. Neither can the CEO. It is not a question of power or position. We need collaboration (or interaction as the systems thinker would say) between the most different parts of our company.
Whether this interaction is done in “cross functional co-located teams” or by virtual teams, heading back to their departments, any interaction requires common understanding. Which, again, can be generated by Story Telling about the thing we want to deliver. How will it be used, in which context, who is the customer, and so on. What does life look like with the thing in the customers’ hands?
One of the main applications for Story Telling is helping to communicate purpose, vision and strategy in hierarchies.
When I give a talk on strategy, I often ask my audience “Who of you can explain her companies’ strategy to us?”. In an audience of 200 people, a few hands, let’s say 2-4, go up. I guess some people are shy and 10 to 20 would actually be able to explain their companies’ strategy. That is still a lousy 5-10 percent of all people. That is still not a lot. Now you could think “all managers are idiots and don’t explain the strategy to their employees.” OK, so I go off and ask managers about why they don’t explain their strategy to their employees. Guess what! Talking to them, the complaint goes the other way: “I explain the strategy like 10 to 20 times a year, we have all hands, newsletters, off sites, you name it. I don’t know why nobody is listening.”
So, what’s going on? My observation is threefold:
- There is no Story Telling, of course. What is told is just a repetition of dry facts, numbers and directions, goals and KPIs. None of that is engaging but purely rational. Here a real life story: Just a couple of weeks ago the top manager of a several hundred employee site of a global company told me about the road show, the company board did. While they went for huge efforts, what they did was giving a presentation of facts and numbers. He was so disappointed! He pointed this out before. And he prepared something different but wasn’t allowed to go for it. The moment the presentation started and numbers and facts started, the morale of his local team went straight to the basement. What made him sad was the missed opportunity to really communicate and make sense and engage. Who hasn’t been there!?
- There are huge gaps in what is told as strategy. What is being told is a factual compression of really complex content and content. Bu there are gaps due to the blind spots of those explaining the strategy. As Adam Grant describes it in his book “Originals”, it is like “knocking a song rather than singing or playing it.” It’s just the rhythm of a melody in mind, but leaving out the actual notes. It is leaving the distinguishable piece out of the Gestalt.
- There is no translation from the level of the CEO to any other level in the company. This leaves the strategy as a riddle to be solved, rather than self explaining and actionable.
So, how could Story Telling help here?
Once we tell the strategy as an engaging story, it could overcome the three problems like this:
1) Engagement can, of course, be reached by telling the strategy as a story. A story is always about a tension between a situation and the forces upon it. Just like on our company content. We have a status quo, external forces and that’s why we came up with things to do in our strategy. We just need to find some metaphors and people will remember where we come from and where we want to go to. Again: A good story may be remembered. Data, not so much.
2) The gaps exist, because the CEO is working on that strategy (well, nearly) every day. The level of abstraction on which the strategy works for him is extremely high. It’s like that old mathematicians joke where one mathematician says to the other “Let epsilon be smaller 0″ and the other ones starts laughing. It’s highly abstract code, well understood inside that tribe. But not at all outside the tribe. Language and stories can have the purpose of excluding. Just like my kids tell their own stories to exclude and us parents to become independent individuals. But to include, we need to tell stories that share context and are easily understood. What is the CEOs pride to able to think on that level, leaves the task to the employee to decode it again. Without context, the decoding will probably be a) wrong and b) differently wrong for every employee. The blind spots and gaps created in abstractions have to be filled again with stories.
3) As my friend Jabe Bloom says in this video, you can imagine a company as different layers of stories. The people producing cups or code are dealing with stories spanning 2-3 days, maybe 2 weeks. Middle management is dealing with stories spanning probably 2-3 months (the next release, marketing event, …). The CEO is dealing with stories spanning a few years (revenue increase YoY, the next shareholder meeting, the next promotion cycle …) . To walk into one direction and to create meaning and understanding, these levels of stories need to be translated ind interlinked. Just independently telling them does not help. An exchange of these stories must repeatedly happen to create understanding. That means, creating strategy is not about telling, but about telling, listening and adjusting. This is how Story Telling works and companies better get good at it. I will talk about tools later in this article.
Working On Products And Campaigns
As I said before, it is very likely that to deliver something meaningful and valuable to a client, we need several different parts of our company. That means we need some way of collaboration across functions, boundaries and capabilities. As each of these has a high level of culture and view on things. To be able to collaborate, first we need an aligned view of the thing we are doing, who will use it, and how it should improve the clients life. Again, Story Telling is the ideal vehicle. Once we have created the aligned view, we can work together on the same thing. Either in the same room or distributed.
What is often happening is that we do not create the shared understanding first (and frankly, often we don’t even have the patience). Instead we shortly meet, divide labor and start working right away.
The risk, of course is on many levels: The idea of the product might be very limited and, again, made up by a lone genius. The division of labor is made up by a different lone genius (project manager?). The understanding of the individual tasks is now without context. That leaves people working on the tasks without context and without the ability to think together with the rest of the “team”.
To name a positive exception, Marketing since ages knows about the power of Story Telling. Marketing is obsessed with explain customers a possible future with a product. Rather than explaining facts of a product, Marketing tells a story of your life with the product. Read Claude C. Hopkins’ classic “Scientific Advertising” for some gems. Claude Hopkins is responsible for making people drink orange juice by marketing Sunkist and popularising brushing teeth by marketing Pepsodent at the times.
Without going to deep into tools, I’d like to talk about User Stories and User Story Mapping. These are essential tools for aligning groups of people through Story Telling.
User stories, so the story goes, were first mentioned by Kent Beck in “Extreme Programming explained” as the tool for talking about a new system to be built. User Stories are not the specification of a system. They are the tool for getting an idea what the system should enable people to do. The , probably more esoteric sounding, but helpful, idea behind them (and I heard this somewhere but do not know where) is that you listen to what users would like to do, express that in User Stories. And then you try to build a system that enables users to experience these stories. (Specification was done in CRC cards).
Coming from here, as Ron Jeffries defined, User stories have the famous and counter intuitive 3C properties:
- Card: A User Story fits on an index card. That means it will by definition be ambiguous and incomplete. The brevity of the story forces us to have the second C:
- Conversation: As we know, the context of our story and our system is complex, we know we need to have a conversation about it. So we will. You might live in an environment where people tell you that your user story is not ready for sprint because it is not detailed enough. You see – we have a problem here. It is not intended to be detailed, complete and clear. It is intended to be short and incomplete to trigger a conversation. We will not work on anything without having had the conversation, where the real story will be told. The card is just t trigger to tell the story. And we will tell the story because we know that without the story being told, no one can do meaningful work. This is no efficient and it is not meant to be. Because we know we can not work without information on the context, we defined a format that forces us to talk.
- Confirmation: After coming to a common understanding of the story and its outcome, we will wright some key insights of that common understanding on the back of the card. Later this became “acceptance criteria”. I hope you see how this is different. Acceptance criteria are more technical terms and probably closer to the intention of CRC cards.
User Stories help us to get a common understanding of what a system will offer. When we work on something bigger, the user story might become huge or take really long to work on. In that case, User Story Mapping comes in handy.
User Story Mapping
User Story Mapping was defined by Jeff Patton and you can listen to some of the story and understanding of it from Jeff Patton in this podcast I recorded with him last last year.
User Story Mapping is just a tool to tell a story in a group. It is not a specification technique or a process modelling tool or something that defines an architecture. Let’s say you have a bigger new system to build. Then that might be a bigger story to tell about the system.
What you do in Story Mapping is that first, you tell the main story line as the upper line of your map. Let’s take the example of building a wine store for the web. Here is the main story line:
- Customer discovers store
- Customer discovers products
- Customer is interested in certain wine
- Customer selects wine
- Customer buys wine
The image shows the first 4 parts of the story in the “skeleton”, the upper horizontal line:
In the next step, you fill each step of this still very very vague and general story with details and specifics. Just some examples
“Customer gets recommendation from store (employee) – the employee has very good knowledge about wine and with a few questions he can direct the client to a very narrow section of wines. “
“Customer keeps some wines on a small table. This is the short list of wines he is interested in. He might try them.”
As you see, these are real stories. They don’t happen in an internet store, yet. I would lose information and context. I am not coming from the direction of the solution. I am not coming from the direction of “this will be a Magento implementation”. I am still trying to think from a real life experience. This leaves me the option to think about “how could I make my internet wine store something special? How could I make recommendation something close to real experts? How could I simulate tasting wine (getting the best, detailed information possible?”
This is done with potentially a big team in a room as a discussion. Questions will be asked and answered, The whole map changes quite a bit over time. It is a dynamic process. We are done, when everyone has a good understanding of what the system should enable customers to do. The test is “could everyone in the room now tell the story and would it be the same?” Then, finally, we can think about how to build it.
Then we can also bring constraints in: How far do we get in two months? Is finding wine more important than getting recommendations? Which parts of the story will still be supported? Is it then still a consistent, coherent story?
With the whole context being well shared, everyone can contribute to this being the best wine shopping experience rather than blindly building anonymous feature by anonymous feature.
There are few formal quality criteria to a Story Map. The main one is that the team has a common understanding and alignment of what they are up to build.
We know that humans can work with stories and that stories are a very good tool for sharing complex content and context. We can exploit that by introducing forms of collective Story Telling to give meaning and to enable teams to collectively work on really abstract things. All we need is a little time and space carved out of the daily grind. the techniques themselves are not too complicated.
The metaphor of the Writers Room will often be more helpful in knowledge work than the metaphor of a production line. You can get a hint on how close the work is by comparing the structure of a User Story Map with what is often used in the Writers Room.
Give it a try!
Christian Riedel - a professional story teller friend of mine
A podcast episode by Christian Riedel and me on Story Telling