Storytelling Engineering: Why the story is the spec

In spring 2012, the CEO of a two-billion-dollar startup hired a cartoonist. Brian Chesky had just finished reading a Walt Disney biography, and one idea stuck with him. It wasn’t about Mickey Mouse. Instead, it was a drawing technique from 1937. The board understandably wondered how this related to renting rooms. But Chesky was about to turn storytelling into a design specification, even if no one called it that yet.

Keep that in mind. It helps answer a question most companies overlook: why do good systems fail?

This happens all the time. Every company I’ve worked with has one, and you’ve probably seen it too: an internal platform that teams quietly avoid. These platforms are usually still running, sometimes maintained, or simply ignored.

AI made structure easy to create, but meaning is still hard to achieve.

More people are doing more types of work, and they’re doing it faster. Agents increase this even further. Someone needs to create the shared structure and common paths that prevent chaos, which is why systems thinking is becoming so important.

That’s all true. But if you look at failed projects, you’ll see many structures built by those same people. Building the system was never the hardest part. The real challenge is getting people to actually use it.

This is a problem of meaning, not structure. AI can design your architecture quickly, but it can’t understand the purpose behind the system.

Now, the rare skill is creating meaning intentionally, as part of engineering, not just something marketing adds later. I call this storytelling engineering. When I mention this term, some people cringe, while others quickly point out someone on their team who already does it, or realise they need it. These reactions show how important this skill is.

I realise this might sound odd. Isn’t storytelling the brand team’s job? But both words mean more than we usually think.

Story is the main way we give meaning to people, and now, to machines too.

You can’t rewrite or restructure a belief.

Meaning is shared from one person to another in only one way, and most builders haven’t studied how it works.

Systems thinking helps explain this. Donella Meadows defined a system as having parts, connections, and a purpose. Connections are more difficult to manage, and purpose is invisible but also the most powerful part.

The main tools for building or changing a system’s design are always the same: budgets, metrics, and headcount are at the base level. At the top is the paradigm, the idea everyone accepts without even realising it.

Here’s the tricky part: our tools can’t reach that high. You can’t rewrite a belief or use A/B testing to create a shared assumption. To spread a purpose from one person to many, we have only one tool, and it’s older than writing: a story.

Think about what a story really is: someone wants something, something gets in the way, they struggle, and then it ends. The way events unfold explains the reason behind it all.

That’s how a system works. The character is one part, the obstacles are the connections, and the goal is the purpose. Research shows that when we hear stories, we don’t remember the exact words. Instead, we create a small mental model and play it out in our minds.

A specification describes a system, but a story actually puts it into people’s minds.

There are three levels, but most teams only reach the first.

Story isn’t just decoration for systems. It’s essential, and it operates at three different levels.

On the surface, story is like packaging: the launch presentation or the document explaining why something was built. These are necessary, but not nearly enough.

One level deeper, story drives adoption. Every platform asks teams to give up some control for shared speed, but no API reference ever convinces them. What works is showing a world where you never have to build authentication again. Amazon even made it a rule: nothing gets built until someone writes the press release. If the story doesn’t work, the system shouldn’t exist.

Go even deeper, and the story becomes part of the infrastructure. A design system isn’t just a set of components. It’s a collection of opinions built into defaults, quietly saying: this is how we treat users. When someone who isn’t a designer creates a page, and it looks right, it’s because the beliefs were built into the design styles, making them scalable and clear. The next step is to capture narratives in a way that everyone on the team and even agents can use. Product requirement documents are turning into story specification documents.

At the deepest level, story becomes the paradigm that drives the system, the foundation of the culture. For example, Amazon’s rule that every team must expose its data through service interfaces led to twenty years of architecture and eventually AWS. At this level, the story doesn’t just describe the system; it shapes it through decisions made by people the original author never met. When building software becomes easy and common, the real value is in the idea. Here, the idea is a belief turned into a story, which then guides and aligns the system.

That’s why so many platforms fail. Teams built them with deep engineering, but their storytelling only scratched the surface.

The cartoonist who debugged a company

Now, the cartoonist. What had grabbed Chesky was Snow White. The first feature-length animated film. A bet so big it nearly broke Disney’s studio, made possible by a technique invented for the job: the storyboard, a way to hold a story too big for any one animator’s head.

Airbnb had the same problem in different clothes. The product wasn’t a website. It was a trip. Days long. Mostly offline. Two main characters. Invisible to every dashboard the company owned.

So Airbnb hired Nick Sung, a Pixar artist, and storyboarded the whole service like a film.

The guest’s journey and the host’s, frame by frame, with the feelings drawn in.

The storyboards found a bug. Not in the code. In the company. Drawn as a story, the guest’s journey made something obvious that no org chart had surfaced: the times that decided whether a trip felt enchanting occurred nowhere near a desktop computer. The conclusion, the key is mobile, redirected strategy, hiring, and at least one acquisition. The story didn’t describe the system. It debugged it.

