When custom systems stop being trusted.
It isn’t a single incident. It’s a condition that compounds — through staff changes, undocumented dependencies, deferred updates, and workarounds nobody intended to become permanent.
Operational decay: the gradual deterioration of an operational system after handover — when the knowledge, ownership, and design intent that made it work at launch quietly erodes until something breaks or someone leaves and the gap becomes visible all at once.
Operational decay is not a technical failure. It’s a design failure. And it’s preventable — if ownership is treated as a design constraint from the start.
The build
A team builds something to specification. It works. The demo is successful. Everyone is satisfied. The build team considers it done.
The handover
The system is handed over to the operation. Documentation is written but incomplete. Training happens once. The build team moves on to the next project.
The drift
Six months later, the system has drifted from its documented state. Workarounds have accumulated. The person who understood how everything connected has changed roles. Nobody is quite sure who owns it.
The exposure
Something breaks. Or someone asks a question the operation can't answer. Or the organisation tries to scale the system and discovers its architecture was never designed for that. The cost becomes visible all at once.
Operational decay is medium-agnostic.
It happens in hardware deployments, software platforms, and automated workflows. The manifestation is different. The root cause is the same.
Installed, not integrated
Shipped, not sustained
Triggered, not trusted
Is a system you depend on already drifting?
Six questions about one system you rely on. If more than two land, the decay is already priced into your operation — you just haven’t been invoiced for it yet.
Decay is preventable — and recoverable.
If you’re building, ownership belongs in the design. If you’ve already inherited something fragile, the first move is understanding what you have — not a rebuild.