Creating Sticky Ideas Through Storytelling

It’s not enough to have a “good” idea; you have to have one that “sticks.”

“By ‘stick’ we mean that your ideas are understood and remembered, and have a lasting impact—they change your audience’s opinions or behavior.”¹ (Heath, 2007).

In the mid-1990s, I managed an enterprise data model project for an apparel company. This initiative had a checkered history of complex technical solutions and limited implementation support. Our primary success criteria was, therefore, garnering management support and funding for implementation.

The team struggled with how to generate enthusiasm for something as inherently uninteresting to business managers as data models. We asked managers in product and functional departments about their problems. We then traced a subset of those problems to data—old systems, multiple data bases, inconsistent schemas. One example story was about a retail customer that received 34 invoices—every month! The final project report contained two sections—a business section that told 30+ stories and then a technical section. The sheer number of stories and diversity of departments impacted created an emotional connection to the problem for the managers. The data became real to them and follow on projects received support and funding. Good stories have the potential to spark action.

In the agile community we talk about collaboration, self-organizing teams, cross-functional teams and adaptive leadership. In these highly collaborative environments getting things done depends more on influence than power. To influence others you need sticky ideas that get others to act. Whether you are trying to influence a customer to buy or a colleague to accept your design idea—having a good idea isn’t enough.

“A credible idea makes people believe. An emotional idea makes people care. The right story makes people act.” (Heath, 2007)

Consider the Agile Manifesto, sited frequently as a pretty good idea that has been sticking around for years. One of the values articulated is “working software over comprehensive documentation.” What makes this idea sticky?

First, it’s simple but not simplistic. It conveys a complex idea in simple, direct language. It is generative in that it guides actions while not being prescriptive.

Second, in its day it provided an unexpected message. Until then the primary message from methodology mavens was that architecture, requirements, and design counted, but coding just needed to follow blueprints.

Third, the statement is concrete—anyone in the software business immediately understands what “working software” means.

Forth, it was credible as a number of the manifesto authors were recognized in the industry.

Fifth, especially for developers and IT staff who were tired of problems with traditional methods—it carried an emotional component.

Finally, stories—good stories—encourage people to act, to change their behavior, to initiate improvements. The “story” of the manifesto’s writing at Utah’s Snowbird ski resort has been widely shared. Stories of failed projects are often the catalyst for trying agile methods.

We often get tangled up in technology and methodology—facts and figures, analysis and concepts. But our best ideas, be they technical practices or product ideas, are often neglected because we have failed to engage others. How often have you been numbed into naps by a PowerPoint presentation containing streams of bullet points of data? Getting people to remember and act on your ideas—requires more—it requires stories that engage emotions as well as intellect. It takes well-crafted stories of people, places, time, and obstacles overcome. Crafting sticky stories takes time, but it’s time well spent.