You are at chapter nine. You are presenting a diagnostic framework that your client — a leadership team you have been working with since chapter 3 — is now ready to apply. But the framework requires a specific organisational setup that contradicts the starting-state description you wrote four chapters earlier. The company you described in chapter 3 cannot arrive at chapter 9 the way you wrote it.
You trace the thread. Four chapters reference a starting state you now need to revise. The change is not in the writing. It is in the structure. Knowing how to structure a book is not the same as knowing how to fill its pages.
Most authors discover their book's architecture after they have already built it. Software engineers learned not to do that forty years ago.
Marion wrote on Tuesday about the fear of starting — why the first chapter is harder than it looks, and what to do about it. This post is about what comes after you start: what you are actually building, and what it takes to build something that holds.
What a Book Actually Is
Two disciplines figured out the same thing long before publishing did.
Architects know a pile of materials is not a building. It has load-bearing walls, rooms that connect in a specific order, plumbing and wiring that route from one floor to the next according to a plan. Change where the stairs go and you change what is above and below them. The materials are the same; the structure is what makes them a building.
Software engineers know a folder of files is not a system. A codebase has modules, dependencies, shared state, interfaces. Change one module and you change everything that depends on it. The code is the same; the architecture is what makes it work.
A book works the same way. Specifically, it works the same way as both.
A business book, a case-study collection, a methodology guide: each contains frameworks, client stories, and profiled people. Each element has a state — a current condition that accumulates through the book and constrains what can come next. The framework you introduce in chapter 3 must still hold in chapter 8. The client you open with in chapter 2 must carry the same starting history when they reappear in chapter 7. The profiled leader who learned something in chapter 4 carries that learning into chapter 6. None of these elements are independent.
An outline is what you intended to build. The manuscript is what you built. Those two things are often not the same.
Two Failure Modes You Can Feel
There are two structural problems that appear in almost every manuscript I have seen in late-stage revision. They are different problems. They feel different. And they have different causes.
The first problem: when you change one thing and everything breaks.
In a consultant's book, a client case study in chapter 3 establishes a company's starting state: the leadership team composition, their operating model, their initial diagnosis of the problem. That setup carries through the rest of the book. The chapter 7 framework application depends on who the client team was. The chapter 10 outcome depends on the starting-state diagnosis. If you revise the chapter 3 setup — even a detail, even a job title — you have to chase every downstream reference, because every chapter that follows was written against that original version.
The same logic applies to people. A profiled leader appears in chapter 1 with a specific mindset and management approach — their way of thinking before the consulting engagement begins. By chapter 5, after the work described in chapters 2 through 4, they have changed. Their assumptions have shifted. Their language has changed. If you revise the chapter 1 portrayal, the transformation arc breaks. If a chapter 7 dialogue contradicts what chapter 5 said about their new approach, the reader notices — even if they cannot name why. Even in nonfiction, people carry state. Characters in business books are not decorative; they are structural.
This is what software architects call coupling — the degree to which one component depends on another. The question it teaches you to ask is simple: if I change this, what else breaks? A manuscript with tight coupling makes that list very long.
The second problem: when a single chapter is doing too many jobs.
A chapter that tries to introduce the HYBRID framework, illustrate it with a client case study, and simultaneously set up the next chapter's diagnostic methodology is doing three structural jobs at once. The reader feels confused. The editor says "this chapter is unfocused." They are both right — the chapter is unfocused because no single element has room to land.
This is cohesion — how well the elements within a single unit belong together. The test is simple: can you state in one sentence what this chapter needs to do? If the answer requires more than one main clause, the chapter has a cohesion problem.
These two failure modes connect to what reader analytics firm Jellybooks has measured across publisher tests: the average book completion rate is between 25 and 50 percent; fewer than 5 percent of books reach 75 percent completion; peak readership occurs at chapter 1 and declines across the early chapters. In late-stage revision, those structural problems show up as two things the author cannot always name: inconsistency (frameworks, client stories, and profiled people that drift because dependencies were never maintained), and lack of engagement (the sense that the book is not pulling the reader forward because the structural setup has not done its job). The reader-visible symptom is simply that they stop.
What the Data Says About Structure
In 2016, researchers at the University of Vermont (Reagan et al., EPJ Data Science) computationally analyzed 1,327 novels from Project Gutenberg's fiction collection for emotional arc shape. They used sentiment analysis to track how the emotional valence of a story rises and falls across its length, and found that these arcs cluster into six recognizable shapes.
The finding that matters for authors: particular emotional arc shapes correlate with higher download counts. The study measured downloads of free ebooks from Project Gutenberg — a proxy for reader preference when cost is not a factor. It is not sales data, but it is a measurement of what readers choose to pick up when the only variable is the work itself. And the pattern, broadly, is that structural complexity outperforms simplicity: stories with more complex arc shapes — those that fall and rise in ways that create multiple points of engagement — tend to attract more readers than stories built on a single linear arc.
The arXiv preprint is at arXiv:1606.07772, for anyone who wants to read the study directly.
What this means for a working author: structural shape is measurable, and it has measurable effects on reader behaviour. The emotional arc you build — whether planned or accumulated — is doing real work on your reader. Knowing that is the beginning of being able to shape it deliberately.
The Revision Discipline That Comes From Software
Building architecture is where the structural metaphor started. Software is where the revision discipline comes from.
Jeremy Hanson-Finger is a fiction author published by Invisible Publishing, a Canadian literary press. In 2017, he documented using Git — a version control system used by software engineers — to manage his novel.
Git is not relevant here as software. It is relevant as a discipline. The practice Hanson-Finger describes is this: every change to the manuscript had to be named before it was committed. Not just saved, but named. A message like "Reference Llew's bat in tub" forced him to articulate what the change was doing and where it would touch. He found that this discipline reduced continuity errors compared to his previous methods. It also had a secondary effect he did not expect: knowing that every revision was nameable and reversible freed him to make changes he would otherwise have avoided.
The structural insight is not about version control software. It is about what naming a change forces you to do. This applies equally to a novel and to a business book. When you write "revise client starting-state in chapter 3," you are committing to a single-purpose change — and implicitly asking where else that client appears. A well-named change tells you something about its reach.
Most authors revise in a different mode: a session, a read-through, a handful of changes, a new save. The changes accumulate. Their interactions are implicit. Nobody has named them. The author who discovers at chapter nine that four chapters need revisiting has been in that mode — and the problem was not that the change was necessary. It was that the change's reach was invisible until it was unavoidable.
The discipline is learnable without any software. Name the change before you make it. Ask what it touches. Make one change at a time. This sounds simple. In a 70,000-word manuscript in late revision, it is not simple at all — which is exactly why having a method for it matters.
How to Structure a Book: Four Practices
Four practices, transferable to any manuscript:
Before writing a chapter, name its structural job. One job, stated plainly. "This chapter establishes the client's starting state." "This chapter closes the argument for the diagnostic methodology." If the name has more than one main clause, the chapter needs to be split or the scope needs to change.
After every significant decision about a case study, framework, or profiled person, ask what it touches. A client's role changes. A framework gets refined. A leader's arc shifts. For each of these, write a brief list of the chapters downstream — the chapters that assumed the prior version. The list does not need to be complete. It needs to exist.
When something breaks, ask coupling or cohesion first. Is this a "too many things connect to this one thing" problem, or a "this chapter is trying to do too many things" problem? The answer shapes the fix. One calls for separating threads; the other calls for clarifying focus.
Structural revisions first, prose revisions second. There is no point tightening a paragraph you will later cut. Fixing where a chapter sits in the structure — what it does, what it connects — is architectural work. It belongs before the sentence-level pass. Architects fix the plan before the finishers sand the floors.
One more thing worth naming: a human editor is the structural review. When someone asks "why does this client appear here?" or "I lost the thread from chapter three," they are doing coupling and cohesion analysis without calling it that. That is the pair-programming equivalent — the structural check you cannot see from inside the thing you built.
The authors on our published books page include people who came to us specifically at the structural revision stage, when they had the words but not the architecture. The structural work happened in collaboration, chapter by chapter.
Where to Start If Your Structure Is Already in Question
Writing a book is a structural act as much as a creative one. Marion wrote on Tuesday about the courage to start. This is about the discipline to build something that holds once you have.
Most structural problems are not discovered when they are small. They surface at chapter nine, or in a developmental edit, or when a reader puts the book down without knowing why. The authors who avoid that point are not more talented writers. They are more deliberate architects.
If you are at the point where you have started writing and are wondering whether what you are building is structurally sound, I would like to hear about your project. A Book Positioning Report is one way to get structural clarity early — before the cost of fixing it compounds. Or if you would prefer a conversation first, book a free call and we can look at what you are building together.
Andrea Tomasini is founder and system architect of my-book.ai, where he leads the engineering and process design behind the service. He spent two years building the consistency and structural tracking system that sits behind every book project — and two decades before that helping organisations build better engineering systems, a discipline that turns out to apply to manuscripts as much as to software.