The Same Fire, Again
Notice how much of your work is spent solving problems you have solved before. The same question, answered for the hundredth time. The same scramble before every launch. The same confusion appearing in the same place every term, met each time with the same patient explanation. You are good at solving these. That is the trap. Because you can solve them, you do, over and over, and the solving feels like competence when it is actually a symptom, the sign of a system that should exist and does not.
a recurring problem is often evidence of a missing system.
There is a line that reorganizes how you see all of this, and it is one of the most useful ideas in the whole book: a recurring problem is often evidence of a missing system. A problem that shows up once is an event, to be handled and forgotten. A problem that shows up again and again is not really a series of separate events; it is a single structural gap, announcing itself repeatedly, that you have been treating as a string of unrelated fires. Every time you solve it as a fresh incident, you are mopping the floor instead of fixing the leak, and the recurrence is the leak telling you exactly where it is.
A problem that keeps coming back is a missing system, announcing where to build.
Why One-Off Fixes Recur
The reason these problems keep coming back is that solving an instance does nothing to the conditions that produce instances. You answer the question, and the question is answered, but the reason the question keeps arising, a confusing step, a missing piece of information, an unclear expectation, is untouched, so the next person hits the same wall and the question returns. The fix and the cause are at different levels. You are fixing outputs while the cause sits upstream, unbothered, generating more of them.
This is the bottleneck idea from earlier in the book wearing different clothes. A recurring problem is a place where the system has no loop, where a need arises repeatedly and there is no structure to meet it, so the need routes to the only general-purpose problem-solver available, which is you. Each recurrence is the system failing in the same spot and falling back on your manual effort to patch it. Seen this way, your recurring problems are a map. They mark, with great precision, every place your systems are incomplete, because a complete system would have absorbed that need into a loop and you would no longer see the problem recurring in the same predictable way. The fires are not random. They are clustered exactly where the structure is missing, and they will keep burning in those spots until you build something there.
Install the Loop, Not the Fix
The move, then, is to stop solving the instance and start installing the system, to respond to a recurring problem not by handling it again but by building a structure that handles that entire class of problem once and for all. This is a different reflex from the one most capable people have, and it is worth making deliberate, because the instinct to just quickly solve it is strong and, in the short term, cheaper. Installing a system costs more than handling one more instance, which is why it keeps getting deferred, and the deferral is why the problem is still here.
The recognizable examples make the move concrete, because you will see your own work in them. If you keep answering the same question, the missing system is a standing answer, a clearly written piece in a place people will find it, an addition to a lesson, an intake step that supplies the information before the question can form. If people keep missing deadlines, the missing system is not more reminding by you but a structure of triggers and reminders that fires on its own. If quality keeps varying, the missing system is a standard and a feedback step that holds the work to it, rather than your inconsistent personal vigilance. If the same confusion appears in the same place every term, the lesson itself is the missing system, and fixing it once removes the confusion permanently instead of explaining it away each time. And if every launch is chaos, the deepest reframe of all applies: the launch is not a project you keep doing badly; it is a system you have never actually built, and the chaos will recur exactly until you build it. In each case the pattern is identical. A recurring problem points at a missing loop, and the durable answer is to install the loop, not to get faster at the patch.
What Installing Costs and Buys
Be honest about the trade, because it is the reason this move is rarer than it should be. Installing a system is more expensive, right now, than solving the problem one more time. The standing answer takes longer to write than to say. Building the trigger takes longer than sending one reminder. The launch system takes real work to design, while muddling through the launch one more time is always available and always feels more urgent. So the missing system stays missing, because each individual instance is genuinely cheaper to patch than to solve structurally, and the structural cost always arrives in a week that is already full.
What that accounting misses is that the instance is not a single cost; it is a recurring one, paid every time forever, while the system is a one-time cost that ends the recurrence. The patch is cheap once and ruinous repeated. The system is expensive once and cheaper thereafter, because the recurring patch is replaced by a structure that only needs maintenance. Run the numbers across a year of the same fire and the math is not close, but you only see it if you stop pricing the problem as a single event and start pricing it as the ongoing tax it actually is. This is the same logic as everything else in the book: pay once to build the structure, and stop paying forever to compensate for its absence. The reason it is worth a chapter of its own is that recurring problems disguise their true cost so well, each instance small enough to absorb, that the total goes unnoticed until you deliberately add it up and realize you have been paying for the missing system many times over while telling yourself you could not afford to build it.
A Course Fire, Put Out for Good
Take the most familiar recurring fire from the course. Every term, in the first week, a wave of the same confusion arrives, the same handful of questions about how the thing works, where to find materials, what is expected, and every term you answer them, patiently, individually, in a flurry of repeated messages that eats your first week and depends entirely on you being available to send them. You are excellent at it. You have answered these questions so many times you could do it in your sleep, which is precisely the evidence that you should not be doing it at all.
Treat it as a missing system rather than a recurring chore and the solution changes shape. The questions cluster, which means they are not really many problems but one, a structural gap where students arrive without the information they need and route their resulting confusion to you. So you build the loop that should have been there. You create a clear onboarding that delivers exactly the information the questions ask for, before the questions form, placed where students will actually meet it, perhaps as a first lesson, perhaps as an intake step, perhaps as a standing resource the system points them to automatically. It costs you real work, once, more than answering another wave of messages would have. And then the fire is out, structurally, not because you got faster at fighting it but because you removed the conditions that started it. The next term, the wave does not come, because the need that caused it is met before it becomes a question, and your first week is free. Do this to one recurring fire and you have bought back a week every term in perpetuity. Do it to all of them, treating each recurring problem as the missing-system alarm it is, and the steady background burn of your work, the endless patient re-solving of things you have solved a hundred times, simply goes quiet, replaced by structures that handle those classes of problem without you. That quiet is what a fully built system feels like, and it is the difference between a life spent fighting the same fires and one spent building the things that make the fires impossible.