Filling Gaps and Adapting on the Fly

Gaps Are Normal

Everything in this part has assumed you have the module you need. Often you will not. You design a project, mark the slots, go to your library, and find that one slot has nothing to fill it. There is a gap. This is not a sign that the method is failing; it is the ordinary condition of doing new work. No library is ever complete, because every project asks for at least one thing you have not made yet. The question is not how to avoid gaps. It is what to do when you hit one, and how to make sure you only ever hit each one once.

The good news is that a gap, seen through the lens of this book, is small and specific. It is not “this whole project is beyond me.” It is “this one slot needs a part I do not have,” and a single missing part has a short list of sensible responses. Because you designed at the module level, you can see the gap precisely, which is exactly what makes it manageable.

The Four Responses

When a slot has no module to fill it, you have four moves: build, borrow, adapt, or cut. Most gaps are handled by one of them, and choosing well is mostly a matter of reading the gap.

Build is the default and the most valuable, because it grows your library. You make the missing module from scratch, the way Part II taught, clean and self-contained so it serves not just this project but every future one. Build when the missing piece is genuinely yours to make and likely to recur.

Borrow is faster when the missing piece is not your distinctive contribution. Some parts of a project do not need to be original, a standard definition, a well-known fact, an established framework, and for those you can bring in an outside source rather than building from nothing. Borrow when the piece is common knowledge and reinventing it would add nothing, but borrow honestly, with attribution where it is due, and make sure the borrowed piece still meets your standard for a clean module.

Adapt is swapping in something close. You may not have the exact module the slot needs, but you have a near neighbor, and a modest repackaging makes it fit. This is the three moves working together, the combination from Chapter 4: you take an existing module and adjust the package, or swap a chunk or two inside it, until it does the new job. Adapt when you are most of the way there already. Borrow reaches outside your library; adapt reaches inside it for the nearest useful neighbor.

Cut is the response people forget, and sometimes it is the right one. A gap can be telling you the slot should not exist. If the project holds together without that piece, removing the slot is cheaper and cleaner than filling it. Cut when the gap reveals that the slot was never load-bearing in the first place.

In a line: build what is yours and likely to recur, borrow what is standard, adapt what is close, and cut what was never needed.

Adapting on the Fly

Not every gap appears while you are calmly designing. Some open in real time, in the middle of delivering, when you discover live that you are missing exactly the thing the moment needs. A room asks a question your prepared modules do not answer. A talk runs short and needs another beat. Here the four responses still apply, just faster and rougher.

On the fly, you usually adapt or borrow, because building clean takes time you do not have mid-delivery. You reach for the nearest module you do have and re-aim it on the spot, or you pull in a known fact to bridge the moment. The skill is the same one this whole book builds, seeing your material as movable parts, which is precisely what lets you rearrange under pressure instead of freezing. Someone who carries their work as a monolith has nothing to adapt when the unexpected hits; someone who carries it as modules has an inventory to improvise from. A comedian missing a closer reaches into the hour for a bit that can end the night. You do the same with whatever the moment opened up. The improvisation feels like magic from the outside and is really just selection and adaptation done quickly, from a stock of clean parts. Afterward, do not let the improvisation vanish. If the adapted answer worked, capture it, clean it, and bank it like any other gap-fill.

Bank What You Build

Here is the discipline that turns gap-filling from a cost into an investment, and it is the most important habit in the chapter. Whatever you build to fill a gap, you bank. You clean it up, make it self-contained, and add it to your library, so the gap is filled once and never again.

This is what keeps the method compounding instead of plateauing. Without banking, every project’s gaps are paid fresh; you build the missing lesson for this course, use it, and let it dissolve back into the project, so the next course that needs it finds the same empty slot. With banking, each gap you fill is permanent. The missing lesson you built for this course becomes a module in your library the moment you finish it, and the next project that needs it finds it waiting. Over time this means your gaps shrink. Early on, much of every project is gap, because the library is small. As you bank what you build, project after project, the library fills, and a larger and larger share of each new project is selection rather than construction. The work gets easier not by accident but because every gap you ever filled stayed filled.

Note what this does to the feeling of building from scratch when you must. Building a new module is no longer pure cost for this one project. It is also a deposit. You are paying once for an asset you will draw on for years, which makes the effort of building clean, rather than just good enough for today, obviously worth it. The banking is where Part II and Part IV close the loop: you build clean so you can bank, and you bank so you never build the same thing twice.

Worked: A Gap, Filled and Banked

See the whole pattern in one project. You are building a course on financial security and your module map has six slots. Five you fill from inventory. The sixth, a lesson on choosing the right insurance, is a gap; you have never built it.

You read the gap. It is genuinely yours to teach, and it will certainly recur in future courses, so this is a build, not a borrow or a cut. You build the insurance lesson clean, the Part II way: selected chunks, one clear job, settled order, light connective tissue, your voice in it, self-contained. You drop it into the course’s open slot, write the bridges, and the course is done. But you are not quite finished, because the most valuable move is the last one. You bank the lesson. You file it in your library by the job it does, so you can find it later by purpose, not just by topic. Six months on, a different course needs that same insurance lesson, and this time there is no gap. The slot that cost you a full build last time costs you a selection now. One gap, filled once, closed forever. That is the engine of the whole method running through a single chapter.

A Gap Is Information

One last shift in how to see gaps. A gap is not only a problem to solve; it is information about what your library is missing. A gap you hit once is just a slot to fill. A gap you keep hitting, the same kind of missing piece showing up across project after project, is your work telling you exactly what to build next and build well. Those recurring gaps are the highest-value modules you can make, because each one will close many future slots at once. So pay attention to which gaps repeat. Rather than filling them grudgingly each time, treat the pattern as a build list, the map of where your library most needs to grow. Handled this way, gaps stop being interruptions and become the guide to what is worth building, pointing your effort at the modules that will pay back the most.

What Comes Next

That completes Part IV, and with it the three moves in full. You can combine, repackage, and swap; you can see projects as arrangements, select from inventory, pull modules across projects, swap at any altitude, and, when there is a gap, build, borrow, adapt, or cut, banking whatever you build so the gap never returns.

Everything so far has assumed a library worth drawing on, and we have kept gesturing at it, file by the job, keep one source of truth, bank what you build. Part V finally makes the library itself the subject. It is the asset that quietly compounds underneath all of this, and it deserves direct attention: how to build it, how to maintain and version what is in it, how a module can become a tool, and how a machine can help you assemble and repackage at speed. We begin with the library itself, the inventory that turns everything in this book from a technique into a way of working.