“You emphatically do not want to tell a beginning-to-end tale describing how results meet expectations.” The screenwriting teacher Robert McKee said that in his 2003 Harvard Business Review interview on storytelling. He was talking to business leaders, but he could have been describing a lot of weekly status updates.
The last update you gave or sat through probably went in the order things happened: this got done, that’s in progress and this other thing is on track. Every item got the same weight, and the overall message was that things are roughly where they were meant to be. That’s exactly the beginning-to-end tale McKee warns against, and it’s why hardly anyone remembers it ten minutes later. Nothing in it changed, so nothing in it asked the listener to think or act differently.
When people say “I’m not a storyteller,” they’re often thinking of anecdotes they don’t have, or a founder-on-stage routine they can’t picture themselves doing. Neither is needed here. This post uses a narrower and much easier idea of a story at work: a change, and what it means for the person listening. You’ll get one structure for saying that. After that come three rewrites that apply it to a status update, a demo and an internal pitch. The post ends with a section on when a story is the wrong tool altogether.
What counts as a story at work?
McKee’s definition of a story is about change: how life changes, and why. At work it comes down to four plain questions that anyone can answer. What did we expect, and what changed? What does that mean, and what happens next? An update that answers those is a story even if it has no characters, no anecdote and nothing you’d call drama.
This is why you already tell stories without noticing. Say you’re explaining to a colleague why a launch moved. You’d naturally start with what the plan was and then the thing that went wrong, and you’d finish with what you’re doing about it. Nobody calls that storytelling, though. They call it explaining. The trouble starts when the same person sits down to write a formal update and switches to reporting outcomes in the order they happened. That strips out the change that made it worth hearing.
There’s some research on why the change matters, though it’s worth being careful about what it shows. In 2000, Melanie Green and Timothy Brock published four lab experiments on what they called transportation. People in the experiments read a short story, and their beliefs were measured afterwards. They defined the idea like this: “Defined as absorption into a story, transportation entails imagery, affect, and attentional focus.” The more absorbed people were, the more their beliefs moved toward the story’s. The neuroscientist Paul Zak made a related point separately. Writing about experiments in his own lab that used short videos and charity donations, he wrote in Harvard Business Review that a story “must first sustain attention” and that it does this “by developing tension during the narrative.”
Neither study was done on workplace updates, so they don’t show that a story beats a list of facts in your Thursday meeting. What they suggest is a mechanism: attention follows tension, and tension needs something to have changed. That’s a reason to try the structure below, not a promise that it works every time. Telling a story well is hard, and McKee says so himself. The structure just makes it less hard.
If you’re interested in stories in a different setting, our post on the power of storytelling in training covers how trainers use them in learning sessions. This one sticks to the updates, demos and pitches you give as part of your job.
A four-beat structure for business storytelling
The structure has four beats, and you say them in this order.
The first beat is where things stood, meaning the expectation or the situation until now. That might be the plan or the target, or the way something has always worked. It’s one sentence, and it’s there because a change only makes sense against something. “The export is late” means little on its own. “We planned go-live around an export due on the 17th” gives the listener the line that the change is about to cross.
The second beat is what changed, and it’s the story. It’s the one fact that’s different from last time. Maybe a date moved or a risk appeared, or a customer said something you didn’t expect. An assumption might have turned out to be wrong, or a number went the other way. It doesn’t have to be bad news, and it doesn’t have to be a result. Even a week where nothing shipped can have a change in it, because something you were assuming is now more or less likely than it was. If you’re not sure you have one, ask yourself what you’d be worried about if you were the person listening.
The third beat is what it means: the consequence for the listener, plus anything you’ve already done about it. It answers the question everyone is silently asking after a change: so what? If it’s missing, people fill in the consequence themselves and may guess bigger or smaller than the truth. This beat is also where your work shows up. In a status update it’s what you’ve done to contain the change. As you’ll see later, a demo’s third beat is the demo itself.
The fourth beat is what you need, meaning the specific thing you want from the listener. That could be a decision or a phone call from them. It could also be sign-off, feedback by a date or simply nothing. Saying “nothing needed this week” counts too, because knowing they can relax is useful information for the listener.
You may know the situation-complication-resolution pattern, or the SCQA version that adds a question. If so, you’ll recognize the family resemblance. This is an adaptation of that long-standing pattern, not a new invention. The difference is in the emphasis, because here the second beat carries the weight and the last beat is always addressed to the person in front of you.
The table below shows what each beat does for the listener and what happens when it’s missing:
| Beat | The question the listener is silently asking | What goes wrong without it |
|---|---|---|
| Where things stood | ”What was supposed to happen?” | The change has nothing to be measured against, so it sounds like noise |
| What changed | ”Why are you telling me this now?” | The update becomes a list of equal items, and the important one gets lost |
| What it means | ”So what?” | The listener guesses the consequence, often wrongly |
| What you need | ”What do you want from me?” | The listener nods, says thanks, and does nothing |
None of the beats needs a gift for narrative, because each one is a sentence or two of plain fact. What makes it a story is the order and the decision about which fact goes in the second slot.
How to turn a flat status update into a story
The best way to see the structure is to watch it rebuild an ordinary update. The example below is illustrative: Tamsin and her director Maren are made-up people. The project, dates and numbers are invented for the purpose as well.
The update as most people write it
Tamsin is moving her company’s customer support team onto a new ticketing system, with go-live set for November 3. Every Thursday she gives Maren a short update, either in their weekly meeting or as a message beforehand. This week’s looks like the one below. It’s accurate, organized and polite, which makes it the kind of fair update most of us write.
Quick update on the support desk migration this week:
- Field mapping for the ticket data is finished and signed off by the support leads.
- Training: four of six sessions are booked. The last two are waiting on room bookings.
- The CRM connector passed testing on Tuesday.
- The ticket history export from the old vendor is now expected on the 24th rather than the 17th, after a staffing change on their side. If it slips again it may be worth someone more senior contacting their account director.
- Macros and saved replies: 70 of 85 rebuilt.
- Go-live still planned for November 3.
Let me know if you have any questions.
Read it as Maren would, between two other meetings. Five of the six items say “going fine,” and the last one says go-live is still on plan. So the overall impression is that the project is on track, and Maren will probably reply “Thanks, great progress” and move on.
But one of those items isn’t like the others. The fourth bullet is the only one where something is different from what everyone expected last week. Yet it sits in the middle of the list in the same format as the macros count, and it ends in a hedge.
Finding the change
The first move is to pick the change out of the list. A simple test helps: for each item, ask whether it would change what Maren does or worries about this week. Field mapping being finished doesn’t, and training bookings don’t either unless the rooms fall through. The CRM connector passing its test is good news, but it’s the news everyone expected. The export moving by a week is the only item that passes the test, because it eats into the time Tamsin has to load and check five years of customer history before go-live.
So that’s the second beat. Once you’ve found it, the other three beats are much easier to write around it. This is how the rewrite might sound when Tamsin says it in the meeting:
“We’ve been planning go-live for November 3, and most of the work is where it should be. What changed this week is the ticket history. The old vendor now says the export arrives on the 24th, not the 17th, because of a staffing change on their side. That leaves us seven working days to load and check five years of customer history, instead of twelve, so we’ve lost five. If it slips again, agents go live without history, and a customer calling about an open issue would have to explain it from scratch. We’ve already moved the history load to run alongside the last two training sessions, which buys back three of those five days. What I need from you is a call to their account director this week, so the 24th is confirmed in writing before it can slip again.”
Here is what each sentence is doing. The first sentence is the “where things stood” beat, and it includes the reassuring part of the old update in a single clause. Maren still learns that most of the project is fine, but she learns it in nine words instead of five bullets.
The next three sentences are the change, stated with dates and the size of the gap. Dates matter here for the same reason they matter in any difficult message: “the export is running a bit late” invites a shrug, while “the 24th, not the 17th” gives the size of the problem in a way nobody can soften.
The next two sentences are the “what it means” beat, and Tamsin doesn’t stop at “we’ve lost five.” Five days of what? Maren isn’t close enough to the work to know what those days are for. So Tamsin translates them into the consequence Maren actually cares about, which is a customer on the phone having to repeat themselves. That’s the moment the update becomes something a director can feel the weight of. She also says what she’s already done. That way Maren knows the problem is being handled and isn’t being dumped on her.
The last sentence is the ask, and it’s specific in three ways. It names the action (a call) and the person (the vendor’s account director). It also sets the timing (this week, before the 24th can move again). Maren can say yes or no to that in the meeting.
Deciding what to cut
The rewrite leaves out the field mapping, the training bookings, the CRM connector and the macros count. That can feel uncomfortable because those things represent real work by real people. Dropping them can feel like not giving the team credit.
The way to decide is to ask two questions about each item: is it on plan, and can the listener do anything with it? If the answer is yes to the first and no to the second, it doesn’t need to be said out loud. That doesn’t mean it disappears. It belongs in the written record, where anyone who wants the detail can find it.
A template is usually the better tool for that written version, especially in routine weeks. Our guide to asynchronous communication includes a written status update template, and its “Needs a decision from you” line already makes you put the ask where a busy reader will see it. What this post covers is the spoken version: the two minutes in a meeting where you have to choose what to say first.
The one thing you should never cut is the “where things stood” sentence, even when it feels obvious. If you leave it out, a change sounds like the whole picture. “The export slipped a week” said on its own could make Maren think the entire project is in trouble. But “Most of the work is where it should be, and one thing changed” sets the scale correctly.
The 30-second version
Sometimes you don’t get two minutes because the meeting is running over. Or Maren catches Tamsin in the hallway and says “how’s the migration?” You can compress the four beats into two sentences for moments like that:
“Go-live on November 3 is at risk because the vendor’s history export slipped a week. Could you call their account director this week so it doesn’t slip again?”
The first sentence folds where things stood, what changed and what it means into one line. The second is the ask, and everything else can wait for a follow-up message.
It’s worth writing this version even when you expect the full two minutes, because it tells you whether you know what your update is about. If you can’t get it into two sentences, you probably haven’t decided which fact is the change yet. That means the longer version will drift back into a list.
How to open a demo with a story instead of a feature tour
A demo has a different problem from a status update. A status update buries the change in a list. A demo usually doesn’t mention it at all, because the presenter is so close to the thing they built that the reason for building it feels too obvious to say.
The same structure fixes it, with one twist: the demo itself becomes the “what it means” beat. It’s the evidence that the change happened. Everything before the demo sets up what the audience should look for, and everything after it asks them for something.
Here’s an illustrative example. Corin is an analyst who has built an internal tool that matches supplier invoices to purchase orders. He’s showing it to the finance and operations leads, none of whom are technical. His first instinct is to open the tool and walk through it in the order the menus appear. He’d go from the login and the home screen to the filters and the upload page. After that would come the matching view, the export options and the settings. He finishes with “So that’s it. If anyone wants access there’s a form on the intranet, and we’re hoping to switch off the old spreadsheet by the end of the month.”
Every screen in that tour works, and Corin is right to be proud of it. But the finance leads spend the first five minutes watching a login page and a filter menu without knowing why they should care.
Here’s how he might open instead. He starts with where things stood, described from the audience’s side rather than his own: “At month-end, matching invoices to purchase orders takes your team about two days, and most of that is copying numbers between two spreadsheets.” (The two days is an illustrative figure for this example. Use the number your audience would recognize when you give a real demo.) Next comes the change: “This tool does the matching itself, and it only shows a person the invoices it couldn’t match.” Before he touches the screen, he tells them what to watch for: “When I upload last month’s invoices, watch the number in the top corner. That’s how many still need a person. Last month it would have been all of them.”
Now the demo has a job. The audience knows what the evidence is, so when the number appears they understand what they’re looking at without needing to follow every click. After the demo, Corin finishes with the ask: “I’d like your sign-off to retire the old spreadsheet after November’s close, and I need it by the 15th so I can switch everyone’s access over.”
The harder part is deciding what not to show. This is how to handle the features that don’t serve the story:
- Cut the login and admin screens. Everyone assumes a tool has a login, and showing it spends your opening minutes on something nobody will remember.
- Move the settings and configuration options to questions. If someone asks how to change the matching tolerance, you can show it then. If nobody asks, they didn’t need it.
- Show one export format, not all of them. The audience only needs to know the result can leave the tool, and the full list can go in a follow-up note.
- Leave out the feature you’re proudest of if it doesn’t help the change you’re demonstrating. This one is hard. But if it took you two weeks to build and it’s beside the point, it will pull attention away from the number in the corner.
None of these features is lost. They’re parked for questions or for a written follow-up, where the people who care about them will find them.
How to pitch an idea internally
A pitch is the format where the four beats need the most care, because your listener isn’t neutral. They may have set up the process you want to change, or they may have already thought about your idea and rejected it.
McKee put this well in the same interview: “the people you’re talking to have their own set of authorities, statistics, and experiences.” He goes on to say that while you’re presenting, they’re arguing with you in their heads. That’s the reason a pitch built on your own data often lands badly. Your manager has numbers of their own, so they start comparing the moment you lead with yours.
The next example is illustrative too. Thea is a customer success specialist, and she thinks the team should start renewal check-ins with customers 90 days before renewal instead of 30. She raises it in a team meeting where her manager and peers are present: “I think we should move renewal check-ins to 90 days out. It gives us more time to fix problems. A lot of other companies do it, and I read a piece last week that recommended it. I’d be happy to try it on a few of my accounts if people are open to it. Thoughts?”
It’s a reasonable idea, presented reasonably. It opens with the idea and follows with three reasons, then ends with “thoughts?” But her manager’s first thought will be that the team moved to 30 days two years ago for a reason. That reason was call volume, and nothing Thea said addresses it.
The rewrite starts from a situation the room already recognizes, not from Thea’s proposal: “Of the last five renewals we lost, three told us about the problem in the 30-day call, after they’d already set next year’s budget.” Everyone in that meeting has been on one of those calls. They know what it feels like to hear about a problem when there’s no budget left to fix it. So she’s reminded them of their own experience instead of asking them to accept her data.
Next comes the change, which is where she answers the strongest objection before anyone raises it: “We moved to 30 days because 90-day calls doubled the call load, and at the time that was the right call. What’s changed is that more of our customers now set budgets in the third quarter, so by the 30-day mark the decision’s already been made.” She says the situation the original choice was built for has moved, which is much easier for her manager to agree with than being told the choice was wrong.
What it means comes next, in the form of the proposal. She suggests earlier check-ins so problems surface while the customer still has budget to fix them. Last comes the ask, with a size and a deadline: “I’d like to run 90-day check-ins on my 22 accounts from November to January and bring the results to the February team meeting.” It’s small enough to say yes to. It also has an end date, so her manager isn’t signing up to a permanent change on the strength of one meeting.
A pitch in a group meeting usually goes better when the key person has heard it beforehand. Our guide to influence without authority covers how to sound out the key people before a meeting like this one, and how to word the ask depending on how warm the room is.
Where this breaks: when not to tell a story
Everything in this section is our editorial judgment. None of the sources quoted in this post supports it, and one of them argues against it. McKee says in the same interview that “statistics are used to tell lies and damn lies, while accounting reports are often BS in a ball gown.” It’s a good line, and for some audiences it’s wrong. There are situations at work where the numbers should come first, and where wrapping them in a story makes things worse.
When the decision rests on numbers the audience will check
A finance lead deciding whether to approve a budget will go straight to the figures. If you open with a narrative, you’ll probably hear “so what’s the actual number?” At that point you look as if you were hiding it. Give the number first, then use the story to explain it. The structure still helps, but the order flips.
When you’re reporting bad news or an incident
If a system went down or a customer was harmed, the listener needs the fact and the impact in the first sentence. A built-up narrative (“we’d been planning a quiet weekend, and then…”) can read as an attempt to manage their reaction. Say what happened, who was affected and what you’re doing about it. The story of how it happened can come later, in the review.
When an executive asks for the bottom line first
Some senior people want the ask before anything else, and they’ll tell you so. When they do, respect it by putting the fourth beat first. You can give the other three as support if they ask for them. The beats are all still there, but they’ve changed places.
When nothing has changed
Some weeks really are on plan, and in those weeks saying “no change, nothing needed from you” is the whole story. It’s a useful story too, because it lets the listener spend their attention elsewhere. Inventing tension to fill the slot is worse than a short update.
When the structure becomes a formula
There’s also a risk in the structure itself. If you use the same four beats every week, people start to hear them coming. “Where things stood” turns into a ritual opener, and the listener tunes in only when you get to the change. That might be fine, since it means they’ve learned where to find the important bit. But it can also mean the first beat has become noise, in which case cut it down to a phrase.
Here is a short note on culture, offered as general observation rather than research. Teams in the US often expect the ask to be stated plainly and early. A direct ask can land as abrupt in the UK, where the same request may be softened into a suggestion. A pitch to a senior person in many Indian organizations tends to go better when it has been aligned privately beforehand, so the meeting confirms rather than decides. The structure works in all three, but how bluntly you say the last beat may need to change.
One thing we can’t give you is a clean rule for how much narrative a skeptical finance audience will put up with. Some will accept one sentence of context before the numbers, and some won’t accept any. You’ll have to try it with your own audience and watch for the moment they reach for the spreadsheet.
How to practice this without turning every update into a performance
None of this needs rehearsal in the theatrical sense. All it needs is about ten minutes before your next update and three steps.
First, write the “what changed” sentence before anything else. If you can’t write it, you may not have a change this week, and then your update is “no change.” The other possibility is that you haven’t yet decided which item matters most. In both cases you’ve learned something before you’ve said a word.
Second, say the whole update out loud in three or four sentences with one per beat. Saying it instead of reading it is where you’ll notice the sentence that’s too long or the consequence you skipped. This is the part of oral communication that structure can’t do for you. If nerves are the bigger problem when you speak up, our guide on how to calm your nerves before a presentation covers the delivery side. Our post on presentation skills for managers covers the wider skill set.
Third, check the ask. Make sure it’s there and that it’s the last thing you say. The listener should also be able to answer it with a yes or a no.
That third step matters more than it might seem. Go back to the three flat versions earlier in this post and look for the ask in each one. Tamsin’s was in the fourth bullet: “it may be worth someone more senior contacting their account director.” Corin’s came after “So that’s it,” once the demo was over and the room had stopped paying attention: “we’re hoping to switch off the old spreadsheet by the end of the month.” That needed their sign-off, though he never said so. Thea’s was the line before “Thoughts?”: “I’d be happy to try it on a few of my accounts if people are open to it.”
Each of them knew exactly what they needed, and each of them said it. But in every case the ask was hedged and placed where nobody was listening. It was also worded so the listener could agree without doing anything. That’s why each flat version would probably have got a friendly nod and no action. The narrative matters, but the change most likely to turn that nod into action is moving the ask to the end and saying it plainly. You’ll see that if you compare each flat version with its rewrite.
So when you check your next update, start with the last sentence. If the person listening can’t tell what you want from them, fix that before you touch anything else.
Try your next update on Merlin
If you’d like to hear how your update lands before Thursday, talk it through with Merlin. Merlin runs natively in Slack and Microsoft Teams, so you can practice without leaving either. Give Merlin your four beats and ask it to play your director or the skeptical manager in your pitch, and you’ll find out which question comes back first. If you’d rather start by seeing where your communication is strong and where it isn’t, the communication assessment takes about five minutes.
After that, write your “what changed” sentence for this week’s update and put your ask at the end of it.