Writing Operations

Deployment is not a handoff.

The standard shape of an engagement is build, deliver, document, leave. It produces a system that works on the day it is handed over and degrades from there, because the conditions it was built against move and nobody is watching the drift.

What moves is rarely the model. It is the inputs. A file format changes upstream. A team starts sending from a new address. A process that used to run monthly starts running twice a month during close. Each of these is small, and each of them silently reduces the fraction of work the system handles without a person.

So we operate what we deploy. Monitoring, correcting, tuning, in production, until the team is ready to take it โ€” and staying on afterwards if that is what is wanted. This is not a service upsell dressed up as a principle. It is the only arrangement under which the accuracy number we quoted at the start still means anything three months later.

The corrections are also the mechanism by which the system gets better. Every exception a person resolves is a labeled example of a case the system could not handle. Fed back, the ambiguous set shrinks. A system that is operated gets more predictable over time. A system that is handed over gets less.

The test of whether a deployment is finished is not whether it works. It is whether anyone would notice if it stopped.

Book a call

Tell us where the work piles up.

30 minutes. We tell you whether it's a fit and what the first phase looks like. No deck.

Book a call

Keep reading

More from the same shelf.