Analogical storytelling approach to technical communication barriers

Data technologists are often challenged with effectively communicating complex technical information to the non-technical side of the business to gain approval for the funding, the resources, the priorities, or all the above for any given data strategy.

This situation is common practice, but being able to conceptually explain the strategy is where good storytelling comes into play. To better elaborate, consider the following story.

Suppose you are in the year 300 BC and you need to create a way to collect, store and organize data. How do you do it? Well as a first step, you'll likely learn the language used to communicate and gather information, particularly in its written format. With this knowledge in hand, you’ll be ready to start writing. To accomplish this, you’ll acquire some papyrus or parchment and some ink (made from the local materials available) and begin recording information. When you run out of page space on one page, you'll start to create more pages. When the number of pages gets large enough that it becomes difficult to find a particular page quickly, you’ll give each page a mark or a number to make it easier and faster to access the information you want. And when the amount of marked or numbered pages becomes too cumbersome to balance on your lap or to spread out on a table, you’ll create a book by binding the pages together.

As you create and acquire books, you find that you have to start organizing books by subject to make it easier to store and retrieve. The math information goes in the math book, and the math book is placed with other math books. Likewise, the biology information is placed in the biology book, the geography in the geography book, and so on. When you have amassed too many books to put on the table or the floor, you’ll build a bookshelf to hold them all. When you run out of bookshelf space, you’ll build another bookshelf to hold all of your books. As the number of books you’ve acquired increases, you begin to organize them by sub-topics within subjects to make them easier to locate and access.

Up to this point you’ve done an effective job of organizing your two bookshelves worth of books – so far so good. But what happens when you have a hundred bookshelves full of books? As the number of similar subjects grows, organizing simply by subject and even sub-topic within the subject is difficult, so you decide to organize not only by subject but also by author. However, at one hundred bookcases and growing, it can still take a while to locate a specific book, so what do you do? You decide to number each of the one hundred bookshelves and create a separate filing system that tells you which book is on which shelf. To help further, you also label the individual shelves so that your filing system includes not only the bookshelf number but also the individual shelf any book is on. You could expand your filing further and maybe add a different filing system that tells you where books are by genre. Or maybe reading level. Or whatever other organization you can come up with so long as it makes the task of locating the information you want as efficient and effective as it can be. Congratulations are now in order, as you’ve become one of the creators The Library of Alexandria c. 300 BC—and your data is stored and easy to find.

If you followed that story you now have a basic understanding of a simple data strategy along with the rationale for why it was required, and some of the insights surrounding the intuition behind why it was built the way it was built.

To connect this back to modern software, think of the Book as the data entity or record, the Bookshelf as the data structure representing and storing the data (an array or a list maybe), the collection of bookshelves as representing your Database, and the filing system as the Database Index. We can expand this analogy even further to say that in your library you can check out a book so that someone cannot change it while you're reading it, or that two people cannot change it at the same time. And, as your library grows it will require regular updates. For example, if you add a new book to your library, your filing system needs to be updated to record all of the particulars of the new book. That will protect against the complications of running out of shelf space and having to move all of the books—the filing system will remain accurate.

In my experience, a quality storytelling approach has proven to be an effective way to convey the technical ideas involved and to get some interesting discussions going as a byproduct. By telling a non-technical but relatable story, a technologist can help explain what data is and how it's generated, as well as what it means to create a data strategy and why it's both necessary and important.

And while it might not come naturally to many technologists, the happy fact is that stories and storytelling is a part of who we all are, the technical and non-technical alike. It's a part of human history and the human experience, uniquely so in fact, and as such provides an instantly recognizable format. Of course, if it were as simple as it sounded everybody would do it. The truth is that like anything else it requires practice and persistence, but once mastered, storytelling can provide huge dividends in communications and relationship building. The other requirement is finding the right story for the right technical concepts presented, which also requires practice and persistence.

The introductory story takes between five and ten minutes to tell. The overall idea is that the story represents a relatively succinct and relatable way for understanding something very complex—essentially giving non-technical listeners the conceptual building blocks to help understand complex problems. This method of formulating a creative analogy for a technical problem is foundational to any successful consulting career. It is a shockingly successful way of getting buy-in from business users by helping them understand a topic to the level that a new developer would, for example, without the explicit understanding of the underlying technical details.

The art of analogical storytelling accomplishes a few things: first and foremost it captures the audience’s attention - everyone likes to hear a story. Second, it uses a common and easily understood format that can be visualized by each listener, increasing the possibility of retention and understanding. And finally, it can be seamlessly connected back to its technical counterpart.

Good stories are worth their weight in gold, and like any other skill, it is something that requires practice and forethought. So the next time you're struggling to explain something to someone, try telling a story.

By Mohammed Hussain, X by 2

© Copyright ASC COMMUNICATIONS 2020. Interested in LINKING to or REPRINTING this content? View our policies by clicking here.


Featured Content

Featured Webinars

Featured Whitepapers