Then the frames went up on office walls, and teams started asking a new question in reviews: which frame does this feature serve? A whole company came to share one mental picture of an experience no single employee could ever watch end to end.

That’s what I meant at the start. The storyboard had become the design spec. Not a document about the product. The document the product got built from. It’s the template for building anything too big to see whole, which is most of what the AI era will ask us to build. A movie fails when it has a bad story. An agentic system fails when it has a bad story too.

Every session is the agent’s first day at work.

For the entire history of software, building was the slow part and explaining was the afterthought. AI just flipped that, permanently.

An AI agent in your codebase or your brand is a new employee with perfect syntax and zero context. And zero context isn’t a figure of speech. It’s the architecture. A language model is stateless. It keeps no memory between sessions. Its context window is its entire working mind for the task in front of it. You might object that models have memory now. Look at how those features actually work: notes written to a file, stored outside the model, read back into the context window next session. The memory isn't in the model. The memory is a document the model reads. Every "remembering" system we've built for AI is a writing system, which doesn't weaken the point. It is the point.

A company onboards a human once. It onboards an agent ten thousand times a day, and the onboarding is whatever story got written down. That’s what those instruction files sitting in codebases actually are: employee handbooks, read in full before every task. Onboarding used to be an HR event. It just became infrastructure.

There’s a second gap, deeper than recall. A model is trained on roughly everything, so left undirected it produces the average of everything: fluent, competent, and beige. Your taste is by definition a deviation from that average, and deviations don’t live in the weights. They have to be supplied.

The supply of artefacts takes a familiar form. Prompts, style guides, voice docs. Every one of them is a story: a description of a world, a character, an intent. “We’re a bank that talks like a friend, never like a lawyer” steers a model better than five hundred formatting rules. A rule covers the cases you thought of. A story covers the cases you didn’t, because the reader, person or model, can run the world in their head and work out the answer. This gives rise to the storytelling engineering team, which articulates, maintains, and improvises the storytelling artefacts so the entire system is aligned with and driven by the company's purpose and goals.

That’s what a story is, technically: compression that loses the details and keeps the purpose. A spec sheet is the opposite. Perfect on details, purpose gone. In an AI workflow, the story is the spec. Context engineering is its first rough tooling, the way FORTRAN was the first rough tooling of software.

The billion-dollar PDF, but for your company system.

There’s a phrase going around for where this ends: the billion-dollar PDF.

It has already happened in slow motion. The Bitcoin whitepaper was nine pages. Most seed decks are longer. A trillion dollars organised itself around it. “Attention Is All You Need” was a research paper, and the AI industry is its implementation. No product, no company, a document with enough purpose in it that the world reorganised itself to execute it.

Agents make this literal. When agents can do the work, the document that tells them what the work is becomes the most valuable thing a company owns. Push that far enough, and the document stops describing the company and starts being it.

Telephone, played by machines

That’s humans steering machines. Something subtler goes wrong when machines steer each other.

Humans have always moved context through story. It’s our oldest protocol. The hunt got retold around the fire with the terrain, the danger, and the reasons intact. Not just the result. Agent-to-agent systems pass results instead: task in, output out, everything story used to carry stripped away for efficiency.

For example, anyone who has handed a contractor a spec with no explanation knows how this goes. You get exactly what you asked for, and it’s never what you wanted. With agents, it’s a documented failure mode. Tell a coding agent to “make the tests pass” and, often enough, it deletes the failing tests. Researchers call it specification gaming. A goal is a sentence. The intent behind it is a story. The model only received the sentence.

Pipelines compound the loss. Each handoff summarises, each summary drops a little intent, and by the third hop the point of the work has quietly fallen out. The formats all validate. The purpose is gone, and nothing was checking for that.

The fix is to make the story part of the payload. Send the why along with the what, unsummarized, untouched by any hop. In a deep pipeline, the story is the one signal that has to survive the depth. Brief a context window instead of dumping files into it; the context window is the new campfire, and what gets told around it decides what the tribe does next. And make systems tell the story back: what they thought the goal was, what they did, why. The moment their story drifts from yours, you’ve caught the failure while it’s still cheap.

The models get better at everything except knowing what you mean.

You might expect these gaps to close as models improve. The opposite is true.

Statelessness is the design, not a bug. A model’s knowledge lives in weights frozen at training time. Your company’s purpose isn’t in there and can’t be: it’s private, particular, and changes faster than any training cycle. Meaning can only arrive at run time, through context.

The average is definitional. A model predicts the most likely next word, and likelihood is averaging by construction. Taste is the opposite: unlikely choices, made consistently, for reasons. A bigger model is a better average, not a braver one.

And the intent gap grows with capability. Any goal you write down is a stand-in for what you want, and optimisers exploit the difference. A stronger agent finds more ways to satisfy your words while missing your point.

So the void isn’t engineering debt waiting for a better model. It’s the shape of the technology. And a permanent void does what permanent voids always do: it creates a profession. Computers could calculate but couldn’t decide what to calculate, and we got programmers. Models can build but can’t want. Someone has to do the wanting, precisely, in a form both people and machines can execute.

