The Project Narrative

The Engineer Who Couldn't Explain

A few years into my career, I watched one of the smartest engineers I've ever met slowly lose a project that he should have won easily. Let's call him Rohan. He was technically brilliant — the kind of person who could see three moves ahead in a system design conversation and explain why each of them would fail. He was building a new data pipeline to replace a legacy system that was causing real pain: late reports, incorrect numbers, on-call engineers woken up at 3am. The old system needed to go. Everybody agreed on that.

But eight months in, the project was on life support. Executives were asking whether it was worth continuing. The team was demoralized. Other teams had quietly started building workarounds instead of waiting. The project eventually limped over the finish line at a fraction of its original scope.

What went wrong? I spent a lot of time thinking about this. The technical work was sound. The plan was reasonable. The team was capable. Here's what I eventually concluded: Rohan couldn't explain the project. Not in a way that stuck. Every time he described it, he described the technical components — the new ingestion layer, the schema migration, the backfill strategy. People would nod. And then, three weeks later, he'd have to explain it again from scratch because nobody had retained enough to care.

The project had no narrative. It had a description — a technically accurate account of what was being built. But it had no story. No villain, no stakes, no moment that made the listener feel why this mattered more than the seventeen other things competing for their attention right now.

This is more common than most engineers admit. We are trained to think in components, interfaces, and edge cases. We are not trained to think in stories. And yet at the senior levels of any large organization, story is the mechanism by which resources get allocated, priorities get defended, and projects survive long enough to ship.

This chapter is about fixing that.

What a Narrative Is Not

Before we can build something, we need to clear the ground of some wrong ideas. The word "narrative" carries a lot of baggage that will lead you astray if you're not careful.

A narrative is not a spin. It is not a way to make a bad project sound good, or to hide the rough edges from executives. Engineers who try to use narrative as a PR exercise end up in a worse position than engineers who say nothing — because they eventually get caught, and the damage to their credibility is significant. Everything in this chapter assumes your project is genuinely worth doing. If it isn't, that's a different problem, covered in Chapter 24.

A narrative is not a slide deck. A deck is a container. Narrative is the content. You can have a twenty-slide deck with no narrative, and you can deliver a complete, compelling narrative in two minutes over coffee. The medium is irrelevant. The underlying logic is what matters.

A narrative is not a summary. A summary compresses what you're building. A narrative explains why it matters. These are different things, and treating them as the same is the most common mistake I see from engineers who are trying to "communicate better."

And finally — and this is the one that surprises engineers most — a narrative is not just for executives. The people who need to hear your project's narrative most urgently are your own team. Engineers who understand why they're building something make better decisions than engineers who are just executing on a ticket. The narrative is the shared context that makes a team autonomous instead of dependent. It is how you delegate well.

What a Narrative Actually Is

A project narrative is the answer to one question: "Why should I care about this project right now?"

That question is harder than it sounds. It's being asked by multiple people with different incentives. Your team asks it when they're choosing between your ticket and the other three tickets in their backlog. Your manager asks it when the quarterly planning doc comes out and there are eight projects competing for three engineers. The VP asks it during a portfolio review when she has to decide whether to cut scope to make the date or slip the date to protect scope. Everyone is always asking this question, all the time. The project with the clearest answer to it survives. The ones without an answer get deprioritized, defunded, descoped, and eventually canceled.

