The Only Project That Always Ships

In July, 130 commits touched the documents that tell me how to run my small studio — the strategy files, the decision gates, the operating principles. The one live product bet those documents exist to serve received 96. I did not notice the ratio while it was happening. I noticed it this week, because a book made me go count.

Here is the diagnosis I would rather not write down. The most reliable shipping project in my studio is the studio's own rulebook. Not the product, not the client work — the rules. And the reason is not that the rules matter most. It is that the rulebook is the only project that never waits on anyone.

Why the rulebook always ships

My real bet moves at the speed of other people. A partner has to review the materials. A client has to say yes to a pilot. This is by design — I chose a structure where someone else pulls the work forward, because on my own I stall. The cost of that design is dead air. Some weeks, everything I care about is parked in somebody else's inbox.

The rulebook has no inbox but mine. It never says no, never reschedules, never needs a follow-up nudge. A governance change completes in an afternoon, and it completes with the full feeling of strategic work — you are, after all, thinking about strategy. Running the studio as a git repository, with an AI that reads and edits the documents with me, removes even the friction that used to protect me: the AI formats, cross-references, argues back intelligently, and never misses a deadline. Revising my own operating system has become frictionless, productive-feeling, and infinitely available. Attention flows downhill, and downhill is wherever something completes.

The tell

The trap is hard to see from inside because every individual commit is defensible. I can defend most of the 130: several deleted rules rather than adding them, one caught a real labeling failure I had been living with for months. The documents genuinely improved. That is what makes the pattern dangerous — bad work announces itself, but good work on the wrong project reads as diligence from every angle except one.

The one angle is the ratio, and what it does when the main bet stalls. Blocked weeks should look quiet. Mine look busy — the governance stream absorbs whatever the waiting releases. At the end of July I even caught the pattern and imposed a moratorium on myself: no new rules, no new instruments, until the September review. Four days later I read a good strategy book, recognized my situation in its chapter on bad strategy, and sat down — with some excitement — to plan a redesign of the documents. The moratorium held on a technicality: what you are reading is that redesign impulse, redirected at something outside the rulebook.

An instrument, not a resolution

My own rules say that anything which depends on willpower fails, so the fix cannot be resolving to do better. It has to be an instrument — something that makes a sound when it breaks.

The one I have installed is a single question, scheduled for the September review: did the ratio invert? Over the next cycle, commits that advance the bet should outnumber commits that govern the studio. If they do, this summer's meta-work was consolidation — the system compressed, then got out of the way. If governance is still outshipping the work in September, then no amount of improved vocabulary changes the verdict: the evolution was displacement, and the rulebook is where the work went to feel finished.

I do not know yet which way it will go. The honest version of this essay has to end there — the instrument is installed, the reading is months out. But the count itself took one command and thirty seconds, which removes my last excuse for not knowing. If your main bet is waiting on someone else and you find yourself reorganizing the system that manages the waiting, run the count. The feeling of productivity will not tell you. The log will.