Thirty hours on the blog theme, zero on the book

Ben Balter wrote up the pipeline he built to produce a book — the automation, the formats, the checks, the whole apparatus. The post is good-natured about how much of it was unnecessary, and that good humour is what makes it worth reading rather than merely relatable.

I read it on my phone, standing up, and felt personally attacked.

Because I have done this. Repeatedly. I once spent the better part of a week building a note-taking system so that I could think more clearly about a problem — and by Friday I had a beautiful system and had not thought about the problem once.

Why the tool always wins

Here is the thing nobody says out loud: building the tool is legible progress.

You can see the diff. The tests pass or they do not. The work is bounded, and at the end of an afternoon you can point at something that did not exist that morning. It feels like the good kind of tired.

Writing the actual chapter is none of those things. It is unbounded. The quality is contested — by you, mostly, at 11pm. And four hours can genuinely produce a worse draft than the one you started with, which is a thing that basically never happens to a build script.

Given a choice between an ambiguous task and a well-defined one sitting right next to it, most people take the well-defined one — and then describe it afterwards as necessary preparation.

The description is not a lie, exactly. That is what makes it durable. The tool is useful. It will help. Some of it genuinely pays off. You are just not able to tell, in the moment, which part is investment and which part is a very sophisticated way of not starting.

Look at the deploy script. Six hours in, forty out — that one was correct, and I would do it again tomorrow. Now look at the blog theme. Thirty hours, and I cannot point at a single thing it bought me except the pleasant sensation of having shipped something on a day when the real work was not going well.

Same feeling in the moment. Opposite outcome. And the feeling is the only signal you get while you are inside it.

The same thing happens to teams

Now scale that up, because this is not a personal quirk. It is an organisational default.

An organisation decides it needs to build capability — which is genuinely hard, unbounded, and slow. Six months later it has a platform, a content taxonomy, a governance model, three dashboards and a steering committee.

Every one of those artefacts is defensible in isolation. Together they are a very expensive way of not answering the actual question, which was: can our people do the thing they could not do before?

Ask that question out loud in a programme review sometime. Watch how quickly the conversation moves to how many people completed the modules.

Nobody in that room is being dishonest. The completions are real and easy to count. The capability is real and hard to see — so the room converges on the number it can defend, exactly the way I converged on the blog theme.

What I do about it now

I have not cured it. I want to be clear about that, because the tidy version of this essay would end with a framework and I do not have one.

What I have is one question, and I ask it before I open the editor: what would I have to show at the end of today for this to have been the writing day rather than the tooling day?

If the honest answer is "a working script", fine — that is a tooling day, and tooling days are allowed. The damage is not in having them. The damage is in having one and filing it under writing.

Ben's post is here. He finished the book, incidentally.

I am still on the theme.