A founder we work with asked for a count last month: how many drafts had we written for him since January, and how many had gone out. The answer was 118 written, 71 published. Forty-seven drafts, roughly 40%, had been killed, and neither of us could say where they were. Some were in a Google Doc with "OLD" in the title. Some were in Slack. At least a dozen were gone.
That ratio is normal. In a healthy engagement, a meaningful share of what gets drafted should never ship. What is not normal is treating the killed 40% as waste. A draft that didn't publish is not a failed post. It is a decision with a reason attached, and both the decision and the reason are worth more than most of what did publish.
We call the place they go the spike file, after the newsroom habit of impaling stories that didn't make the edition on a desk spike. Every content system we have written about covers what goes in (capture banks), how it gets filed (the router), what ships when (the running order), and what happens after it's live (the decay pass). None of them covered the material that made it all the way to a draft and stopped. This one does.
Why killed drafts disappear
Nobody deletes a draft on purpose. A draft dies because something more urgent got written, or the founder said "not that one" on a call, or it sat in the queue until the news peg it needed passed. Then the document it lived in gets reused, the Slack thread scrolls away, and six weeks later the draft has no location.
The mechanism matters because it tells you the fix is not discipline. Drafts die in the gap between "not this week" and "never." Nobody decides never. It happens by default when there is no place for "not now" to live.
What a killed draft actually contains
Open any spiked draft and it holds three things a published post does not.
A reason it was killed. Too close to something you posted ten days ago. The number couldn't be defended in a DM. The founder wasn't sure the story was his to tell. The angle was fine but the week was wrong. That reason is a piece of editorial judgment, and editorial judgment is the scarcest thing in any content operation. Published posts don't record why they were chosen. Killed ones, if you write it down, record why they weren't.
A claim that didn't clear the bar. A draft killed because the number felt shaky is a flag on the source, not just on the post. If the same claim is sitting in your proof bank unmarked, the spike file just caught something the bank missed.
A block of work that is 80% done. A killed draft is a hook, a structure, and two or three specifics that already exist. When the reason it died expires (the news peg comes back around, the clustered topic is now four months old, the founder is ready to tell the story), the post is a 15-minute rewrite instead of a 90-minute session.
The five fields
We keep it deliberately small. A spike file that takes more than 30 seconds per entry becomes a second job and stops being maintained.
- Working title and the draft itself. Paste the whole thing. Don't link to a doc that will get renamed.
- Date killed.
- Why it was killed, in one line. The field that matters. "Too close to the Aug 4 post" is useful. "Didn't feel right" is not. If the founder can't give a reason, write "no stated reason" so you can count those later.
- Revive condition. When, if ever, does this come back? "After the Q4 freeze." "If the return-rate result holds at 90 days." "Never, the number was wrong." Writing "never" is fine and stops you re-reading it every month.
- Claim status. If the draft was killed because a number was shaky, mark the number, not just the post.
Reading the spike file as a diagnostic
Every quarter we sort the spike file by reason. Twenty killed drafts sorted by why they died tell you more about an engagement than the quarterly performance review.
Too many killed for "too close to a recent post." The running order is failing. The material is good, the sequencing isn't. Fix the two-week horizon, not the writer.
Too many killed for "number can't be defended." The capture system is letting unverified proof reach the draft stage. Route it through the source ledger earlier. This is the only reason on the list that should make you nervous, because the drafts that got through without being caught are already live.
Too many killed for "founder not comfortable telling it." Usually a disclosure-ladder problem. The story is fine at a different rung, a band instead of a number or an unnamed partner instead of a named one. Those come back within a month once the rung is picked.
Too many killed for "no stated reason." The founder is approving on feel, which typically means approving on how the post makes them look rather than what it does for a reader. This one predicts churn. A founder who cannot say why a draft died in month four is a founder who will not be able to say why the engagement is working in month fourteen.
Almost nothing killed. Also a finding. A 95% publish rate means nobody is saying no, and an engagement where nobody says no produces a feed that is consistent and forgettable.
What comes back, and what doesn't
Roughly a third of our spiked drafts eventually publish. Which third is predictable.
Comes back: anything killed for timing (clustering, wrong week, news peg not yet live). Anything killed for a disclosure problem that has a cheaper rung. Anything killed because the result wasn't mature yet; the post about a returns fix that was two weeks in gets revived at week ten with a better number than it would have had.
Doesn't come back: anything killed because the claim was wrong. Anything the founder didn't believe. Anything that was an opinion without access behind it, because those don't improve with age, they just get restated by six other people while they sit in the file.
The rule for revival is the same as for a re-run: rewrite from the entry, don't repost the draft. The reason it died is usually visible in the prose, and a reader can tell when a post was written for a different week.
How it changes the drafting conversation
The unexpected effect is on the founder, not the writer. When killing a draft costs nothing because it goes somewhere with a reason attached, founders kill more freely and more honestly. The "no stated reason" count drops within two months, not because we pushed, but because the field is on the form and an empty field is uncomfortable.
The second effect is that the writer stops defending drafts. If the choice is publish or delete, a writer argues for the post they spent an hour on. If the choice is publish or spike with a revive date, there is nothing to argue about. The draft is not gone, it's parked, and the hour is not lost.
FAQ
Isn't this just a backlog? No. A backlog is things you haven't gotten to. A spike file is things you got to and decided against, with the reason written down. The reason is the asset. A backlog has no reasons in it, which is why backlogs get abandoned and nobody learns anything from them.
How is it different from the hold list in the running order? The hold list holds finished material waiting for the right week. The spike file holds material that was actively declined. Some hold-list items become spikes when their week never arrives. Nothing in the spike file should be on the hold list; if it has a date, it's held, not spiked.
What if the founder wants to delete something outright? Delete it from the feed, not from the file. The only entries we remove are ones involving a third party that should never have been drafted. Even those keep a one-line record: "drafted, killed, reason: not ours to tell." That line has saved us from re-drafting the same story twice.
We're two years in with no spike file. Start with the archive? Don't. Start with the next draft that dies. Ten entries with reasons outperform a hundred recovered from old docs with the reasons long forgotten.
If your drafts are dying somewhere you can't find and nobody can say why, that is not a writing problem. It's a filing problem with a writing symptom, and it's the one part of the content system most founders have never been shown. We build it in from week one.