We do not maintain a content calendar. We have a small backlog of unpublished drafts, an editorial filter we trust, and a habit of reading the week’s tickets before deciding what to write about. The schedule emerges from that, not before it.
That sounds like a lack of process. It is not. Choosing what to write about is the most expensive editorial decision in marketing, and we made it cheap by tying it to work that already happened. If the engineering team shipped something on Tuesday that changed how the system behaves, that is a candidate. If a comment thread on a ticket settled an argument that had been simmering for three weeks, that is a candidate. If a routine failed in a way nobody had seen before, that is a candidate.
What is not a candidate: any topic that exists only as a topic we would like to talk about. Marketing topics in the abstract have a way of generating prose without substance. We have written enough of those to recognize the shape, and we have stopped publishing them.
Where the topics actually come from
We read three things before picking the next post.
The first is the merged work. We look at the issues that closed and ask whether any of them involved a small decision worth explaining. Most do not. A bug fix usually closes with a one-line note, and that is the right length for it. But a fix that changed a default, removed a fallback, or introduced a new invariant is a topic. The work has already done the thinking. We just have to find the sentence that holds it.
The second is the comments. The most interesting writing in our company does not happen in commit messages. It happens in ticket comments where someone argued against a default and got overruled, or where a decision got walked back because of a constraint nobody had surfaced. Those comments are usually two paragraphs long. They make better posts than press releases.
The third is the things that broke. Incident threads are usually structured: timeline, root cause, follow-up. They are also unusually honest, because incidents do not leave room for the language that marketing teams reach for when nothing is at stake. We try to write our posts the same way. A thing happened, here is what we changed, here is what we are still unsure about.
What gets filtered out
The filter is unforgiving. Most candidate topics fail it.
If we cannot say what the post would teach a reader who reads it once and then forgets the rest, we do not write it. If the lesson is just a restatement of the topic, we do not write it. If the lesson is correct but obvious to anyone who has worked on a similar system, we do not write it. The audience is not new to engineering.
A surprising number of candidate topics fail in another way. They would require us to mention things we cannot mention. A clean lesson sometimes runs through a private decision, a vendor name, or a budget number, and there is no way to extract the lesson without disclosing what produced it. We move those topics to an indefinite shelf. Some come back later in a form that no longer needs the private detail. Most do not.
The filter is the part of the process we trust. It is also the part that makes the calendar unnecessary. If a week produces no work that passes the filter, we publish nothing that week. The penalty for a quiet week is smaller than the penalty for a forgettable post.
What changes when the topic is recent
Topics taken from the week’s work read differently from topics taken from a calendar. The most obvious difference is specificity. A post written about a defaults change three days after the change knows the exact thing the change broke first, and the exact reason the team chose one default over the other. A post written about defaults in general knows none of that.
The less obvious difference is honesty. Recent topics are still alive in the heads of the people who decided them. When we write about them, we tend to include the part we are not yet sure about. A post that says “we are still not certain this default was right” is more interesting than a post that says “we chose the right default because here are our principles.” We are pretty sure the principles came after the decision.
There is a third difference. Posts about recent work are easier to verify. Anyone reading along can check the repository or the changelog or the deploy notes. The post stays honest because it has to. It cannot drift toward something more comfortable, because the source is still there.
What we give up
The cost of not having a calendar is real. We cannot promise a partner that a topic will land on a particular date. We cannot align posts to product launches, because we do not have product launches in the conventional sense. We cannot plan an editorial arc across a quarter.
We are mostly fine with that. The thing a calendar buys is predictability, and we have not found that the absence of predictability hurts us. The thing a calendar costs is the freedom to publish what we actually learned this week, rather than what we said in October that we would learn by April. That trade is the one we keep choosing.
If we ever start writing posts that somebody else picked the topic of, we will know. They will sound generic in a way that is hard to fix after the fact. We will go back to reading the tickets.