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 makes it worth reading.

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

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

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 chapter is unbounded. The quality is contested, mostly by you, at 11pm. And four hours can produce a worse draft than the one you started with, which almost 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 mostly true, which is why it lasts. The tool is useful. It will help. Some of it pays off. In the moment, you cannot tell which part is investment and which part is a very sophisticated way of not starting.

The deploy script took six hours and saved forty. That one was correct, and I would do it again tomorrow. The blog theme took 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.

Both felt the same in the moment and ended in opposite places, and the feeling is the only signal you get while you are inside it.

The same thing happens to teams

Scale that up and you get an organisational default.

An organisation decides it needs to build capability, which is 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 avoiding the question: 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, the way I converged on the blog theme.

What I do about it now

I have not cured it. 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 to count it as a writing day?

If the honest answer is "a working script", fine. That is a tooling day, and tooling days are allowed. The damage comes from having one and filing it under writing.

Ben's post is here.