Building Systems

A system is a process whose output does not depend on who runs it. That definition is stricter than it sounds, and most of what companies call systems fail it. Documentation is not a system. Automation is not a system. A system has a trigger, a named owner, a defined output, some way to observe whether it ran, and defined behaviour when it fails. Building systems is the work of converting founder judgment into that structure, one decision at a time, and it is the only mechanism by which a company stops being a set of people improvising.

The five parts

• Trigger. What starts it. A date, an event, a threshold. If the answer is "someone remembers," you have a habit.
• Owner. One name. Shared ownership of an invariant means nobody owns it.
• Output spec. What good looks like, written down precisely enough that two people would agree whether it was met.
• Observability. A way to know it ran, and how often it did not. Unobserved processes decay silently.
• Failure path. What happens when the input is malformed or the step fails. For anything automated this is concrete engineering: idempotency so a retry does not charge twice, auth scoped so a failure cannot escalate, and a dead-letter queue so failed work is visible rather than gone.

Observe, standardise, automate — in that order

You cannot automate what you cannot see. Automating an unmeasured process hardcodes whatever it happened to be doing, including the parts that were wrong, and removes the human who was quietly correcting them on the way through. The errors do not stop. They stop being noticed.

Standardisation comes second: pick one way, write it down, eliminate the variants. Automation is cheap after that, because the expensive part of automation is variance, not code.

The corollary is the highest-return move available in most companies: delete steps rather than automate them. An automated step you should have removed is a permanent tax that reads as progress on a roadmap.

Where it goes wrong

The tool gets mistaken for the system. A CRM does not produce pipeline hygiene; it produces a place to keep the mess. The system is the definition of what a stage means and what happens when a deal sits in one past its expected age. The tool is only where that lives.

Systems also get judged on good days. The demo always works. What decides reliability is behaviour when the input is malformed, the upstream API is down, volume triples, or the owner is on holiday. Design for the failure you did not predict, or the true reliability of the system is the reliability of whoever happens to notice it broke.

The test that settles most arguments: if the person leaves and the output stops, it was a role, not a system. Roles are legitimate — some work should be judgment. But you can hire into a role, and you can only own a system.