What is fixes that fail?

Fixes that fail is a system archetype. A solution works at first, which makes it look correct, but it also creates a delayed side effect that undoes the benefit. When the problem returns, people repeat the same fix, and the cycle gets stronger.

How it works

A balancing loop applies the fix and reduces the problem. A second, slower reinforcing loop creates the unintended consequence that raises the problem again. Because of the delay, the early result looks like a success. The pattern is common in cost cutting, where cuts bring savings today and quality losses later. The way out is to look for the delayed effect before acting, and to ask what the fix will do after the first improvement.

To spot the pattern, track the problem metric for much longer than the fix takes to show results. A drop followed by a slow return is the signature, and short review windows tend to hide it.

Example

Say a support team has a backlog of 500 tickets and closes tickets faster by limiting each answer to a template. Within a month the backlog drops to 300. But customers with unresolved questions reply again, and reopened tickets add 40 per week. After ten weeks the backlog is back at 500 or higher, and the team feels it must use templates even more. This is an illustration with round numbers.

How to model it in Machinations

Draw the problem as a Pool, the fix as a Drain, and the side effect as a Source that feeds the Pool after a Delay. Link the fix to the side effect with a state connection. Play the diagram and chart the Pool, then lengthen the Delay with a Lever to see how long the false success lasts.