Why do the same problems keep coming back, even after you fixed them? The short answer: the fix usually worked on what you could see, not on what caused it, and nothing in your head kept the earlier attempts side by side long enough to notice the repeat. A problem that returns is rarely bad luck. It is a pattern that has not been written down yet.
Three habits cause most repeats. You treat the symptom because it is quick. You try the same kind of fix again because it worked a little last time. And you meet each return as a fresh problem, so the history never adds up. A written record answers all three, which is the idea behind Problem Graph, a journal of problems and the solutions tried on them, drawn as a graph.
Why do the same problems keep coming back after a fix?
Systems thinkers have names for the shapes recurring problems take. One is called fixes that fail: a fix has an immediate positive effect, its side effects show up later, and the best remedy then seems to be the same fix again. Another is called shifting the burden. A simple solution with an immediate effect heals the symptoms, while the real source of the problem is overlooked because its remedy is demanding and shows no result right away.
Both shapes feel like progress. The pain stops, so you stop asking why it started. Weeks later it is back, and the quick fix is still the easiest thing to reach for. Each round makes the quick fix look more proven and the real cause look less urgent.
The same page notes that delays in systems lead people to misread the response to an action. When a problem returns a month after the fix, the link between the two is easy to miss. You remember that you fixed it. You do not remember that the fix was the same one that failed in spring.
Trying harder at the same fix
Chris Argyris introduced the idea of double-loop learning in the 1970s. He set it against single-loop learning: the repeated attempt at the same issue, with no change of method and without ever questioning the goal. Double-loop learning also questions the assumptions, goals and rules that led to the action in the first place.
The page puts one point plainly: the way a problem is defined and solved can itself be a source of the problem. If you define a messy kitchen as "I need to clean more", every fix will be a cleaning schedule. If the real cause is that there is no place to put the mail, no cleaning schedule will hold.
Single-loop fixes feel responsible. You are doing something, and doing it again. But when the outcome keeps coming out the same, effort is not the missing piece. The missing piece is a question about the fix itself: what did it assume, and was that assumption true?
Why memory hides the pattern
A recurring problem rarely comes back in the same clothes. Late to work on Monday becomes a missed train on Thursday, then a rushed call with a friend you had to cut short. Each one feels separate, so each one gets its own small fix.
Memory keeps the feeling of a problem better than its details. It keeps "mornings are hard" and drops which fixes you tried, in what order, and what happened after each. Without those details you cannot tell a new problem from an old one, and you cannot tell a fix that failed from one you never tried.
This is where writing helps. A line on a page does not drift. When the same line shows up for the third time, the repeat is in front of you instead of behind you.
A worked example: the Sunday night scramble
Take a problem many people know: every Sunday night you realise nothing is ready for the week, and you stay up late. Follow these steps on paper.
- Write the problem in one line. "Sunday night I am not ready for Monday and go to bed late." One line, a fact, no blame.
- List every fix you remember trying, with its outcome. Set an alarm for 8 pm: partly, it went off but you ignored it. A Sunday checklist: failed, you stopped using it after two weeks. Doing laundry on Saturday instead: worked for clothes, did nothing for food.
- Keep the failed fixes. Do not cross them out. A failed fix tells you which cause it was not.
- Ask what each fix assumed. The alarm and the checklist both assumed the problem was remembering. Saturday laundry worked because it moved the work, not because it reminded you.
- Look for related problems. Late Monday arrival and skipped lunches on Tuesday sit next to this one. All three share a cause: the week's prep has no fixed time slot.
- Try one fix aimed at that cause. Block one hour on Saturday afternoon for food and bags. Write its outcome after two weeks: worked, partly or failed.
Notice what changed. The first two fixes treated the symptom: forgetting. The last one treats the cause, which only became visible once the fixes and their outcomes were written next to each other.
Recording outcomes, not only attempts
A list of things you tried is half a record. The other half is what happened. Problem Graph gives every solution one of three outcomes, worked, partly or failed, and a solution that failed stays on the map as a failed solution instead of disappearing. That small rule matters. A fix that failed is the clearest evidence you have about where the cause is not.
"Partly" deserves its own attention. A fix that partly works is the most likely one to be repeated, because it seems almost right. When the same partial fix appears twice on the same problem, read it as a sign that it is treating a symptom.
For more on keeping the attempts themselves, see how to track what you tried to solve a problem, and for what a failed attempt can teach, how to learn from failed solutions.
Linking problems that share a cause
The strongest sign of a recurring problem is two problems that look different and share a cause. A list keeps them apart: one under work, one under home. Linking them puts the shared cause in plain view.
On a graph, problems that belong together can be linked even when they sit in different lanes, such as personal and work, so a pattern shows that a list would hide. You do not need special software to start. Draw a line between two problems on paper whenever one fix touches both, or whenever the same cause appears in both chains of why. When one problem has three lines going out of it, it is probably the root of the others.
Once the problems are linked, a single fix can be tried against all of them. If the Saturday hour helps Sunday night, Monday mornings and Tuesday lunches, it is aimed at the cause. If it helps only one, keep looking. For a step-by-step way to dig for that cause, how to do a root cause analysis on a personal problem walks through a chain of whys.
Frequently asked questions
Why does a problem come back after it seemed solved?
Usually the fix removed a symptom, not the cause. The cause stays in place, so the symptom returns, often in a slightly different form that makes it look new.
How do you tell a recurring problem from a new one?
Write each problem in one line and keep the lines. When a new line reads close to an old one, or the same fix shows up on both, you are looking at a repeat.
Is it a bad sign if a fix only partly worked?
Not on its own, but a fix that keeps coming out partly is often treating a symptom. Ask what it assumed about the cause, then check that assumption.
What is the difference between single-loop and double-loop learning?
Single-loop learning repeats an attempt at the same issue without changing the method or the goal. Double-loop learning also questions the assumptions and goals behind the attempt.
Breaking the cycle of recurring problems
Recurring problems survive on three things: a quick fix that hides the symptom, a fix that is never questioned, and repeats that are never seen together. Each has a plain answer. Write the problem down in one line. Record every fix with its outcome, failed ones included. Ask what each fix assumed. Link the problems that share a cause.
None of this needs to be clever. It needs to be kept. The third time a problem comes back, the difference between guessing and knowing is whether the first two attempts are still written somewhere you can read them.