Some things fail all at once.

A component burns out. A company loses its largest customer. A relationship ends after a particular event. A software deployment introduces a defect and the service stops working.

Other failures are harder to locate because there is no moment when the thing clearly broke. What worked last year works a little less well this year. Responsibilities shift without anyone formally changing them. A workaround becomes routine. A rule remains in place after the conditions that produced it have changed.

Nothing is broken enough to force attention.

The thing simply drifts.

I've tended to think of drift as something systems should resist, but I'm less certain about that now. Preventing all drift would mean preventing adaptation too. An organization that operated exactly as it did twenty years ago might have preserved its original structure perfectly while becoming increasingly unsuited to the world around it.

Sometimes changing away from the original design is the healthy response.

That makes drift harder to evaluate than it first appears.

Suppose a small business develops an informal process because five people work together closely enough that everyone knows what's happening. Years later there are twenty employees, and people begin documenting decisions that were previously handled through conversation. The operation has drifted from its original form, but the change may be exactly what allows it to preserve something more important than the original process.

The form changed because the environment changed.

Now consider the opposite case. A temporary workaround is introduced during a busy period. Nobody removes it afterward. New employees learn the workaround rather than the intended process, another workaround gets built around the first one, and eventually nobody remembers why either exists.

That is drift too.

The interesting question isn't whether change occurred. It's what the change is doing.

Some systems have relatively easy answers because we know which properties they're supposed to preserve. If replicated data begins diverging between two machines that are supposed to contain the same state, we have a problem. If a clock drifts far enough from its reference, we can measure the difference. If a manufacturing process moves outside an accepted tolerance, somebody can investigate.

Organizations and relationships are harder because the reference itself can move.

A newspaper today shouldn't look exactly like a newspaper from thirty years ago merely to demonstrate fidelity to its origins. The available technology changed. Reader behavior changed. Distribution changed. The economics changed. Preserving the old form without asking what the form was accomplishing could destroy the very thing we were trying to preserve.

So we need some way to distinguish continuity from repetition.

That usually requires asking what mattered about the earlier arrangement.

Perhaps a process existed to prevent a particular error. Perhaps a role existed because information needed to pass between two parts of an organization. Perhaps a boundary was created after somebody discovered that combining two responsibilities produced a conflict.

If we recover the problem, we can evaluate the change against something more useful than tradition.

The old solution may still be the right one.

It may also have finished its job.

This is why drift can contain information. A workaround may indicate that the formal process no longer matches the work. Employees repeatedly ignoring a particular field in a form may mean they need better training, or it may mean the field no longer captures anything useful. Customers finding an unintended way to use a product may be creating a support problem, or they may be revealing a need the designers didn't anticipate.

Deviation doesn't tell us which interpretation is correct.

It tells us where to look.

The same caution applies to prevention. Rules, constraints and standards aren't signs that a system has become rigid. They often contain accumulated learning about failures that aren't obvious to the people encountering the rule today.

A guardrail prevents certain kinds of drift because somebody has already decided that some deviations are too expensive to rediscover through experience.

That's useful.

The problem appears when the guardrail can no longer be examined against the reason it exists. Now we have a rule protecting an unknown property from an environment that may or may not still contain the original risk.

Removing it blindly would be foolish.

Preserving it blindly isn't much better.

We need enough memory to ask why it's there.

This gives reflection a more modest role than I once gave it. Reflection isn't a special process through which a system sees itself and restores coherence. Sometimes reflection produces insight, and sometimes people sit around a conference table producing extremely sophisticated explanations for why they shouldn't change anything.

Looking inward isn't inherently corrective.

What matters is comparison.

What did we expect?

What actually happened?

What changed?

Which part of the earlier arrangement were we trying to preserve?

Does that still matter?

Those questions can be answered badly, but at least they give reality a way into the conversation.

This also changes how I think about feedback. Feedback isn't valuable merely because it exists. A customer complaint may reveal a genuine problem or an unusual preference. Employee resistance may expose a bad policy or resistance to a necessary change. A metric can improve because the underlying condition improved or because people learned how to optimize the metric.

Feedback doesn't interpret itself.

It becomes useful when we can compare it with other observations and remain willing to revise the explanation.

Over time, an organization can become better at doing this, although I hesitate to call that a kind of memory by itself. Some of it really is ordinary memory. People remember what happened. Documents preserve decisions. Procedures carry lessons forward. Records make it possible to compare current conditions with earlier ones.

Some of it is practice.

A team that has handled several failures may become better at recognizing which questions to ask during the next one. People learn which shortcuts created trouble, which alarms were meaningful and which apparently essential processes turned out not to matter very much.

That capacity isn't stored in one place.

Neither is it mystical.

It emerges from people, records, procedures, tools and repeated experience interacting well enough that the next problem doesn't have to be approached entirely from scratch.

The danger is that successful experience can create confidence faster than understanding. A system survives several failures and begins assuming its procedures are what saved it. An organization succeeds for ten years and mistakes the conditions surrounding that success for universal principles.

Memory can preserve bad lessons too.

So experience needs contradiction just as much as inexperience does.

Something eventually happens that doesn't fit what we learned before. The temptation is to classify the new case as an exception and protect the existing model. Sometimes that's correct. Other times the exception is evidence that the environment moved while our explanation stayed still.

Again, the deviation gives us a reason to look.

I think this is a more useful way to understand resilience than imagining a system that always finds its way back to some original orientation. Sometimes going back would be exactly the wrong thing to do.

After a failure, we may discover that there is no reason to restore the previous arrangement.

A relationship can survive conflict by changing.

A business can survive technological change by abandoning a process that once defined it.

Software can remain useful because dependencies drag parts of it forward that would otherwise become incompatible with the environment around it.

Continuity can require drift.

The harder problem is deciding what we're willing to let drift.

That decision can't be made once and inherited forever because the environment participating in the decision keeps changing. We preserve some boundaries deliberately. We allow other practices to evolve. Occasionally we discover that we protected the wrong thing.

Then we revise again.

None of this guarantees endurance. A system can observe carefully, learn intelligently and still encounter something it can't survive. A company can adapt well and run out of money. A relationship can contain genuine understanding and still end. A technology can be beautifully maintained until something better makes it unnecessary.

Resilience isn't immortality.

It is simply greater capacity to encounter change without losing the ability to respond.

That capacity requires some stability because there has to be something from which change can be noticed. It requires some flexibility because the response can't always be predetermined. It requires memory because otherwise every deviation appears new.

And it requires somewhere for contradiction to land.

Not so that every contradiction changes the system.

So that the system can tell the difference between a disturbance it should resist and information it should learn from.

Drift isn't automatically failure.

Sometimes it's decay.

Sometimes it's adaptation.

Sometimes it's ordinary variation that means almost nothing.

The work is learning which one we're looking at before we decide whether to pull the system back or follow where the change is leading.