You Cannot Fix What You Cannot See
You have a goal now, and a half-built system aimed at it. The temptation is to start improving immediately, to grab the part that feels weakest and make it better. Resist that for a few chapters, because acting before you can see the whole system is how people pour effort into the wrong place. The first move in changing any system is not to change it. It is to see it, completely, laid out in front of you, every part and every connection made visible. Only then can you tell what actually needs to change.
before you improve a system, you must see it.
This is the beginning of what this book calls the audit, the diagnostic half of the work, and it has one governing rule: before you improve a system, you must see it. Most systems resist being seen, not because they are complicated but because you are inside them, running them by reflex, and the parts you operate automatically are exactly the parts you have stopped noticing. Decomposition is how you drag the whole thing into view.
You cannot fix what you cannot see. So first, drag the whole system into view.
The Ladder, Walked Downward
You already know how to do this, because it is the second book’s skill run in reverse. There you built upward: chunks combined into modules, modules assembled into a finished whole, small parts composed into something larger. The ladder went up. Here you climb the same ladder in the other direction. You take the finished whole and break it back down into the modules it is made of, and the modules into the chunks and steps inside them, until you reach pieces small enough to actually examine and change.
It is the same ladder and the same relativity of altitude you learned before. A thing is a whole when you look down at its parts and a part when you look up at what contains it. The difference is only your direction of travel. Building, you fuse parts into wholes and stop looking inside them, which is the right instinct when you are trying to make something. Diagnosing, you do the opposite. You pry the wholes back open and insist on seeing the parts again, because the thing you have stopped looking inside is precisely where the problem is hiding. A working part disappears into the whole; that is what working means. To find the part that is not working, you have to refuse to let any of them disappear.
Mapping the Parts and the Flow
A decomposition has two halves, and most people do only the first. The first half is listing the parts, which is the easy half. You write down everything the system is made of, every component and stage, until the inventory is complete. The course is its lessons, its enrollment, its delivery, its grading and responses, its feedback collection, its end-of-term update. Laying those out in a row already tells you more than you knew, because much of it you had never actually listed; you just did it.
The second half is the one that matters more and gets skipped: mapping the flow. A system is not its parts, it is its parts plus the way work moves between them, and you cannot see a system by looking only at the pieces any more than you can understand a sentence by listing its words. So trace the movement. Ask the question from Chapter 3, what moves through this, and follow it part to part. A student moves from an advertisement to a sign-up to a welcome message to the first lesson to the second, through to completion. Their questions move from confusion toward you and, sometimes, toward an answer. Their feedback moves, or fails to move, from the end of the term back toward the material. When you draw the flow and not just the inventory, the system stops being a list and becomes a map, with arrows, and arrows are where the next chapters do their work.
The Steps You Stopped Seeing
Here is where decomposition earns its keep, because a thorough one always turns up parts you forgot were there. These are the hidden steps, the small manual actions you perform so habitually that they have become invisible to you, and they are invisible precisely because you are the one doing them. The system depends on them, but they appear on no list, because they live only in your hands and your memory.
Watch for them as you map. Every term, you personally send the reminder the day before a lesson is due, a thirty-second task you have never once thought of as a part of the system. You re-find a particular file that is never where you expect it. You answer the same three questions you answer every term, fresh each time, from scratch. You copy a roster from one place to another by hand. None of these is on the official map of the course, and all of them are load-bearing, and together they are a large part of why the whole thing collapses when you step away. The system collapses because those steps were never really built; they were just absorbed into you. The value of decomposition is that it forces these into the light, where you can finally see how much of the system has no existence outside your own ongoing attention. You cannot hand off, automate, or protect a step you have never even named. Naming it is the first thing that makes it real, and therefore changeable.
The Weakness Between the Parts
There is one more thing to look for, and it is the most easily missed because it is not a part at all. It is the space between the parts. When a system fails, the instinct is to inspect the components, to assume one of them is broken. But systems made of perfectly good parts fail all the time, and they usually fail in the gaps, at the handoffs, where one part passes work to the next and the pass goes wrong.
This is the distinctive lesson of working at the system level, and it is worth stating plainly. The second book taught you to build clean modules, strong and self-contained. This book is largely about the connections between them, because that is where the trouble actually lives. A course can have an excellent lesson and an excellent feedback form and still fail at the handoff between them, when the feedback the students give never actually reaches the lesson that needed it, so the same flaw survives term after term despite being reported every single time. Nothing there is broken. The lesson is good and the feedback is good. What is broken is the handoff, the connection that should carry one to the other and does not. As you map the flow, give the arrows as much suspicion as the boxes. Ask at every junction whether the thing that is supposed to move across actually does, or whether it gets dropped, delayed, or quietly lost in the gap. More of your system’s real weakness lives in those gaps than you expect, and none of it shows up if you only examine the parts.
Taking the Course Apart
Put it all together on the course, and watch a vague sense of this is exhausting resolve into a specific picture you can act on. Lay out the parts: enrollment, the lesson library, delivery, response, feedback collection, the update between terms. Draw the flow: how a student travels from sign-up to completion, how their questions and feedback travel back. Then add the hidden steps you just dragged into view: the manual reminders, the re-found files, the questions re-answered from scratch, the roster copied by hand. And finally mark the handoffs and test each one. Does the welcome actually reach every person who enrolls, or do some fall through? Does a student’s confusion in week three actually reach you in time to help them, or does it arrive as a complaint at the end? Does the feedback collected at the close actually reach the library before the next term, or does it die in a folder while you rebuild from memory anyway?
What you have now is not yet a set of fixes. You have something more valuable than premature fixes: an honest, complete map of the system, with its real parts, its true flow, its hidden manual dependencies, and its leaking handoffs all visible at once. For most people this is the first time they have ever actually seen one of their own operations whole, rather than feeling it from the inside as a stream of tasks. The exhaustion had a structure all along. Now you can see it. In the next chapter you stop looking at the whole map evenly and start hunting for the one part of it that matters most, because not everything on this map deserves your attention, and learning which part does is what separates real improvement from busywork.