I keep noticing how many posts on this site exist only because something went wrong.
There is the day my own automation missed a day. There is the time I published every post twice, and then, because apparently once was not enough of a lesson, the time I deleted the post twice. There is the alarm I raised when nothing was actually missing, which is a post about a watchdog that worked exactly as built and still told me nothing worth knowing. And last week there was the milestone that had not happened, written on the same morning I nearly published a two month progress report twelve days early.
Five posts. Not one of them was on a calendar. All of them went up within days of the thing they describe.
That timing is deliberate, and a few people have asked me why I do not save these up and write one thoughtful piece at the end of the quarter instead. This is the honest answer.
Waiting turns the mistake into an anecdote
If I write it down the same week, I am still describing what happened. If I wait a month, I am describing my explanation of what happened, and my explanation is always more flattering than the event.
I can watch this happen in real time. Three days after something breaks, the version in my head has already acquired a reason. The reason is usually true, and it is usually not the point. "The scheduler fired while the machine was asleep" is a reason. "I built a system that could quietly do nothing and I had no way of knowing" is what actually happened. The first one is a fact about a laptop. The second one is a fact about me, and it is the only one of the two that changed how I build anything afterwards.
Give it a month and the second sentence is gone. Not because I am hiding it. Because I genuinely no longer remember it that way.
The fix is still ugly, which is the useful part
Publishing in the same week means I am writing while the repair is half finished. I cannot round the story off, because there is no round end yet.
That is uncomfortable and it is also the whole value. A post written after everything is tidy reads like a case study, and case studies are close to useless to anyone actually in the middle of the same mess. The parts worth reading are the ones I would have edited out later: the wrong first diagnosis, the fix that made it worse, the twenty minutes I spent certain the problem was somewhere it was not.
Nobody needs another clean story about a founder who had a small setback and learned a valuable lesson. There are enough of those.
It changes what I look at the next day
This is the part I did not expect when I started doing it.
Knowing I am going to write the thing down makes me look harder at it while it is happening. Not so I have better material. Because the act of having to explain it in plain sentences to somebody who was not there exposes the gaps in my own understanding almost immediately. I have abandoned at least three explanations halfway through writing them, gone back, and found the actual cause.
Something similar happened today, in a different context. I spent the morning on a guide about the consent rules for direct marketing in South Africa, and rather than reading a summary of the rules, I downloaded the gazetted form the law actually prescribes and read it.
The form has a tick box that says "give my consent". It has no box for refusing. But the rule it belongs to only lets you approach a person once, and only if they have not previously withheld consent, which means the whole thing depends on you having a record of the people who said no. The prescribed form gives you nowhere to write that down. The regulator's own guidance quietly tells you to add the missing option, without mentioning that it is filling a hole.
I would never have found that in a summary. Summaries reconcile their sources. They smooth over exactly the sort of gap that turns out to matter.
That is the same instinct as writing the failure down early. Go to the thing itself, before anybody has tidied it, including me.
What I do not publish
I should be straight about the limits, because "I publish my failures" is the kind of line that sounds braver than it is.
Anything with a client in it does not go up. Not anonymised, not softened, not later. Their business is not my content, and a story about someone else's operations is not mine to tell just because I was in the room. That rules out a decent share of the more instructive mistakes I have made this year, and I have made my peace with that.
I also do not publish the ones I have not finished being annoyed about. Not out of image management, but because the writing is bad. Anything written while I am still irritated reads as either defensive or performatively self critical, and both are a waste of a reader's time.
So what is left is a narrower band than the phrase suggests: my own systems, my own decisions, my own reasoning, written down while it is still slightly raw. That is a smaller promise than "radical transparency". It is one I can actually keep every week.
The reason underneath
I write these because the person I would most like to reach is someone about eighteen months behind me, who has just watched something break and has concluded that it broke because they are not really cut out for this.
The useful thing I can tell that person is not that I have solved it. It is that I am still finding the same class of mistake, in public, most weeks, and the business is fine. The mistakes did not stop. They just stopped being a verdict on me.
Which is easier to believe from someone who is still writing them down while the repair is unfinished than from someone presenting a clean quarterly summary.