Every piece of I/O work ends the same way. You know something you didn't know before, and somebody else has to decide whether to do anything about it. That handoff is where the value of the work is realized or lost, and it runs on a skill most of us were never formally taught.
The phrase for it is "data and storytelling," usually said as though these are two separate things you bolt together at the end. The data half is what school produced: the analysis, the evidence, the research you trust. The story half is what makes any of it usable to a person who has to choose something. For this field the stakes are specific. Our whole proposition is that people decisions can be made on evidence instead of instinct. The evidence exists and keeps accumulating. Whether it reaches a decision comes down to this, which makes storytelling less of a soft skill and more of the mechanism the field runs on.
Underneath all of it is a distinction worth making explicit, because most presentations that go badly are not badly made. They're the wrong form.
A report is organized around your process, in the order it happened. Here's what we set out to examine, here's how, here's what came back, here's what it might mean. That structure exists so a reader can check your work, and it does that job well.
A story is organized around someone's situation, in the order that makes it make sense to them. This is what's happening, this is what makes it a problem, this is what to do about it. Same facts, different spine. One form is built for verification and the other is built for a decision, and a great deal of frustration comes from bringing the first one into a room that needed the second.
A second shift comes with it and it's harder to make. In a report, your work is the subject. In a story, their situation is the subject and the person listening is the one who has to act in it. Your analysis is what makes the story true, and the story itself is about them.
What follows is why good work stalls anyway, what the people who are good at this do differently, the specific techniques worth learning, and how all of it changes depending on who you're sitting in front of.
Part 1: Why good work stalls
Some of it has nothing to do with you
The budget isn't there this year. A reorganization lands three weeks later and everyone you convinced has a different job. Somebody above the room already decided something else and nobody in the meeting knows yet. The data would need to be pulled out of three systems and cleaning it up costs more than the problem does.
None of that is a communication failure and no amount of craft prevents it. It's worth saying plainly, because the alternative is assuming every stalled recommendation was your fault, and that assumption makes people quieter over time rather than better.
Some of it is the story you brought
The rest is more useful, because it's the part you can do something about.
You can solve a problem nobody is feeling yet. The finding is real, the fix is sound, and nothing about the current quarter makes it urgent to anyone. Correct and early looks identical to wrong from inside the room.
You can be right in a way nobody can act on. "Our selection process lacks validity evidence" is true and it isn't a decision. Somebody still has to work out what to do on Monday, and if you leave that step to them, you've handed over a problem rather than a recommendation.
And most commonly, the story ends up being about your findings when it needed to be about their situation. Every slide is accurate, the analysis is thorough, and the room never quite sees itself in it. What you get back is polite interest, which is what a report earns when a story was needed.
This field carries a specific headwind
There's one more thing, and it's particular to us.
When an engineer says the migration takes six weeks, nobody in the room has a competing view. The subject is technical, the expertise is conceded, and the conversation moves to what to do about it.
People work isn't like that. Everyone at the table has hired people, managed people, sat through their own performance reviews, and formed real conclusions from decades of watching how this goes. When you say the interview process isn't predicting performance, you're talking to a room of people who have their own evidence, gathered first-hand over a long time. That isn't ignorance or resistance. It's the accumulated experience of anyone who has spent a career around other humans, and it means our findings arrive into a fuller room than most.
The practical consequence is that weight doesn't work the way you'd hope. Adding more findings and more method to an argument that isn't landing tends to make it worse, because a room that's debating your sample size has stopped talking about the decision.
Which no you get
When something does stall, the outcomes are not equivalent.
A no where the room concluded you were wrong is expensive and slow to undo. A no where the room agreed with you and couldn't act is a different thing entirely. Those people carry the conclusion into the next planning cycle, and one of them raises it themselves when the money appears, usually without you in the room. Most of what looks like influence later was built in meetings where nothing happened at the time.
Part 2: What the people who are good at this do differently
They build the story before they build the analysis
This one reverses the order most of us learned. Rather than running the analysis and then working out how to present it, they decide early what the story would be if the data supported it, and let that shape what they go and look at.
It sounds like putting the conclusion first, and it's closer to knowing what question you're answering. If you can't state what a finding would mean before you have it, the analysis tends to produce something technically sound with no obvious use. Working that out at the start is also much cheaper than working it out the night before a readout.
They know the one thing
Before anything gets built, they can say in a sentence what the point is. Everything else in the deck either supports that sentence or sits in the appendix, and material that does neither doesn't get made.
This is harder than it sounds, because most projects produce five or six things worth saying. Choosing between them feels like throwing away work. It's the choice that separates a story from a summary.
They have three versions and know which one is wanted
Thirty seconds, five minutes, thirty minutes. Same content, genuinely different builds, and they can tell from the room which one is being asked for.
Most people only ever build the thirty-minute version and then deliver it regardless of circumstance, which is why so many findings get compressed badly on the spot. The thirty-second version is the one that matters most, because it's the one that gets repeated when you're not there.
They keep the story and the evidence file separate
The rigor still exists. It lives in the appendix, the technical note, the methods section, and it comes out the moment somebody wants it.
What they've worked out is that a room deciding something and a reader checking something want different documents, and that trying to serve both at once produces a document that does neither well. This is the resolution to the tension a lot of practitioners feel between being thorough and being convincing. You don't have to choose. You have to know which one you're holding.
They cut things they were proud of
Editing is where craft lives in every storytelling discipline and this one is no different. The finding you spent three weeks on, that turned out to be interesting rather than decisive, comes out. It stings, and it's the price of a story that holds.
They use sequence deliberately
The same three facts in different orders lead a room to different conclusions, and none of the arrangements are dishonest. Which fact you open with determines what the room is thinking about when they hear the second one.
People who are good at this treat order as a decision rather than an accident of how the analysis unfolded.
Part 3: The techniques worth learning
None of this needs to be invented from scratch. There's a well-worn body of craft behind it, most of it from consulting and technical communication, and it's all learnable quickly.
SCQA and the Pyramid Principle. Barbara Minto's framework, and the standard for structuring an argument. Your governing idea goes at the top with support beneath it, introduced through four beats: the Situation your audience already accepts, the Complication that disturbs it, the Question that raises, and your Answer. The Complication is the engine. A story without one gives nobody a reason to keep listening, and a surprising number of readouts skip straight from background to findings without ever establishing why any of it is a problem. Minto's book is the source and it repays reading properly.
Action titles. Write the headline of every slide as a full sentence that states the point, answering a what or a how. "Turnover analysis" tells a reader nothing. "Most first-year turnover traces back to two teams" delivers the point before anyone looks at the chart. Michael Alley's assertion-evidence approach is the version of this with research behind it, and it's well documented online.
Read your titles as a narrative. Pull every title into a single list, in order, and read it with nothing else on the page. It should hold together as an argument on its own. If it reads like a table of contents, the deck doesn't have a spine yet. This exercise does more for the author than the audience, because you can't write a title as a claim until you've decided what the slide actually argues, and the slides that argue nothing become obvious immediately.
The one sentence. What you found, what it means, what you'd do. If you can't fill in all three parts, the missing one tells you what work is left.
The "so what" test. Take any finding and ask what somebody should do differently because of it. If the answer is "know a thing," it isn't finished. If the answer is "improve onboarding," it isn't finished either. "Add a structured 30-day check-in, owned by the HRBP for that function, starting with the September cohort" is finished.
Part 4: Who's in front of you
The same finding needs a different entry point depending on the room, and what changes is mostly the ratio of story to evidence.
A finance audience wants the constraint and the number, and will get to the reasoning afterwards if the number is interesting. A legal or compliance audience wants defensibility and will be skeptical on purpose, because that's the job. An operations leader wants to know what this does to their week before they'll consider whether it's true. None of these are personality types. They're different jobs with different exposure, and the entry point determines whether anyone gets far enough in to weigh the evidence at all.
Then there's the meeting where the person who can actually decide isn't present. This happens constantly and it's easy to treat as a waste, which is the wrong read. What changes is your job in the room rather than whether the room matters.
You're now equipping somebody to carry the conclusion somewhere you won't be. That means giving them a version they can repeat accurately without you standing next to it, which in practice is one sentence and one number. Anything more complicated degrades on the way, and you'll never see where it broke. It also means finding out who's going to carry it and what they'll be walking into, which is a different conversation from the one you prepared.
Why this matters more here
It's worth stepping back to why any of this is worth the effort, because the answer is different for us than it is for most professions.
When a system goes down, nobody debates whether to fix it. When the auditors flag something, nobody books a workshop to explore whether accuracy is a priority this quarter. Technical and financial recommendations tend to arrive with the reason to act already attached to them. The person delivering one can be an average communicator without it changing what happens next.
People strategy almost never arrives that way. Most of what we recommend shifts a rate rather than preventing an event. Turnover runs a few points high. The selection process predicts a little less well than it could. Managers are somewhat underprepared for the jobs they're in. Every one of those is genuinely expensive, and the expense accumulates slowly, spread across hundreds of separate decisions, in a form that never lands on a single line that somebody owns. A hiring process that leaks value at scale carries on working the entire time it's leaking. Nothing breaks, nothing goes red, and no deadline appears on anyone's calendar.
So acting on people strategy stays optional in a way that acting on a technical recommendation does not. It ends up competing against things that have dates attached, and it tends to lose on urgency rather than on merit.
That's easy to read as a complaint about organizations undervaluing this work, and it's far more useful as a description of the job. When the urgency isn't built into the finding, somebody has to supply it — honestly, out of consequences that are real and currently invisible to the people paying for them. That is what the story is for: making a slow, diffuse, genuinely expensive problem legible enough to compete with the things that are on fire.
Which is also why the gap between a good telling and a poor one is wider here than almost anywhere else. An engineer with clumsy delivery still gets the fix approved, because the alternative speaks for itself. The same quality of evidence in our hands carries less automatic force, so much more of the outcome depends on how it gets carried. That's an uncomfortable thing to sit with, and it's the strongest argument there is for treating this as a craft you practice rather than a knack you either have or don't.
What to take from this
A few things worth carrying into the next one, on the understanding that they're a starting point rather than a method. Whether a decision actually gets made turns on timing, money, who happens to be in the room and what went wrong last quarter, and plenty else that has nothing to do with you.
- Decide what the story is before you build the analysis.
- Know the one sentence.
- Keep the rigor and put it somewhere else.
- Write your titles as claims and read them alone.
- Ask what somebody does differently on Monday.
- Build the thirty-second version, because it's the one that travels.
The evidence already exists. Most of what this field knows is sitting in journals and reports that organizations would act on if it reached them in a usable shape. Getting it there is the work, and it's a craft rather than a talent, which means it can be practiced deliberately like anything else.