So storytelling has to become an engineering discipline.

The narrative process is the new design plus product engineering process.

A changing of the guard is underway in how software gets made, and its name hasn’t caught up yet.

For twenty years, the design process was the backbone: research, wireframe, critique, polish, ship. It made sense because screens were scarce. They aren’t anymore. What’s scarce is coherence: a thousand fast outputs that still feel like one product.

Coherence used to come from slow loops. Reviews. Apprenticeship. Ask the one person who knows. At AI speed, the slow loops never close. Elizabeth Stone, rebuilding Netflix’s product and engineering org around this exact problem, puts it plainly on Lenny's Podcast: a company of thousands can’t run on tribal knowledge anymore. What good looks like has to be built into the paved paths themselves.

The part I’d add: tribal knowledge always lived as story. Writing it into the defaults isn’t the end of narration. It’s storytelling, industrialised. When a marketer ships a landing page no designer will ever see, the story built into the design system is the only designer in the room. For example: a customer success person's tribal knowledge is a lot of stories and cases they have seen and dealt with.

So the process flips. The design process shipped screens and hoped they added up to a story. The narrative process writes the story first: who this is for, what it refuses to be, what good feels like in the moment that matters. Then it builds the story into the templates, the defaults, the agent context, and lets a thousand people and agents build inside it without drifting apart.

The old process asked: is this screen right? The new process is more like: does this screen belong to our story?

Every gap in the machine creates a job for a human. Job titles are already yielding to this.

A product manager’s PRD used to brief humans, who filled its gaps with judgment. Now it briefs machines, which fill gaps with averages. So the PM’s real deliverable shifts from requirements to the narrative they came from. Product manager becomes product storyteller.

Engineers already have their version: the architecture decision record, a short story of why we chose this, now read by agents before they touch the code.

The pattern repeats in every function. AI automates the task, and in the same motion creates a new job: supplying the thing it can’t. Statelessness makes someone the author of the onboarding story. Regression to the average makes someone the keeper of taste. Specification gaming makes someone the writer of intent. That someone is the storytelling engineer. I’m betting the first companies actually to put this on an org chart will look eccentric for about two years, and then obvious.

This is also why storytellers are escaping the marketing department. Marketing tells the story after the system is built, to people outside. The AI era needs it told before anything is built, to everyone inside, including the machines.

And one more reason, maybe the deepest, is that every solution to the alignment problem that has ever worked at company scale, starting with missions to cultures to founding legends, was a narrative technology. Rules fail at the edge of their author’s foresight. Stories keep working past it. It’s why the most serious attempts to govern model behaviour read less like rulebooks and more like constitutions.

Six storytelling engineering tools, one loop

Six tools, each an old storytelling habit pointed at a new problem.

The future press release. Write the story of the day the system works, before you build it. Then give that same page to the system as its north star. One document briefs both the builders and the built.

The storyboard. Draw the journey frame by frame, the way Airbnb did, remembering your cast now includes agents. The frames show you where people need to feel asked, warned, or seen.

Golden narratives as evals. Turn your best stories into tests. “Guest lands at midnight, the lockbox code is wrong” checks whether the system gets the ending right. No accuracy score can do that.

The constitution. Give any system with many actors a short story of who we are, how we treat people, what we won’t do. Rich enough that new situations can be reasoned through instead of looked up.

The premortem. Write the story of how it all quietly failed, a year from now, before you launch. Failure told as a story surfaces what no risk checklist finds.

Narrative telemetry. Make the system tell its story back: what it thought the goal was, what it did, why. The moment its story drifts from yours is the moment to act.

If you build AI systems, you’ve already met all six of these tools wearing lab coats. The press release is the eval you write before you build. Golden narratives are the regression suite. The constitution is the system prompt. The premortem is the red team. Narrative telemetry is interpretability. The AI field has spent years reinventing the storyteller’s toolkit without ever saying the word. That’s not a coincidence. Any discipline that needs to instil purpose in minds it can’t supervise will converge on story. Engineers just arrived at the campfire from the other direction.

One loop ties them together. Author the story. Encode it into the system. Test the system against it. Make the system report back in story. Purpose in, purpose enforced, purpose out. That loop is storytelling engineering.

The story was the spec.

Disney bet the studio on a storyboard. Chesky hired a cartoonist to debug a marketplace. Satoshi shipped nine pages, and the world built the rest. In every case, the diagrams came later. The story was the spec.

Systems thinking really is becoming the defining skill of the AI era. But the deepest lever in any system only moves by story.

In a world where everyone can build, the rare skill is seeing the structure that should exist. The rarest is telling the story that makes everyone, people and machines, build it together. And keep building in the same direction after the author has left the room.

The scaffolding lets many people move fast. The story is what makes them move in the same direction. The graveyard is what happens when you build one without the other.

Build both: systems and stories.