The answer to "why should I care right now" is never a list of features. It is never a technical architecture. It is a story with a very specific structure: there is something broken or missing in the world right now, it is getting worse or more expensive to ignore, and here is the thing we're going to do about it that hasn't been tried (or has failed before, and here's why this time is different).

That's it. Three things. A good project narrative — whether it's delivered in a two-minute hallway conversation or in a thirty-page design document — always contains those three things. If any one of them is missing, the narrative doesn't work.

Let's go through each layer in detail.

The Three Layers

Layer 1: The Villain — The Problem That Exists Today

Every story has a villain. In project narratives, the villain is the problem — the thing that is causing pain, burning money, blocking growth, or creating risk right now. The villain has to be concrete. Abstract problems make weak villains.

Compare these two openings:

The second one names a real villain. It's not "technical debt" — a phrase so overused it creates no emotional response in anyone. It's the finance team sitting in a room at 7am, making decisions they don't have the information to make correctly. That is a villain people can picture. And when people can picture a villain, they feel the urgency to defeat it.

There's a discipline to naming a villain well. Here are the questions to ask yourself:

• Who is experiencing this problem right now, today? Give them a name or a role. "Our on-call engineers" is better than "the team." "The payments checkout flow" is better than "user-facing services."
• How often is it happening? Frequency creates urgency. "Every morning" hits differently than "sometimes."
• What does it cost? Cost doesn't have to be money. It can be time, trust, morale, customer confidence. But name it specifically.
• Is it getting worse? A villain that is growing is more alarming than one that is static. If your data shows the problem is trending in the wrong direction, that is your most powerful piece of evidence.

Layer 2: The Stakes — What Happens If Nothing Changes

The villain describes the present. The stakes describe the future if the villain goes undefeated.

This layer is the one most engineers skip. They describe the problem, jump straight to the solution, and wonder why people don't feel the urgency they feel. The reason is simple: without stakes, a problem is just a known issue. Known issues live forever in backlogs. Known issues with named consequences get fixed.

Stakes come in two flavors: cost-of-delay and cost-of-inaction.

Cost of delay is what you lose for every month you don't fix this. Revenue left on the table, engineering hours spent fighting fires instead of building features, customer trust slowly eroding. Cost of delay is a number, or at least an estimate. Even a rough estimate — "we believe this costs us roughly two engineer-weeks per month in toil" — is far more powerful than no estimate. It turns the stakes from a story into a business case.

Cost of inaction is what the world looks like in one year if you do nothing. This is harder to quantify but often more emotionally compelling. "If we don't address this now, every new feature the payments team ships will take twice as long because they'll be building on the old foundation" is a picture of a future that engineers, managers, and executives can all see themselves in. That picture motivates.

Layer 3: The Path — What You're Doing and Why It's the Right Call

This is the layer engineers are most comfortable with, and where they often make their first mistake: they describe the solution before they've made the villain and stakes vivid enough that the audience wants one.

The path is your answer to the problem. But notice that it is a choice — not the obvious move, not the only option. A strong narrative acknowledges that alternatives exist and explains why you chose this particular path. This is important for two reasons.

First, it builds credibility. An audience that hears you've considered other approaches trusts your recommendation more than one that suspects you're just advocating for the first idea you had.

Second, it pre-empts pushback. The most common form of pushback is "why didn't you consider X?" If your narrative already addresses X and explains why you rejected it, that pushback evaporates. This isn't manipulation — it's good thinking made visible.

The path layer should cover four things:

• What you're building — described at the level your audience can engage with, not at the technical level you find most comfortable.
• What you're explicitly not building — the scope boundary, stated clearly. Narratives that omit scope boundaries invite scope creep, because everyone fills in the gap with their own interpretation.
• Why this approach over the alternatives — two or three sentences is enough. You're not writing a design doc here.
• What success looks like — one concrete, measurable state of the world that will exist when this project is done and wasn't true before you started.

The North Star Statement

Every project needs a one-sentence north star statement. This is the sentence that anyone on the project should be able to say from memory after two weeks on the team. It is the sentence you say when someone at the coffee machine asks what you're working on and you don't want to give a five-minute answer.

Here is the template:

Notice that each example is one sentence. Not two. Not a sentence with four sub-clauses. One sentence. If you can't say the north star in one sentence, the project isn't focused enough yet, or you don't understand it well enough yet. Either way, you need to fix that before you brief anyone on it.

The north star statement has a specific job: it is a filter. When a new idea comes up — a feature request, a scope addition, a "while we're in there, could we also..." — the north star statement is what you use to evaluate it. Does this addition help us give the finance team same-day numbers? If yes, consider it. If no, it does not belong in this project. Not because the idea is bad, but because this project has a job and the job is defined. The north star keeps scope honest.

Same Narrative, Different Audiences

One of the most common mistakes I see principals make is building different narratives for different audiences. They have the "engineer version" — technical, detailed, full of architecture diagrams. And they have the "executive version" — high-level, focused on business outcomes, stripped of all the interesting details.

This is a mistake, and here's why: when the engineer version and the executive version are structurally different, the people in the middle — staff engineers, senior managers, tech leads from other teams — don't know which one to believe. They've heard both. They feel like they're getting different stories. And people who feel like they're getting different stories stop trusting the source.

The answer is not to build two stories. It is to build one story at multiple resolutions. Think of it like a map. A street map and a world map show the same geography. One just shows more detail. You can zoom in and zoom out, but the geography doesn't change. The north star statement doesn't change. The villain doesn't change. The stakes don't change. The path doesn't change. What changes is how much detail you show.

Audience	Resolution	What They Need
Individual engineers	High	Technical decisions and why they were made. What they're responsible for. How their piece connects to the whole. What done looks like for them specifically.
Tech leads / staff engineers	High-medium	Architecture trade-offs. Dependencies on and from other teams. Risk areas. Decision points coming up in the next 4-6 weeks.
Engineering manager	Medium	Milestone status. Blockers that need their help. Team health. Whether the project is on track to hit the commitment they've made to leadership.
Director / VP	Low	North star. Business outcome. Current milestone. Top two risks. What they need to do, if anything.

Notice that the audience list above doesn't have a special "executive version" separate from the "technical version." It's a dial, not a switch. And that dial represents how much detail to show, not which story to tell.

The discipline here is to write the full narrative first — at full resolution, for yourself and for the engineers on the project — and then practice zooming out. When you can explain the project correctly at each zoom level without contradicting yourself, your narrative is solid.

How Narratives Die

Building a narrative is the easier half. Keeping it alive for six months is where most engineers fail. Here are the five most common ways a project narrative dies, and how to spot each one before the damage is done.

Death by complexity. As the project progresses, the technical work reveals new nuances. Edge cases multiply. The architecture evolves. Engineers start describing the project in increasingly accurate but increasingly impenetrable terms. The narrative gets buried under the details. The fix: maintain two descriptions of the project at all times — the full technical truth, and the one-paragraph narrative. Never let the technical description replace the narrative. They serve different purposes.

Death by pivot. The project changes direction. A new stakeholder gets involved, scope shifts, the business priority changes. But the narrative doesn't get updated. So for the next three months, people are executing on the new plan but talking about the old one. This is more common than anyone admits, and it is deeply confusing to everyone who isn't close enough to the work to have noticed the pivot. The fix: every time the project changes direction in a meaningful way, explicitly update the north star statement and announce the update. Don't assume people noticed.

Death by success creep. The project starts delivering results — maybe partial results, in a pre-launch phase. People start using early versions and requesting changes. Gradually, the project stops being about the original goal and starts being about satisfying the loudest current user. The villain from the original narrative has been mostly defeated, but nobody has declared victory and redefined what success means now. The fix: when the original villain is defeated or substantially reduced, run a narrative refresh. State what has been achieved, name the new north star if there is one, and be honest if the project should end rather than continue.

Death by silence. The team stops talking about the narrative altogether. It's written in some document that was last opened four months ago. New engineers join and learn the technical details but never hear the story. The project becomes, to the people doing it, a series of tasks without a through-line. Motivation drops. Decisions get made locally without reference to the overall goal. The fix: the narrative must be spoken aloud regularly, not just written down. Every project sync, every demo, every onboarding conversation — the north star comes up. Not as a ritual but as a reminder of why the work matters.

Death by false consensus. Everyone nods at the narrative in the kick-off meeting. But six weeks later, different people on the project have subtly different versions of it in their heads. The engineers think the goal is to reduce latency. The product manager thinks the goal is to unblock new features. The sponsor thinks the goal is to cut costs. Everyone is doing work that serves their version of the goal. Nobody is doing maximally bad work — but they're pulling in slightly different directions. This is how projects end up shipping something technically complete that doesn't actually move the metric that matters. The fix: test for alignment regularly. Don't ask "does everyone understand the goal?" Ask specific questions: "what decision would you make differently if we prioritized X over Y?" Different answers reveal diverged interpretations before they become expensive.

Keeping It Alive Through Six Months

The practical question is: how do you keep a narrative alive without it feeling like a forced ritual that everyone is just going through the motions on?

The answer is to connect the narrative to decisions, not to ceremonies. A ceremony is "we all say the north star statement at the start of every meeting." This gets stale in three weeks. A decision is "we're being asked to add X to scope — let's check whether it serves our north star." This keeps the narrative relevant because it's doing actual work.

Here are the four moments where narrative should be explicitly referenced:

When the Narrative Must Change

Some engineers treat the north star as sacred — something that cannot be changed once it's been set, because changing it means the project was ill-defined. This is the wrong way to think about it.

The north star is your best understanding of the goal at a given point in time. The world changes. The business learns things. A bet you made six months ago turns out to be wrong, or partially right, or right for different reasons than you thought. Updating the north star to reflect new understanding is not weakness — it's precision.

The rule is simple: change the narrative when reality requires it, but make the change explicitly and deliberately. Don't let the narrative drift through omission. Don't update it quietly in the Google Doc without telling anyone. When the narrative changes, announce the change. Explain what new information caused the update. This is exactly the kind of transparent reasoning that builds credibility with teams and stakeholders over time.

The moments that require a narrative update:

• The primary stakeholder changes and the new stakeholder has different needs.
• A key assumption in the original narrative has been invalidated by data or by events.
• The business priority that the project serves has shifted in the organization's ranking.
• The original villain has been meaningfully addressed and the remaining work serves a different goal.
• Scope was cut significantly enough that the original north star is no longer achievable with what's left.

What you do not do is change the narrative under pressure. If an executive pushes back on your project and you update the north star to match what she seems to want to hear, you've destroyed the integrity of the narrative. The team will notice that the goal changed based on a meeting rather than evidence, and they'll stop trusting it. Distinguish between "the narrative changed because we learned something new" and "the narrative changed because someone important didn't like it."

The One-Page Project Brief

The one-page brief is the written form of your narrative. It is the artifact you produce at the beginning of a project — and update as the project evolves — that makes the narrative portable. Anyone who reads it should be able to understand what the project is for, why it exists now, what success looks like, and what they need to know to engage with it intelligently.

Notice the word "one-page." This is not a soft constraint. It is a hard one. If you can't explain your project in one page, you don't understand it well enough yet. The act of forcing the brief to one page is the most valuable editing you will do on the entire project. Every cut makes the remaining content sharper and more defensible.

The brief has eight sections. Here is the structure, with notes on what each section is actually for:

The brief is not a one-time artifact. It is a living document. At the start of a project, the brief is your best current understanding. Two months in, it should be updated to reflect what you've learned and what has changed. The updated brief is then the record of how the project evolved — and why. Future engineers, future post-mortems, and future projects all benefit from that record.

A Worked Example: From Mess to Narrative

Let me show you how this works in practice by taking a real-world type of project and building its narrative from scratch.

The project: A team has been asked to "improve the developer experience for the internal API platform." The ask is vague. The charter is thin. The team isn't sure exactly what to build. This is the standard state of most large projects when they land on a principal engineer's desk.

The first thing to do is interview stakeholders and find the villain. After a few conversations, the picture that emerges is this: there are currently forty-three internal API clients across twelve product teams. When the API platform team makes a change — a schema update, a new authentication requirement, a rate limit adjustment — they currently send an email to a Slack channel and hope people see it. In the last year, four production incidents were caused by a product team missing a breaking change announcement. The average cost of each incident was about six hours of engineer time across both teams. Additionally, onboarding a new API client currently takes two to three weeks because the documentation is scattered across three wikis and a Confluence page nobody maintains.

Now we have a villain. Let's build the narrative:

Notice what happened. We started with "improve developer experience" — which could mean anything — and ended with a specific villain (missed change announcements, slow onboarding), specific stakes (40% client growth that breaks at current incident rates), a specific path (four-capability portal), and specific success criteria (measurable outcomes, not features shipped).

This brief can now go to an executive in two minutes or to the engineering team in thirty. The story doesn't change. The resolution does.

The Hallway Test

There is only one meaningful test for whether your narrative works. Not whether you can write it clearly. Not whether it fits on one page. Not whether your manager approved it.

The test is this: pick someone who has heard your narrative once, two weeks ago. Stop them in the hallway. Ask them to tell you what your project is for. Listen to what comes out.

If they can give you back a version of the north star — even imperfect, even incomplete — your narrative is working. The key idea transferred. It stuck.

If they say "um, it's something about the API... improving the developer workflow... or was it the Kafka migration?" your narrative failed. It was technically present in the room but it didn't lodge anywhere. You need to go back and find out which layer is weak. Usually it's the villain — it wasn't concrete enough to stick — or the north star — it was too vague to remember.

Run the hallway test every four to six weeks on your longest projects. Not just on your immediate team — on the periphery too. The PM from an adjacent team. An engineer who attended one of your syncs three weeks ago. A manager whose team has a dependency on yours. These are the people who will either carry your narrative forward into their own conversations or let it die.

If the hallway test passes, you're doing your job as a communicator. If it fails, nothing else in this chapter matters until you fix it. A project whose story nobody can tell is a project that will die the next time the business has to make a prioritization decision.