Pacing Handbook

A client hired me to ghostwrite a book about a company switching from waterfall development to Agile. Sprint planning. Retrospectives. Standups. The daily mechanics of a methodology transformation. Similar territory to The Phoenix Project, which fictionalized DevOps principles into a novel readers actually finished.

The first draft was technically accurate and completely unreadable. It lingered on the methodology. Every Agile concept got its full explanation. Every sprint planning session got documented. The book knew everything about Agile and nothing about why anyone would keep reading.

I went back through and asked a simple question about every scene: is this story or is this documentation? The methodology explanations were documentation. The people arguing about the methodology were story. The manager who couldn’t let go of waterfall because it was the only way he knew how to feel in control. That was story. The team lead who’d seen Agile fail at three previous companies and was waiting for this one to collapse the same way. That was story. The sprint planning meeting where those two people were finally in the same room. That was story.

I compressed everything that served the documentation instinct. I expanded everything that served the narrative. I added dialogue wherever the text had been summarizing what people said instead of letting them say it. The book that had been a methodology manual became a novel about people under pressure making decisions they weren’t sure were right.

Same information. Completely different pacing. The difference wasn’t what the book contained. It was where the reader’s brain was allowed to live.

Pacing isn’t about fast or slow. It’s about identifying where reader attention wants to be and moving toward that instead of away from it. Documentation pulls readers out. Story pulls them in. The ratio between those two things is what readers experience as pacing, whether they can name it or not.

This handbook is what I learned. Not intuition. A system for measuring where reader attention is going, diagnosing why it’s failing, and fixing the actual problem instead of adding action scenes that don’t help.

Questions

The scene that convinced me the Agile book was working was a sprint planning meeting where the waterfall manager and the skeptical team lead were finally in the same room. Neither of them said anything about Agile directly. They argued about estimates, about who owned which decision, about what “done” meant. Every line of dialogue was about the methodology without ever naming it. Readers understood exactly what was at stake because the conflict was human before it was technical.

That’s what pacing does when it works. It finds where reader attention wants to live and builds the book there. The information is still present. The methodology still gets explained. But it arrives through people under pressure making decisions they aren’t sure are right, which is the only place any reader’s brain actually wants to be.

Part of the AI Writer’s Library Series. See also: Novel Handbook | Conflict & Tension Handbook