Most technical founders hand the company's story to someone else: the marketing team, the sales lead, a more public co-founder. The reasons are usually fair. The version of storytelling they have seen is performative. Vulnerable LinkedIn posts. Keynotes with three-act structure lifted from a screenwriting book. Origin myths rehearsed in a mirror. None of it reads as honest to an engineer, so the engineer opts out.
That instinct is correct. The catch is that the performative version is not the only version, and the one underneath fits a technical mind better than it fits almost anyone else. This piece is about that version: what the craft is when you strip the theatre out, and why the habits that make you good at an incident review already make you good at it.
The performative version deserves the dismissal
You are not wrong about the storytelling you have seen. Most of it is bad.
"I cried in the parking lot" is not a story. It is a performance of feeling, and a reader who prefers substance reads it as a sales move. The forced underdog arc is the same problem. Most real business moments do not have a villain, a climax, and a tidy resolution in that order, and pretending they do is exactly what makes founder content sound fake.
So the reflex to walk away from it is sound judgment, not avoidance. The mistake is letting the bad version stand in for the whole category. Throwing out storytelling because the LinkedIn variety is hollow is like throwing out documentation because someone showed you a bad README.
The actual craft: decisions, tradeoffs, and changes of mind on record
Stripped of the theatre, a founder story is a structured account of a real decision: what you chose, what you gave up, and what you know now that you did not know then.
That is it. No arc to manufacture, no feeling to perform. You are putting a call on the record and showing your work, which is something you already do every time you write an RFC or run a retro.
The reason this fits technical founders is mechanical, not motivational. Three habits engineers already have are the exact habits good narrative needs:
- Precision. "The queue backed up for 47 minutes on March 3rd" is a sentence an engineer writes without thinking. It is also the register that makes a story land. Most founder content fails because the specifics are missing, and specifics are the one thing engineers never skip.
- Naming both sides of a tradeoff. Latency for cost. Consistency for availability. Build for buy. Engineers are trained to state what they gave up, and the thing you gave up is what gives a business story its stakes.
- Honesty about being wrong. Incident reviews reward "we were wrong and here is why." Most founders flinch at that line. Engineers write it for a living.
The muscle is already built. The only thing that needs to shift is the register, from internal memo to public post, and that is a smaller move than learning to tell stories from scratch.
A few reflexes to retrain
A technical mind dropped into the feed runs into a few patterns that work against good content. Each one needs a deliberate undoing.
The abstraction reflex. Engineers over-generalize when writing for a broad audience, assuming the specific case is too niche to matter. The opposite is true. "We moved off Postgres to DynamoDB and here is what it cost us" is a story. "We scaled our infrastructure" is a press release nobody finishes.
TED-talk structure. Setup, tension, resolution, applause. That is a format for a stage, where the speaker has twenty minutes and wants the room to clap. In writing, the reader leaves the second the register goes theatrical. Use the post-mortem shape instead: decision, context, tradeoff, outcome, what you know now.
Waiting for a clean ending. Engineers want the bug closed before they write it up. The best founder stories are often told mid-problem, while the outcome is still uncertain. The uncertainty is the part readers recognize, because they are sitting in their own version of it.
The decision log: 150 words per real call
The whole practice fits in one habit. Keep a decision log.
Every time you make a real call, write 150 words about it. What you chose. What you gave up. What you were uncertain about when you chose it. What you would need to see to change your mind.
Do it in the flow of the work, not as a separate content exercise. The entries are for you first, which is why the habit survives a busy week when a content calendar does not. Most entries, with light shaping, become posts. A few become talks. One or two become the structural beams of a fundraise narrative.
The log compounds. A content calendar asks you to invent material on a schedule. A decision log just records the material the business is already producing, and the supply never runs dry because you are always making decisions.
An incident review and a founder story are the same shape
This is the part worth internalizing: you are not learning a new skill, you are pointing an existing one at a new audience.
A post-mortem states what happened, what decision led there, what the tradeoff was, and what changes now. A founder story states what you decided, what it cost, how it played out, and what you believe now that you did not before. Same skeleton. Same demand for specifics. Same refusal to pretend you knew all along.
The founders writing this way in public are not in confessional mode. They are documenting and defending. Spenser Skates has talked openly about Amplitude's start: he and his co-founder built a voice-recognition app called Sonalight, could not work out what users were actually doing inside it, built a crude internal analytics tool to answer that question, and pivoted the company into the tool when other companies kept asking for it. He does not smooth the pivot into a retcon. The wrongness stays visible, and that is why the story carries.
David Heinemeier Hansson at 37signals does the same with arguments: most of what he publishes is a decision or a stated position with the reasoning attached, defended rather than confessed. Stewart Butterfield told the Glitch failure honestly before Slack, and the Slack story reads stronger for it. Charity Majors at Honeycomb writes about running infrastructure with a directness that reads like an internal memo someone made public. None of them is performing. All of them are on the record.
The Upshot
You already know how to do this. You call it a post-mortem.
The micro takeaway: start the decision log this week. One real call, 150 words, what you chose and what you gave up. Do not announce it, do not schedule it, just write the next decision down. In a month you will have a backlog of posts you did not have to invent.
The sharper one: the reason most founder content is generic is not that the founders lack stories. It is that the people most equipped to tell a grounded, specific, honestly-uncertain story, the technical ones, are the people most likely to opt out. The feed is full of high-level operator takes because the operators are the ones still posting. When a technical founder shows up with a real decision and a real tradeoff, the content stops sounding like a marketing department and starts sounding like a company that actually builds things.
For the broader craft this sits inside, the founder communications guide covers extraction, shaping, and deployment end to end. If your stories keep coming out flat, start with why founder stories sound generic. And if pulling the real story out is the hard part, story extraction is the listening discipline behind all of it.
Common questions.
Why do technical founders dismiss storytelling?
Because the version they have seen is performative: vulnerable LinkedIn posts, three-act keynote structure, origin myths with the rough edges sanded off. That version deserves the dismissal. The actual craft is closer to a well-written post-mortem than a keynote, which fits engineers and technical leaders better than it fits most communicators.
What should a technical founder write about instead of a hero narrative?
Decisions. A tradeoff you made and what it cost. A bug whose root cause taught you something structural about the team. A customer conversation that rewrote a belief. These are stories with stakes and a shift, and they do not require pretending to feel something you do not.
Why is an incident review the same shape as a founder story?
Both put a decision, its context, the tradeoff, and the outcome on record, plus what you know now that you did not know then. A post-mortem does this for an outage. A founder story does it for a business call. The register is the only difference, and engineers already own the harder register.
What is the simplest practice to start with?
Keep a decision log. Every time you make a real call, write 150 words about what you chose, what you gave up, and what you were uncertain about. Do it in the flow of work, not as a separate content exercise. Most entries become posts with light shaping.
