The close taught me to ship

I spent my twenties closing books. Reconcile the bank, chase the accrual that nobody wants to own, argue about which period a piece of revenue belongs in, sign it, send it. Do that every month for years and it stops being a task and becomes a shape you see in other things.

Then I moved into delivery, and everybody treated it as a career change. It was, on paper. In practice I had been running releases the whole time and calling them something else.

A close is a release

Here is what a month-end close actually is. There is a cut-off date. Before it, things can move. After it, they cannot, and anything you find later is a correction rather than an edit. There is a checklist that has to be completed in a specific order, because half of it depends on the other half. There is a reconciliation step where two independent records have to agree, and if they do not, you do not proceed on the assumption that they will. There is a review by someone who did not do the work. And there is a date somebody outside the building is waiting on, which does not move because you are tired.

Now read that again as a software release.

The vocabulary is different and the shape is identical. Cut-off is a code freeze. The dependency-ordered checklist is a runbook. Reconciliation is your test suite, or it should be. The independent review is a pull request that someone actually reads. The immovable external date is the client.

When I started scoping delivery work I kept reaching for accounting instincts and being slightly surprised that they fit. Acceptance criteria are just a definition of what “done” means agreed before the work starts, which is what a close checklist is. A programme decomposed into tracked items with owners is a trial balance for effort. The instinct to distrust a number that only one system knows about is the single most useful thing I brought with me.

The habit that transferred best

Accounting gives you a specific and slightly unusual relationship with being wrong.

In most work, being wrong is embarrassing and you move on. In accounting, being wrong is a thing with a size. You can measure it. It sits in a column and it does not go away because you feel bad about it, and it does not go away because you explained it well. The only thing that removes it is the correcting entry.

That is a strange discipline to carry into a room full of technical people, and it turns out to be extremely useful, because software has the same property and pretends not to. A number on a dashboard is either defensible or it is not. You either know why the two systems disagree or you are guessing. The gap between “the report says 400” and “I can walk you from the raw event to the 400” is the entire distance between a report and an audit trail, and most reporting never crosses it.

I have spent a good part of the last few years crossing it on other people’s behalf. Attribution gaps, conversions that exist in one platform and not another, migrations where nobody could say what the old system was actually doing. Every one of those is the same exercise: two records that should agree, do not, and somebody has to sit with it until they do.

What did not transfer

Plenty. Accounting rewards being exhaustively right before you commit, and software mostly rewards being roughly right quickly and correcting in public. I was slow for a while because of that. I wanted the answer before the meeting rather than in it.

Accounting also has a settled definition of correct that engineering does not. There is a standard. You can look it up, argue about how it applies, and be wrong in a way that is demonstrable. Almost no question in delivery has that. “Should this be one service or two” has no standard, and pretending otherwise wastes everyone’s afternoon. Learning which questions have a right answer and which only have a decision took me longer than any tool did.

Why I bother writing it down

Because the two fields talk about each other badly. Finance people describe engineering as chaotic, and engineers describe finance as bureaucratic, and both are describing the same instinct from opposite sides. The checklist is not bureaucracy. It is the thing standing between you and finding out in March what went wrong in November.

I would rather have the checklist.