A technical story needs an unresolved question

TL;DR: Michelle Lo Horton's short reel points to three storytelling resources. The exercise I would take into technical writing is to give the reader one unresolved question, then make each section change what they can conclude about it. Suspense earns its place through explanatory progress.

This share is for engineers writing incident accounts, design explanations or demonstrations that contain useful facts but feel like a sequence of disconnected updates. Horton recommends work by Kallaway, Vinh Giang and Will Storr. The on-screen cards identify the resources more clearly than the automatic transcript does. Original reel.

Around 0:09, she introduces Kallaway's storytelling video. Around 0:18, she points to Giang's three-ingredient explanation; around 0:26, the card names Storr's The Science of Storytelling. I inspected the reel's transcript and representative frames, not the complete book and both longer videos. Treat these as reading and viewing leads rather than a verified neuroscience prescription.

Let evidence change the story

Here is the outline I would use for a hypothetical failure investigation. A service becomes slow after a release, so the initial question is whether the release caused the slowdown. That is concrete enough to make the next observation matter.

The first section establishes the timing. The next compares affected and unaffected requests. A third examines the evidence that separates an expensive new code path from an unrelated dependency problem. Each section reduces uncertainty rather than merely reporting what the team did next.

A chronological list of meetings would also be true, but it would ask the reader to reconstruct the causal argument themselves. I would keep only the events that explain why an interpretation changed. The rest can live in the operational timeline.

The unresolved question must also be honest. If the article already has enough evidence to name the cause, withholding it for several paragraphs can become a trick. State the finding early, then let the interesting question become how the team distinguished it from the plausible alternatives.

Keep the discarded explanation

The most useful paragraph may be the one explaining why the obvious diagnosis was rejected. It teaches a reader what evidence would stop them making the same mistake. A polished story that removes every wrong turn can make the final answer look inevitable.

This is a proposed writing structure, not a test showing that the reel's resources improve attention or business growth. I would assess the draft by asking a colleague to name the initial hypothesis, the discriminating observation and the resulting change in understanding. If they can only remember that something dramatic happened, the explanation still needs work.

Horton's list is a starting point for practice. My addition is to make the unit of progress a resolved uncertainty, rather than a stronger adjective or another cliffhanger. That gives technical storytelling a job beyond holding somebody on the page.

Keep the reader moving by changing what the evidence lets them believe.