What Breaks Six Months After You Fix It

You fixed it. The process got documented, the automation got built, the dashboard got made, and for about two months everything worked exactly as intended.

Then you looked again at month seven and it had quietly reverted. Not dramatically — nobody announced they'd stopped using it. It had just eroded to the point where somebody was doing the manual version again, and had been for a while.

Founders read this as a discipline failure, usually their own. It isn't. Operational systems decay on a predictable schedule, through five specific mechanisms, and every one of them is a design problem rather than a willpower problem.

Here's what actually happens.

One: the field nobody fills in

Any system that requires a person to enter something that returns nothing to them will decay, and the decay curve is remarkably consistent. Six weeks of good compliance. Three months of partial. By month six the data is patchy enough that nobody trusts it, and untrusted data stops being consulted, which removes the last incentive to maintain it.

This is the most common failure and the most misdiagnosed. It gets blamed on the team, then on the tool, then on the training. The actual cause is that the exchange was one-directional.

A system that takes from the person feeding it and gives back to somebody else has a shelf life of about a quarter.

The fix isn't enforcement. It's making the system return something to the person entering the data — their follow-ups scheduled for them, their deals surfaced when they go quiet, their proposal assembled from the record. Entry stops being a tax and becomes the thing that makes their week easier.

Where that genuinely isn't possible, the capture has to ride along with something they were doing anyway. A conversation that happens in a system that records it is free. A conversation that requires a separate logging act is not, and no amount of insistence changes that.

Two: the process that grew an exception

The documented path handles the normal case. Then a client needs something slightly different, somebody handles it off-process, and it works fine.

That's not a problem. Deviations are frequently correct. The problem is that nobody recorded it, so nobody notices when it happens again, and again, and by month six the exception is running about a third of your engagements while the documentation describes a path that's increasingly theoretical.

The failure isn't the deviation. It's that there's no mechanism for the standard to learn from it.

A healthy exception rate is under a quarter. Above that, the process is out of date rather than being ignored.

Three: the thing upstream that changed

Someone renamed a field. A form got restructured. A stage got added to the pipeline. A tool updated something in an integration.

None of those are visible from where the downstream system lives, and none of them produce an error — the automation simply stops matching, or the report starts pulling a slightly different set, or the routing rule stops firing.

This is the one that produces genuinely invisible failure. A working automation and a dead one produce identical silence, so there's no signal at all until a client mentions they never got something.

The mitigation is an expectation check rather than an error alert. This should run roughly forty times a week; it ran zero; say so. That single instrument catches the entire class, and it's the cheapest monitoring you'll ever build.

Four: the person who was holding it together

Every new system has an informal owner in its first months — usually whoever built it or pushed for it. They catch the edge cases, they nudge people, they fix the small breakages before anyone notices.

Then their attention moves to the next thing, or they change roles, or they leave.

Nothing dramatic happens. The system just stops having someone who cares about it, and unowned things degrade. What made it work for six months wasn't the design; it was a person, and nobody wrote that down as a dependency.

This is why "who owns this" is a real question rather than a bureaucratic one. Not who built it — who is accountable for it still working in a year, and does that person know they are.

Five: the reason it existed stopped being true

The most legitimate failure and the one most likely to be misread as a problem.

Sometimes a system decays because the business changed and the system was solving something that isn't the constraint anymore. The check that was catching real errors is now catching nothing. The report that drove a decision is reporting on something nobody decides.

Left alone, these become worse than useless — they consume attention, they add steps, and they make people cynical about process generally because they can see that some of it is pointless.

The right response is retirement, and it needs to be a deliberate act. Most operational bloat in a five-year-old business is archaeological: every rule was created in response to a specific failure, and none was ever removed when the failure stopped recurring.

The maintenance nobody budgets for

Here's what all five have in common. Every one of them is invisible at the moment of the build, and every one of them is cheap to address if somebody is looking.

Which means the missing thing isn't better systems. It's a review — quarterly is enough — that asks four questions of anything you've built.

Is it still being fed? Check the data, not the intention. Fields empty, entries stale, gaps in the record.

Is it still being followed? Count the exceptions and read the reasons.

Is it still running? Expected volume against actual, for anything automated.

Is it still worth it? What decision does this change. If the honest answer is none, retire it.

Half an hour, four questions, applied to the things you built this year. That's the entire maintenance layer, and almost nobody has it.

Build the systems as you do the work, not instead of the work — and then look at them again in ninety days, because the version that ships is never the version that survives.

The review, concretely

Half an hour a quarter is the whole prescription, and it works better with a fixed shape.

List what you built or changed in the last twelve months — not everything you own, just what's recent enough to still be settling. Ten to fifteen items is typical.

For each one, four checks, in this order because they get progressively more expensive to answer.

Is it running? Expected volume against actual, for anything automated. Thirty seconds if the instrumentation exists, and if it doesn't, that's the finding.

Is it being fed? Look at the data rather than asking. Empty fields, stale entries, gaps in the record. People will tell you they're using something; the data tells you whether they are.

Is it being followed? Count exceptions and read the reasons. Under a quarter is healthy. Above that, the process is out of date rather than being ignored, and the recorded reasons tell you how.

Is it still worth it? What decision does this change. If the honest answer is none, retire it — deliberately, with an announcement, because a quietly abandoned system leaves behind fields nobody fills and steps nobody skips.

The output is a short list: two things to fix, one to instrument, one to retire. That's a quarter's maintenance, and it's the difference between infrastructure and sediment.

Why this changes how you build

Once you accept that decay is the default rather than the exception, it changes what a good build looks like.

You stop optimizing for elegance and start optimizing for legibility — because a system somebody can understand in six months is a system that can be repaired, and one they can't is a system that gets replaced.

You write down what breaks if this stops, because that's the field that makes it possible to safely remove something later.

You give it an owner at the moment of the build, not when it fails.

And you build the smallest thing that could work, run it for a quarter, and then improve it — because the features people ask for before using something and the features they need after are reliably different sets.

That's what the Execution pillar means by cadence, applied to your own infrastructure rather than to client work. A great system doesn't just execute: it communicates. It tells you when it's thriving and when it's gasping — and most of what founders build does the first half of that sentence and none of the second.

The uncomfortable implication

If systems decay predictably, then a business that keeps building and never reviews is accumulating a layer of half-working infrastructure, and each layer makes the next build harder to reason about.

That's the actual cost of skipping the review. Not the individual system that reverted — the fact that in three years you'll have forty things in various states of decay, nobody will be able to say which ones matter, and the honest answer to can we change this will be I'm not sure what would break.

Half an hour a quarter is the price of that not happening.