When communicating, you want to enable your audience to see possibilities and solutions and their part in them. No more so than when speaking with the engineers on your product team.
If you want your team (not just your customers) to believe in your product and its promise, you have to share stories that invite trust and tangibly illustrate what they can believe. Unlike data alone, stories provide crucial context, enabling us to create meaning out of complexity and confusion.
Stories bridge the rational and the emotional. So, when you are communicating with your engineering team, you don’t have to choose between story or evidence. By applying story, you can support both your engineer’s logical thinking and their need for empathetic and social engagement with the team.
Stories unfold logically: beginning, middle, and end; cause and effect. Stories will help your engineers focus on the connections between information. So, sharing a short story that reflects those patterns serves to reinforce logical, patterned thinking.
Not only are stories actually logical frameworks and presentations of information, they also enable you to share otherwise seemingly unsayable emotional content. No matter how dispassionate your engineers (or your customers) may pretend to be, they react to and make decisions about your product with their emotions in play. Even small emotions, such as excitement, commitment, and passion, can be big behavioural motivators.
Tips for Sharing Stories with Engineers
Bear in mind that it is important that you share a story that makes sense to you. Share a story that helps you find the pattern and logic in the otherwise disconnected data. Share the story that allows you to store that pattern in a more compact way that makes sense.
Think, too about both the real and fictional characters that are held in high esteem by your engineering team. You can share actual stories you’ve heard about these real-life heroes and idols that support your evidence. And, you can ask your engineers to imagine fictional characters – such as those from movies and TV shows – as the protagonists in your product stories.
Also consider presenting your data and evidence in expository (no bullets or charts) format:
“Research indicates that an individual reading an article written in narrative style will be done in half the time and learns twice as much as someone reading the same information presented in an article using a more logic-based style.”
This is because a story allows the audience to sit back and more easily process understanding of the connections you have already made for them. You’re not asking them to work extra hard to make sense of disconnected data points. You have already made the connections and are generously offering a memorable and short synthesis.
Of course, you should provide data and evidence when communicating with your engineers. And you should illustrate the genesis and impact of your evidence through story. In this way, stories will further understanding among your team.