The number Paul Critchley led with comes from research on how human memory actually works. People are 22 times more likely to remember a fact or piece of data when it's wrapped inside a story than when it's presented as a standalone number or claim.
That number is the entire argument of the session in one statistic. Continuous improvement practitioners — engineers by training in many cases, including Paul — tend to default to data when communicating results. The data is real. The improvements are measurable. The case for change is empirically sound. And yet adoption stalls. Engagement plateaus. Frontline staff don't internalize why the change matters. Executives nod through the dashboard review and don't follow up. The disconnect between strong data and weak adoption is one of the most persistent frustrations in the field, and Paul's argument is that the disconnect has a recognizable cause.
Data informs. Stories inspire. Metrics explain what happened. Stories explain why it matters. Organizations don't struggle with continuous improvement because they lack data. They struggle because people don't emotionally connect to the change. Storytelling closes that gap.
What Paul did across the session is walk through how to build that storytelling capability deliberately — a seven-step framework for crafting and delivering improvement stories, anchored by a historical example most CI practitioners haven't heard before, and finished with a live demonstration that made his point through the audience's own experience rather than telling them about it.
Paul Critchley is the President and Lead Consultant of New England Lean Consulting, a firm he founded in 2012. He has over 20 years of experience in organizational leadership and is recognized as a thought leader on using employee engagement and continuous improvement to improve business results. He is a former Board Member of the Northeast Region of the Association for Manufacturing Excellence and a supporter of several civic organizations throughout New England. He is passionate about Lean and creating organizational cultures that are sustainably engaged. He co-authored his first book, "The Whole Professional," which offers a perspective on work/life balance and how individuals and organizations can work together toward greater attainment for all.
Paul holds a B.S. in Mechanical Engineering from Clarkson University, an M.S. in Management from Rensselaer Polytechnic Institute, and an M.S. in Organizational Leadership from Quinnipiac University. He also holds U.S. Patent 5,927,868. And, as audiences who watched the original broadcast of season five may recall, he has been on Shark Tank — a story he told during the session for reasons that became clear by the end.
Paul opened with a personal story about being on Shark Tank. The setup: he runs obstacle course races and has for over a decade. One of the races he runs is Rugged Maniac, owned at the time by Rugged Races out of Boston. The two owners, Rob Dickens and Brad Scudder, went on Shark Tank in season five and struck a deal with Mark Cuban. Their company grew substantially after the appearance.
Paul had previously gotten to know Rob and Brad because he had run laps of the Rugged Maniac race for charity at a time when laps weren't officially allowed. He had to sign a waiver acknowledging that injuries would be on him. After Rob and Brad's deal with Mark Cuban, Shark Tank sent a film crew to Southwick, Massachusetts — Rugged Maniac's first venue — to film an update segment. Paul happened to be running in the wave that was filmed. That's how he ended up on Shark Tank, for roughly two and a half seconds.
The story is a great bar story. Paul uses it constantly. It drives his kids crazy. People who hear it assume he was pitching a product, which wasn't quite true, but the technical fact remains that he was on the show.
Why he told it: he was setting up the framework he was about to walk through. The way he opened the session — with a story that had nothing directly to do with continuous improvement — was itself the demonstration of the principle he was about to teach. He'd return to it at the end of the session, in a way audience members would only fully understand after they'd been through the rest of the material.
Paul's framing of the case for storytelling started with a Gallup statistic he found troubling. In a recent survey, only 40 percent of US employees marked that they strongly agreed their supervisor or anyone at work cared about them as a person. Fewer than half. Paul's response: if that number doubled to 80 percent, it wouldn't be a big ask, given how much of work satisfaction comes from the people you work with. But the current state is what it is, and it has implications for how continuous improvement work needs to happen.
Storytelling requires trust. Walking into a new client and immediately proposing a kaizen event, a heijunka board, PDCA cycles — it's too much, too fast, from someone the team has just met. To people in operations who've seen consultants come and go, the new CI practitioner gets viewed as one of "the Bobs" from Office Space. The work can't start there. Relationships have to be built first, and storytelling is one of the most direct ways to build them.
Paul quoted Kevin Hancock, CEO of Hancock Lumber in Maine — one of the oldest family-owned companies in the United States, currently in its seventh generation, dating to 1848. Hancock's framing: "Our employees are number one. Customers are a wicked close second." That order matters. When employees are genuinely engaged and trust that leadership cares about them, they take care of the customer-facing work, the operational metrics, the KPIs — all the things that organizations chase directly often arrive as byproducts when the employee engagement is real. Storytelling is part of how that engagement gets built.
The other case for storytelling Paul made repeatedly is that Lean's value proposition extends beyond cost and quality improvements. Lean done well lowers employee frustration. Reducing the friction in someone's daily work — the things that bug them, the workarounds they've built up, the steps that don't make sense — is its own form of respect for people. Storytelling is how you communicate that you actually understand what people are dealing with, rather than presenting a generic improvement methodology that could apply to anyone anywhere.
Paul introduced Gustav Freytag's framework for story structure — a German playwright and novelist from the 1800s whose pyramid model has been taught in middle school English classes ever since.
The structure has five movements. Setting the scene establishes where things stand at the start. Rising tension introduces the problem or conflict that needs to be addressed. Climax is the moment of crisis or decision. Falling action is what happens after the climax — Paul translated this to Lean terms as the question of whether the change is going to stick or not, the sustainability test. Resolution is when the change becomes part of the organization's DNA, included in standard work, internalized by everyone.
The parallel to PDCA is direct. The current state. The problem that emerges. The improvement work. The testing of whether the change holds. The integration of the change into how the organization operates. Anyone who has been in CI for a while will feel the shape of Freytag's pyramid in their own improvement work, even without having seen the framework before.
Paul devoted substantial time to a historical example most CI practitioners haven't heard, and the reason for including it landed harder than any abstract argument about storytelling could have.
The setup: Vienna, 1823. Roughly one percent of women giving birth at the Vienna General Hospital died from what was then called "childbed fever" or "puerperal fever." Then, halfway through 1823, the rate spiked dramatically — to somewhere between 10 and 30 percent depending on the month. In 2022 terms, a one-in-three chance of dying when going to the hospital to give birth is unimaginable. In 1823 it was reality.
The chart Paul showed displayed monthly mortality rates from January 1841 forward — almost 20 years after the spike began. The rate was wildly variable. Months would drop near zero and then jump above 30 percent. The highest single month, in late 1842, hit around 32 percent. Paul's read of the chart: hospital administrators got everyone's attention when the worst months hit, which is what produced the subsequent month-over-month drops. But the volatility never stabilized. People hid problems. Reporting was inconsistent. The variation continued. For 20 years.
A lot of smart people had been working on the problem.
Then in late 1846, Ignaz Semmelweis took a position at the Vienna hospital. His boss showed him the data and gave him an assignment: figure this out. Within three or four months, Semmelweis had it.
The hospital had two maternity clinics. One was staffed by doctors. One was staffed by midwives. In 1823 — exactly when the mortality spike began — the hospital had introduced a change: doctors were now required to spend time in the morgue performing dissections to learn more about anatomy. The midwives had no such requirement. For 23 years, no one had connected the dissection duty in the morgue with the maternity work in the clinic. Doctors were going directly from cadavers to assisting births, without washing their hands. The infections that killed the women were being carried by the doctors themselves.
Semmelweis introduced a hand-washing protocol with a chlorine-based solution. The mortality rate at the doctors' clinic dropped dramatically. The chart Paul showed displayed the red line of the post-protocol data — substantially lower, more stable, and obviously distinct from the pre-protocol baseline.
What should have followed was a Eureka moment. Hand-washing protocols spreading across European hospitals. Recognition for Semmelweis. The end of childbed fever as a major killer.
What actually happened was the opposite. The Vienna medical establishment didn't accept Semmelweis's findings. He was shunned. A smear campaign followed. The doctors who had been working in the morgue and then in the maternity ward had a substantial professional interest in not accepting the conclusion that they had been the cause of the deaths for over two decades. Semmelweis lasted a year and a half before leaving Vienna entirely. He couldn't walk through the town because everyone knew who he was and most thought he was a fraud.
In 1865, after years of trying to convince the medical establishment to accept his findings, Semmelweis suffered a nervous breakdown. He was committed to an asylum. He took a beating from the guards. He died two weeks later — from an infection. The same symptom he had identified the cause and prevention for two decades earlier.
Paul's point in telling the story: the data was looking everyone right in the face. The Vienna hospital had the mortality rates. Semmelweis had the controlled comparison between the doctors' clinic and the midwives' clinic. He had the post-protocol data showing the intervention worked. The empirical case was as clear as any case has ever been in medical history. And the data, by itself, wasn't enough. The medical establishment couldn't hear what the data was telling them because acceptance carried implications they weren't prepared to face.
If the most compelling data in medical history wasn't enough on its own, then the data-first communication strategy that most CI practitioners default to is going to fail in less extreme circumstances too. Stories are how the case gets through.
Paul's framework for crafting and delivering effective improvement stories has seven steps. The framework isn't rigid. The steps overlap in practice. But each one is worth considering separately.
Step one: be genuine and authentic. Use true stories, not fabricated ones. Most audiences can detect manufactured stories from a conference stage. The real stories — including the ones that don't have happy endings — are the ones that land. Vulnerability matters. Telling a story about a time you tried something and it didn't work, and what you learned, builds trust with the audience. The audience is skeptical enough that the rainbows-and-unicorns version of Lean transformation just makes them more skeptical. The honest version makes them listen.
Step two: know your audience. Understand what they're dealing with day to day. What's the problem they're trying to solve? What takes time away from the work they want to be doing? Paul's example: when he walks into a hospital, he doesn't lead with cost reduction. He asks how much time clinicians get to spend with patients and whether they'd like to spend more. Then he asks what gets in the way of that. The framing meets the audience where they are. The stories that follow are stories the audience can connect to because they're about problems the audience recognizes.
Step three: answer the question of why anyone should care. Lean has been around for 30 years in widespread practice. The implementation rates aren't where the field would want them. Part of the reason is that practitioners often haven't worked hard enough to make the work relevant to the specific audience they're trying to engage. Pull from your own history. What have you done, seen, or read that helps this specific person solve the specific problem they're dealing with? Generic Lean evangelism doesn't land. Stories about people who looked like the audience, facing problems the audience faces, who got somewhere worth getting to — those land.
Step four: use descriptive language and visuals. Follow Freytag's structure. Set the scene. Use visuals when you can. The popularity of TikTok and Instagram Reels exists because people respond strongly to visual content. The same principle applies to improvement stories. A photograph of the workplace before and after. A short video of the team running a kaizen. A simple chart that shows the trajectory. The visual reinforces the verbal in ways that text alone can't match. And the ending of the story has to have a point — a moral, a takeaway, the thing the audience should walk away with.
Step five: follow a timeline. Start at the beginning, wherever that is. Don't jump around. Everyone has been at a backyard barbecue where someone started telling a story, got halfway through, and then said "oh wait, I forgot to tell you" — and the audience loses track of where they are. The same thing happens with improvement stories. You know where the story is going. The audience doesn't. You need to lead them through it cleanly. The discipline isn't about rehearsing the story until it sounds scripted. It's about keeping the structure crisp so the audience can follow.
Step six: engage the audience. Words alone get tuning out, particularly in large audiences and virtual sessions. Ask questions. Use polls. Get the audience interacting with the material rather than just receiving it. One caution: when asking questions in large groups, make the answer obvious yes-or-no, or you risk getting a response you weren't expecting that derails you. Paul shared that he's been derailed by audience answers before. The principle is to invite engagement deliberately, not accidentally.
Step seven: deliver the punchline. The punchline doesn't have to be funny. It does have to be meaningful. Bring the story home. Tie back to the origin — what comedians call a callback. "Remember when I said we were going up against this problem? We went from 800 boxes per day to 1200 after the three-day kaizen event." The callback works because not everyone in the audience remembers every detail of the story. Bringing it back around lets the audience see the full arc. The setup, the work, the resolution.
After Paul finished walking through the seven steps, he ran a live demonstration that turned the entire session into its own example.
He asked the audience a series of questions about him.
Where did he go to undergrad? Some answers came back. Cal State Fullerton. UConn. Denison University. The right answer — Clarkson — came up too, but spread across many wrong guesses.
What was his bachelor's degree in? Engineering. Mechanical. Chemical. Industrial. Some right, some wrong.
What were his master's degrees in? Management. Business. Organizational leadership. Various combinations. The actual answers — management from RPI and organizational leadership from Quinnipiac — were guessed in pieces by different audience members.
What year did New England Lean Consulting start? 2012. A few people got that right. Paul had deliberately said "in 2012" rather than "ten years ago" because the specific year is harder to remember than a relative reference.
What TV show was he on? Shark Tank. Almost everyone got that one. Several attendees added "for an obstacle race" or "running a race."
Then Paul revealed what he had done. The opening of the session — the slide where he had walked through his credentials, his degrees, his consulting firm, his year of founding — he had explicitly asked Mark not to introduce him through, because the opening was part of the training. The audience had been the receiver of biographical data: undergrad, masters, year of founding, credentials. The audience remembered fragments. The audience remembered Shark Tank in detail.
The Shark Tank story had been wrapped in narrative. Setting the scene at obstacle course racing. The relationship with the company's founders. The waiver-signing for the unsanctioned laps. The TV crew arriving to film at Southwick. Paul appearing on screen for two and a half seconds. The whole story had structure, tension, resolution, and a punchline. The biographical data had none of that.
The audience proved Paul's central point through their own experience. The story stuck. The data didn't.
Paul apologized for the manipulation, which was good-natured. He had told the audience earlier that he doesn't enjoy walking through his own credentials — that he asks audiences to bear with him because he has to do it for the training. The discomfort was real. The point landed harder because of it.
A series of audience questions surfaced practical concerns about how to tell stories responsibly.
How do you know when you have a good story to tell? Paul's answer: if it's a story you think someone could relate to, it's probably a good story. Not every story needs to end in laughter or tears. The point doesn't have to be a triumph or a tragedy. It just has to be relatable and have a clear lesson. Stories from your own experience as a Lean practitioner are very likely good stories, because most Lean practitioners have faced similar problems and your version of facing those problems will connect with someone in the audience.
What about stories that don't end well? Those are often more valuable than the success stories. Sharing a time you tried something that didn't work, and what you learned, builds trust with the audience in a way that the highlight reel never will.
What about confidentiality? Paul was firm about this. NDAs matter. Confidentiality agreements from prior employers matter. He worked at Pratt and Whitney making jet engine parts for the F-22 Raptor and the Joint Strike Fighter. He's careful with stories from that period because he isn't cut out for federal prison. The principle applies more broadly. Even stories that don't involve classified work can implicate former employers in ways that aren't appropriate to share. When in doubt, ask the people involved before telling a story publicly. When the people involved are still working at the organization, the conversation about whether to tell the story is part of the relationship-building work that makes the storytelling worth doing in the first place.
Mark raised a question about whether stories land harder when told by the client rather than by the consultant or CI lead.
Paul shared an example from a recent training engagement. He had trained roughly 160 people in Lean 101 across a Connecticut company. At the end of the training, he told what he calls the story of Chris and Tony — a story from his own history about a shipping manager who nearly quit because his job had become so frustrating, and how the team eventually fixed the underlying problems. The story is on the New England Lean Consulting blog.
The CEO of the client company had been sitting in on every training class. After Paul told the story, the CEO came to the front of every session and said: "Do you remember when so-and-so and so-and-so used to work here?" Paul's story had a parallel in the client's own history — two employees who had yelled at each other constantly because the underlying work conditions were intolerable. The CEO connecting Paul's story to the company's own history made the lesson immediately concrete. The audience knew the people the CEO was referring to. They had seen the yelling. They understood what Paul had described, because something just like it had happened in their own building.
The principle Mark suggested, which Paul agreed with: in consulting work, the client is always the hero of the story. Not the consultant. The consultant facilitates. The client owns the work and the result. Stories that frame the client as the protagonist who navigated through the challenge — with the consultant providing coaching along the way — produce better engagement than stories that frame the consultant as the savior. Mark referenced the hero's journey framework that drives most successful movies and noted that the same principle applies to internal CI practitioners working with their own teams. Let the team be the hero. The internal practitioner's role in the story will usually emerge naturally, with the team attributing the help they received — and that attribution lands harder than self-promotion ever would.
Mark asked about the trade-off between setting the scene properly and burying the lead. He shared loving feedback from his wife — who is also an engineer — calling out what they refer to as the engineer trap of including too much detail.
Paul's answer was that it's a constant calibration. As a fellow engineer, he tends toward detail. The discipline is to filter for what matters to the story versus what's interesting to you as the teller. A couple to three minutes is a reasonable ballpark for an improvement story. If a detail directly serves the story, include it. If it's just satisfying to share, cut it. The audience won't remember 15 to 20 pieces of data even when they're wrapped in a story. Filter for the data that actually drives the point.
The detail calibration also varies by audience. The same improvement story told to a process improvement conference would be structured differently than the version told to an executive team. Executives often want the punchline first, then the detail. Frontline staff often want to see themselves in the story before they care about the result. Knowing the audience determines the order, the level of detail, and the framing — all from the same underlying story.
A question came in from Alicia about how to read the audience in virtual sessions when you can't see body language.
Paul's honest answer was that it's nearly impossible. He gave an example from recent virtual training he'd done in Massachusetts. Two groups. The first group was engaged — cameras on, microphones on. The second group of seven had five participants with cameras off and microphones muted the entire session. The second group probably wasn't fully present. There's nothing the facilitator can do about that.
The compensating move for virtual sessions is to fall back on stories you know well — the ones you've told before, that you know land, that you can deliver effectively even without feedback. The polish from practice partially substitutes for the inability to read the room. It doesn't fully solve the problem. It does help.
A question came in about whether certain story structures work better than others — bookending with the resolution, leading with leading questions, Socratic patterns.
Paul's answer was the classic consultant answer: it depends. The structure that works depends on the size and composition of the audience, what they came for, how much background they bring. Large audiences and pure-presentation contexts call for more linear delivery. Smaller groups and workshop settings tolerate more interactive Socratic patterns. The principle isn't to find the one right structure. It's to read the situation and pick the structure that fits.
Paul shared his own experimental practice. Mark mentioned he's working on a book of stories from his "My Favorite Mistake" podcast. He used an example: telling a guest's story about losing his first congressional race could either start with the punchline (three-term Congressman Will Hurd lost his first race) and then unpack how and why, or build to the loss as the climax. Both versions work for different reasons. The lead-with-punchline version creates immediate curiosity. The build-to-the-climax version creates emotional investment. Which version fits depends on what the storyteller wants the audience to take away.
The session was about communication rather than infrastructure, which makes the connection to platform tools less direct than in some other webinars in this series. But the connection is real and worth pulling out.
Storytelling at scale depends on having stories worth telling, and having stories worth telling depends on having improvements worth narrating. The 108,000-idea systems that mature CI organizations build aren't just data repositories. They're libraries of stories — the bubble mirrors outside the elevator, the secure-chat replacement for pager-based ECMO activations, the sponsor-night idea from a behavioral health team. Each of those is a story that someone in the organization could tell. Each is a story that demonstrates what the practice of continuous improvement actually produces in concrete, recognizable terms. Infrastructure that captures the work makes the stories available to be told.
The honor roll pattern Cliona Archambeault and Penny Iannelli described at UMass Memorial — selecting a few ideas each month for recognition and broader sharing — is essentially a structured way of choosing which stories the organization tells about itself. The platform holds the raw material. The communications process makes the stories visible. Without the platform, the stories exist only in the heads of the people who participated in them, and they fade as those people move on or forget the details. With the platform, the stories persist, can be searched, and can be retold accurately months or years later.
The vulnerability Paul advocates — telling stories of failures and learning, not just successes — also has an infrastructure dimension. Organizations that only capture success stories teach their workforce to hide failures. Organizations that capture the full range, including the experiments that didn't work, signal that learning is welcomed and that honest narration of what happened is more valuable than curated highlight reels. The platform doesn't make that cultural choice. The leadership does. But the platform supports whichever choice the leadership makes.
The audience calibration Paul described — telling the same improvement story differently to executives versus frontline staff — requires that the underlying record of the improvement is accessible to people who would tell different versions for different audiences. A consultant writing a case study, an executive presenting at a conference, a team lead celebrating their own people in a department meeting — each of these uses needs the same source material. The infrastructure that holds the source material makes the multi-audience storytelling possible.
None of this changes what Paul was teaching. The seven steps are the steps. The discipline of starting with the audience and the trust-building is the discipline. The willingness to be vulnerable and to let the client be the hero of the story is the willingness. What infrastructure does is preserve the raw material of improvement work so that the stories can keep being told, in different versions, to different audiences, for as long as the work matters.
Why are people 22 times more likely to remember a fact wrapped in a story? Because stories engage emotional and narrative processing in the brain, not just the fact-retrieval mechanism. Standalone numbers and claims activate a narrow part of cognitive processing and fade quickly. Stories activate spatial reasoning, emotional resonance, and the brain's pattern-matching for human experience. The combination produces dramatically more durable memory. The 22-times figure comes from research Paul referenced as a foundational data point for the practice of storytelling in any context where retention matters.
Why isn't data enough on its own? The Ignaz Semmelweis example demonstrates the point most starkly. Semmelweis had as clear empirical evidence as has ever existed in medicine — controlled comparison between the doctors' clinic and the midwives' clinic, post-protocol mortality data showing the intervention worked, an obvious causal mechanism in the dissection duty. The Vienna medical establishment rejected his findings anyway, in part because acceptance would have implied that the doctors had been the cause of deaths for two decades. The professional, emotional, and reputational stakes of accepting the data exceeded the evidentiary weight of the data itself. If the most compelling data in medical history wasn't enough on its own, less extreme cases will fail similarly without communication that reaches the audience emotionally as well as empirically.
What are Paul's seven steps for effective improvement storytelling? Be genuine and authentic. Know your audience. Answer the question of why anyone should care. Use descriptive language and visuals. Follow a timeline. Engage the audience. Deliver the punchline. The steps overlap in practice and aren't rigid. The framework provides a checklist for crafting stories that land.
What is Freytag's Pyramid? A five-part story structure articulated by Gustav Freytag, a 19th-century German playwright and novelist. The structure: set the scene, introduce rising tension, reach a climax, follow with falling action, arrive at resolution. The pyramid has been taught in middle school English classes for over a century. The parallel to PDCA in improvement work is direct. Current state, problem emerging, improvement work, sustainability question, integration into standard work.
Should improvement stories always have happy endings? No. Paul argued strongly against this. The stories that build trust most effectively are often the ones that don't end well. Telling a story about a time you tried something that didn't work, and what you learned from it, signals to the audience that you're being honest about the practice. The audience is skeptical enough that perfectly polished success stories make them more skeptical, not less. Vulnerability builds the trust that subsequent successful work needs to take hold.
When should the client tell the story versus the consultant? When the client has a parallel example from their own history or a connection that the audience will recognize, the client should tell it. Paul's example from his Connecticut training: he told a story from his own past about a shipping manager who nearly quit, and the CEO of the client company then connected that story to two employees who used to work at the company and had yelled at each other constantly for the same underlying reasons. The CEO's parallel made the lesson immediately concrete because the audience knew the people he was referring to. When the consultant and the client are both contributing to the storytelling, the effect is stronger than either could produce alone.
Who should be the hero of the story? The client. Not the consultant. Mark referenced the hero's journey framework — the structure that drives most successful films and many successful business stories. In consulting work, the client is always the hero. The consultant facilitates. The team owns the work. The team navigates through the challenges. The consultant's role appears in the story as coaching and support, but the story is about what the team accomplished. The same principle applies for internal CI practitioners working with their own teams. Let the team be the hero. The internal practitioner's role will emerge naturally and lands harder when the team attributes the help they received than when the practitioner promotes their own contribution.
How much detail should a story include? A constant calibration. The discipline is to filter for what serves the story versus what's interesting to the teller. A few minutes is a reasonable target length. If a detail directly serves the point, include it. If it's just satisfying to share, cut it. The audience won't remember 15 to 20 pieces of data even when they're wrapped in a story. Filter for the data that actually drives the lesson. The calibration also varies by audience — executives often want the punchline first, frontline staff often want to see themselves in the story before they care about the result.
How do you read a virtual audience when you can't see body language? You largely can't. Paul was honest that virtual sessions limit feedback substantially. The compensating move is to fall back on stories you know well — the ones you've told before, that you know land, that you can deliver effectively even without feedback. Practice substitutes partially for the inability to read the room. It doesn't fully solve the problem.
Should improvement stories be linear or should they bookend with the resolution? Both can work. The choice depends on the audience, the size of the group, and what the storyteller wants the audience to take away. Leading with the punchline (Mark's Will Hurd example: three-term Congressman lost his first race, here's how) creates immediate curiosity. Building to the climax creates emotional investment. The principle isn't to find the one right structure. It's to read the situation and pick the structure that fits.
What's the relationship between storytelling and trust? Storytelling is a primary mechanism for building trust. The Gallup finding that only 40 percent of US employees strongly agree their supervisor or anyone at work cares about them as a person reveals a trust deficit that affects almost every workplace. Stories — especially honest ones, including ones about mistakes and learning — signal that the storyteller sees the audience as people rather than as targets for change management. The trust that builds across multiple interactions is the foundation that subsequent improvement work depends on.
What did Paul do at the start of the session that he revealed at the end? He had explicitly asked Mark not to introduce him with the standard biographical preamble. Paul presented his own credentials at the start — undergrad, master's degrees, founding year, accomplishments — in flat biographical form. Then he told the Shark Tank story. At the end of the session, he asked the audience to recall the details from the opening. They remembered fragments of the biographical material and almost all of them remembered Shark Tank. The audience experienced his central point through their own retention rather than being told about it. The opening had been the demonstration of why storytelling matters more than data delivery.
.svg)
Copyright © 2026
Privacy Policy