You Already Know Where to Push
The diagnosis is done, and it left you holding something rare: a single named target. The audit did not produce a list of everything wrong with the course; it produced one constraint, circled, and one highest-leverage change, named. That restraint was the whole point. Most people begin improving with a dozen vague intentions and spread their effort across all of them. You begin with one, which means the hard part, knowing where to push, is already behind you. What remains is to push there and only there, and to resist the pull back toward the easy, satisfying parts that the audit just told you do not matter.
That resistance is harder than it sounds, because the moment you sit down to work, the polished parts call to you. They are pleasant to improve and you are good at improving them. The discipline of this short chapter is to keep your hands on the one part the audit flagged, even though it is probably the boring or uncomfortable one, because a change to the constraint moves the whole system and a change to anything else moves nothing.
Push on the constraint, and only the constraint. Then expect it to move.
Three Things You Can Do to a Part
When you face the part you mean to change, you have exactly three moves, and naming them keeps you from defaulting to the first one out of habit. You can upgrade it, swap it, or remove it.
Upgrading is making the existing part better while leaving it in place: the same step, improved. It is the move people reach for automatically, and sometimes it is right, but it is also the most expensive and the slowest, so it should be a choice rather than a reflex. Swapping is replacing the part with a different one that does the job better: a new tool in place of the old, a different supplier, a different way of handling the step entirely. Because you built your system out of clean modules in the second book, swapping is safer here than it would otherwise be, since a well-bounded part can be lifted out and replaced without the whole system unraveling around it. And removing is taking the part out altogether, which people forget is even on the menu. Each of these acts on the same constraint; they are just different bets about whether the part needs to be better, different, or gone. Run through all three before you act, because the obvious move, upgrade the thing in place, is often the worst of the three.
Subtraction Is a Lever
Of the three, removal deserves its own moment, because it is the one almost everyone skips and the one that most often works. The instinct when improving a system is to add: another step, another check, another tool, another feature. But a system is not improved by addition; it is improved by whatever moves the result, and very often what moves the result is taking something out. A step that adds friction and little value is not neutral. It slows the flow, creates another handoff to fail, and demands maintenance forever. Cut it and the whole system gets lighter and faster at once.
This is worth holding as a principle, because it runs against the grain: simplify before you add. Before you reach for a new part to fix the system, ask whether an existing part could come out instead. The bloated course with too many lessons is not helped by a better lesson; it is helped by cutting the three that dilute it, so the ones that matter land harder and the whole thing moves faster from start to finish. Subtraction is a lever, and usually a cheaper and more powerful one than anything you could add. The best engineers and the best editors share this instinct. They reach for the delete key before the one that adds, because they know that most systems are not starving for more; they are clogged with parts that should never have stayed.
One Change at a Time
However you decide to act, make one change, and then stop and watch before you make another. This feels slow, and the temptation is to fix the constraint and three other things in the same sitting while you have the system open, but that temptation destroys the one thing that makes improvement reliable, which is knowing what worked.
Change five parts at once and the system shifts, and you have no idea which of the five did it, or whether two of them helped while a third quietly hurt and the net looked like a small gain. You have improved nothing you can repeat, because you cannot tell cause from coincidence. Change one part and the next cycle gives you a clean reading: this moved, and only this could have moved it. This is the same logic as the feedback loop from the last chapter, applied to your own interventions. You are running an experiment on the system, and an experiment with five variables changed at once answers no question at all. There is one more discipline inside this one. When you measure the effect, measure it at the level of the whole system, not the part. The point was never to make the part better in isolation; the part can improve while the system does not. The only measurement that matters is whether the result you set as the goal actually moved.
The Constraint Will Move
When you improve the constraint, the constraint does not disappear; it moves.
One thing to expect before you start, because otherwise it will feel like failure when it is actually success. When you improve the constraint, the constraint does not disappear; it moves. You widen the narrowest pipe, and now some other pipe is the narrowest, and the part that was fine last cycle is suddenly the thing capping the result. This is not a sign you fixed the wrong thing. It is the sign you fixed the right one, because the cap moved to a new place, which only happens when the old cap is genuinely gone.
This is why improvement is iterative rather than a single triumphant repair, and why the audit had to be a repeatable tool rather than a one-time look. You change the constraint, you let the system run, and then you audit again, and the audit points at a new part, because the system you are looking at is no longer the system you diagnosed. People who do not expect this get discouraged at exactly the wrong moment. They make a real improvement, see a new problem appear, and conclude that nothing worked, when in fact the new problem is the trophy. The work is not to find the one constraint and kill it forever. It is to keep finding whatever currently caps the result and to keep moving the cap, cycle after cycle, so the whole system rises by stages.
One Change to the Course
Take it to the course, where the audit circled a single constraint: the operation runs entirely on you. You will not fix that with a grand redesign. You will pick one part of that dependence and make one move on it.
Say you choose the swelling pile of repeated questions, the part of the response load that lands on you every term. Run the three moves before acting. You could upgrade your answering, getting faster at the same manual replies, which leaves the constraint fully intact and just makes you a quicker bottleneck. You could swap the manual answering for something that handles the repeats without you, a standing resource that fields the common questions so only the genuinely new ones reach you. Or you could remove the cause of some questions entirely, if a confusing lesson is generating half of them, by fixing the lesson so the questions never arise. Notice that the removal option attacks the problem upstream and might be the cheapest of all. Choose one of these, make only that change, and then let a full term run and watch the right number, not how clever the fix feels, but whether your actual load came down and the term ran with less of you in it. If it did, you have proof, and you repeat the move on the next piece of the dependence. If it did not, you have learned something true and cheap, because you changed only one thing and the system told you plainly that it was not enough. Either way you are now improving on evidence instead of hope, which is the entire difference between tuning a system and merely fiddling with it.