The temporary fix that quietly became permanent

Most organizations have arrangements that began as temporary. A spreadsheet created because the proper system will not be ready for another month. A manual approval step added during a difficult transition. A small script written to keep two systems talking until a migration is completed. An old system kept running for a little longer because one team still needs something from it.

At the time, each of these decisions makes sense. The problem is real, the deadline is near, and the proper solution is not yet available. A temporary fix is the reasonable thing to do. Nobody is pretending it is ideal. Everyone understands it is not permanent.

That is the part we tend to remember: the reason the arrangement existed in the first place. What we remember less clearly is the point at which the original reason stopped being the reason.

The problem passes. The transition ends. The migration is completed, or at least declared complete. The new system is in place. But the temporary fix is still there. It has become part of how the work is done.

People get used to it. The colleague who created the spreadsheet has moved to another role. The person who added the approval step has left. The script is mentioned occasionally in meetings, but nobody can quite say who owns it. Nobody is sure who would switch it off, or what would happen if they did.

New employees learn the process as it is presented to them. They do not know it was once temporary. They copy the spreadsheet every Friday. They send the report through the approval channel. They run the script because that is how the figures are produced. The arrangement has passed from exception into custom, and from custom into routine.

After a while, other work begins to depend on it. A report is built from the spreadsheet. A downstream team waits for the approved file. A dashboard draws from the script's output. The temporary fix is no longer just a workaround. It has become infrastructure in practice, even if nobody has called it that.

That is the strange point. The arrangement was introduced because it was not supposed to last. Then it lasted. Then it became hard to remove, not because anyone decided it should stay, but because no one encountered a clear moment when it should be reconsidered.

Sometimes you will see a person try to raise the question. Why are we still doing this? The answer is usually practical. We still need it. Switching it off is risky. It works, so why touch it? These answers are not wrong. They are simply answers to a different question than the one that was asked.

The question was not whether the arrangement works. The question was whether it is still the arrangement we would choose. But that question is harder to ask once the temporary fix has settled into the shape of the work. It is harder still when nobody can reconstruct what would happen without it.

An old system kept running for a little longer is one of the clearest examples. At first, a little longer means a few months. Then it means until the next release. Then it means until the other team finishes their migration. Eventually, nobody remembers what a little longer originally meant. The system is just running. It has been running for years. People have stopped asking when it will stop.

The same thing happens with the small script. It was written to bridge a gap. It is a thin piece of code that translates one format into another, or checks a file, or sends a reminder. The bridge was supposed to be temporary. But the river has changed, and the bridge is now part of the road. Switching it off would require someone to decide that the gap is no longer there. That is a different kind of decision than the one that created it.

Even the spreadsheet has a similar trajectory. It begins as a stopgap. Someone fills it in each week because the real system is not ready. Then the real system is ready, but the spreadsheet has acquired columns that the real system does not have. Or people have grown used to the view. Or the data in the spreadsheet has become slightly different from the data in the system, and now both are needed to explain the difference. What started as a temporary measure has become a comparison point.

None of this is necessarily a mistake. The temporary fix may have been the right call. The problem was urgent. The permanent solution was unavailable. The organization had to keep moving. That is not poor judgment. It is simply the context in which most temporary things are made.

What is interesting is the afterward. The original conditions disappear, but the temporary fix stays. It gains weight. It becomes familiar. It becomes, in some small way, part of the organization's memory. And memory is not a reliable judge of what is still necessary.

There is a moment, usually unnoticed, when a temporary arrangement stops being temporary. It is not a meeting. It is not a decision. It is simply the point at which enough people have stopped remembering that it was ever supposed to be otherwise. After that, the arrangement becomes normal. Not good, not bad. Just normal.

That moment is hard to locate. If you look back, you can sometimes see where the conversation should have happened. But it did not happen, and the reason it did not happen is usually that nothing was broken. The arrangement was working. There was no failure to force the question.

So the temporary fix remains. It is maintained, updated, defended, and occasionally cursed. It is no longer a solution to a problem. It is part of the landscape. And landscapes do not announce when they have become permanent.