Outcomes Automation / Doctrine
A system should not need its builder.
What twenty years of proposals, a year of utility production, and running our own contracting companies taught me about operational automation. By Joshua Hill.
I have spent most of my working life doing two jobs at once. For more than twenty years I wrote proposals, capability statements, and government bids, the documents where a wrong rate or a missing section costs the contract. The whole time, I was also a software engineer. For years those two skills ran side by side and rarely touched.
They finally met when I started automating my own work. First the document practice: two years building tools around right-of-way scopes of work, then sixteen months engineering them into one pipeline that now produces priced scopes every week for a land-services firm under contract to a major electric utility. Then the trades: my family and I own a licensed general contractor in Washington and run painting and flooring companies under it, and I built the lead, estimating, proposal, and follow-up systems those companies run on.
Building for yourself is a different education than building for clients. When my own crew loses a lead or my own scope goes out with a wrong number, I pay for it. That pressure produced a short list of principles I now refuse to build without. This page is that list.
1. Prove it in production, not a demonstration.
A demo is a promise. Production is a record. Anything I offer a client has to have survived real inputs first: real leads, real estimates, real customers, real deadlines, on work where I carry the loss if it fails. The document pipeline earned its place by running every week for over a year. The contractor systems earned theirs on our own jobs. If a system has only ever worked in a walkthrough, it is not finished, and it is not for sale.
2. Build judgment into the workflow.
Most automation fails not because the model is weak but because nobody put the judgment in. The pipeline that prices a scope of work carries twenty years of knowing which rate is wrong and which section is missing. The estimating system carries what our crews actually burn in labor and materials. Automation without embedded judgment is just fast guessing. The slow part of my work is encoding what a careful person would check; the software part is comparatively easy.
3. Escalate exceptions instead of pretending they do not exist.
Every real workflow produces cases the system was not built for. The honest design assumes that and routes the exception to a person, visibly, instead of forcing it through and hoping. A lead with a half-typed phone number, a scope that references a document nobody sent, a quote request outside the service area: those go to a human queue, not into a confident wrong answer. A system that never says "this one needs a person" is not mature. It is hiding.
4. Put a human at consequential release points.
Some actions are cheap to undo. Some are not. Anything that commits money, signs a customer, or leaves the building under a company's name gets a human set of eyes before it goes. In the document practice that is a reviewer signing off on every scope. In the trades it is an owner approving every proposal before a customer sees it. Automation earns trust by doing the drafting, the sorting, the chasing, and the remembering, and by leaving the commitments to people.
5. Leave the client owning the accounts, the data, and the system.
I have watched agencies hold websites, ad accounts, and customer lists hostage, and I have been the person hired to untangle it. So this is fixed policy: everything we build sits in accounts the client owns. If we part ways tomorrow, the site, the data, the phone number, and the pipeline stay behind and keep working. A system should not need its builder. That sentence is the whole doctrine, and it is also the test: the goal of every engagement is that my absence would be an inconvenience, not an outage.
Why this is the same business twice
People ask why one practice produces right-of-way scopes for utility work and also builds lead systems for painters. The answer is that they are the same machine pointed at different paperwork: capture the inbound, apply encoded judgment, produce the document or the response fast, put a person at the release point, and keep a record of everything. The utility work proves it holds up under enterprise standards. The contracting companies prove it holds up when the phone rings at dinner. Outcomes, not hours, in both rooms.
If that is how you want your operation to run, both doors are open.