Keep the person who built it

Why systems drift

Six weeks after Dana’s estimate system went live, the web form company added a field for “preferred contact time.” Sensible. The form now sent the system a piece of information it had never seen, in a spot where it expected the address.

Nothing crashed. The system kept drafting estimates. It just started putting “mornings” where the street should be, and the draft looked wrong enough that Dana began fixing addresses by hand and stopped trusting the rest.

That is drift. Not a failure, a slow return of the work to the owner’s desk, one small correction at a time, until the system is a thing that mostly works and nobody relies on.

The fix took the person who built it eleven minutes, because they knew where the address came from. It would have taken Dana an afternoon to even describe the problem to someone new.

What a retainer month actually contains

The word retainer makes owners nervous because it sounds like paying for nothing. Here is what a month looks like when it is done properly.

A short brief. One screen, sent most weeks, saying what the system handled, what it held for approval, what it got corrected on, and anything that looks off. Quick to read, safe to skip. This is how the owner keeps the picture without keeping the work.

Corrections folded in. Every time Dana edits a draft, that edit is a lesson. Someone has to read the edits and decide which ones are a one-off and which ones mean the rule should change. That is the job. Left alone, the corrections pile up and the drafts stop improving.

Breakage fixed before it is noticed. The address field is the example. The person on retainer watches for the shape of the output changing, which is how drift shows up, and fixes it the same week.

One small improvement. Not a new build. The next step from Chapter II’s list, or the approval line moving one notch, once the drafts have earned it.

Nothing else. No monthly meeting for its own sake. If the brief says nothing is wrong and you have no changes, that month costs you almost nothing.

The brief

The brief deserves its own section because it is the one piece of the arrangement the owner touches.

A bad brief is a report. Numbers of things done, charts, a paragraph that could describe any week. Owners stop reading those in the second month.

A good brief is written to be skipped safely. The first line says whether anything needs you. If nothing does, you can stop there. Below that, in plain sentences: what ran, what waited and why, what got corrected, and one thing worth knowing. Dana’s brief from the address week said, in its first line, “Three estimates had the wrong address, fixed Thursday, check the ones you sent Tuesday.” That is the whole value of the thing.

When to add the next piece, and when to stop

The temptation after a good build is to automate the next five things. Do not.

Add the next piece when two things are true. The current system has run for a month with fewer than a handful of corrections. And the next item on the shortlist still keeps landing on your desk. If either is false, wait.

And if you want more than the next small step, say so. A second system, a bigger build, a whole new part of the week handed off: that is a conversation, not a ticket, and it starts with the same diagnosis as the first one. The retainer grows with what I am looking after, and you see the new number before anything gets built.

Stop when the shortlist is empty. This is worth saying plainly because most people selling automation do not. There is a point, often after three or four builds, where the work that remains on the owner’s desk is the work that should be there. Estimates that need judgment. Hiring. The bank. A retainer at that stage shrinks to maintenance, which is a smaller number, and that is the right outcome, not a lost sale.

What you should own outright

Everything. This needs to be in writing before the build starts.

The system runs in your accounts. The rules it follows are written in a document you can read. The drafts it produces are yours. If the arrangement ends, the system keeps running in your tools and you have the document that explains it. Someone else could pick it up.

Be suspicious of any arrangement where the system lives somewhere you cannot log into, or where ending the retainer means the work stops. That is not a system you bought. It is a subscription with a person attached.

Common mistakes

Treating “it works” as the end. It is the middle. Plan for the change you did not plan for.

Skipping the brief because things are fine. The brief is how you know things are fine. The week you skip it is the week the addresses go wrong.

Handing maintenance to whoever is free. The person who built it fixes drift in minutes. Anyone else starts by reading the whole thing.

Paying for a monthly meeting. If nothing is wrong, the month should cost you almost nothing. Insist on that.

Where to start

If you read all four chapters, you have a way to sort your week, a way to diagnose what keeps coming back, a rule for where a build should live, and a picture of what the months after look like.

The first step is still the smallest one. Thirty minutes, on a call, talking through where your week goes. I write down what keeps landing on your desk. You come away with the list from Chapter I whether or not we ever work together.