What Document Control Taught Me About Writing Books
I have spent a significant portion of my professional life managing documents, revisions, approvals, changes, and the eternal question:
Which version is actually current?
So perhaps it should not surprise me that I eventually became a writer and publisher. Document control and writing overlap more than people might expect. In fact, a surprising number of document-control people I have worked with came from literature, writing, or other language-heavy backgrounds. My own degree is in literature and writing; one of my current coworkers studied French literature.
That makes sense when you think about what document control actually requires.
You need to understand information. You need to notice inconsistencies. You need to recognize when something changed, what else that change affects, and whether someone looking at the record years from now will understand what happened.
Writing books requires many of the same skills. It just involves more ghosts. ;)
A Book Has a Product Lifecycle Too
One of the biggest things working around engineering has taught me is that very little goes directly from idea to finished product.
Products move through phases. It starts with a concept or design phase, where someone determines what the thing is supposed to be. Then comes some form of prototype: the first version that exists outside someone's head. Then testing. Testing often reveals that something does not work as intended, which may send the design backward into an earlier phase for revision. Eventually, if all goes well, the product reaches production. And even then, it is not frozen forever. There is sustaining work: corrections, updates, maintenance, improvements, and changes driven by new information. Eventually, there may be end-of-life and obsolescence.
Books are remarkably similar. The initial idea is the concept phase. The first draft is a prototype. Beta readers, critique partners, developmental editing, and revision are testing. Sometimes testing tells you the prototype worked beautifully. Sometimes it tells you that Act Two needs to be dismantled and rebuilt. Eventually the manuscript enters production: copyediting, proofreading, formatting, covers, retailer files, metadata, and all the other things that turn a story into a product someone can actually buy. And even after publication, there can still be sustaining work. Typos are discovered. Back matter changes. Links need updating. A new edition gets a different cover. A series develops and an older book needs to be brought into better alignment with what came later.
The lesson is not that nothing is ever finished. It is that finished means something different at each phase. A draft can be finished enough for developmental review. A manuscript can be finished enough for formatting. A proof can be finished enough for publication. Trying to make something “final” before it has passed through the appropriate phase is usually just another way of delaying the next test.
Change One Thing, Check What Else You Broke
Engineering changes rarely affect only one thing. Alter a requirement and another document may need revision. Change a drawing and a work instruction may no longer match. Replace a part and suddenly six references elsewhere are wrong.
Fiction behaves exactly the same way. Move a scene and the timeline may shift. Change a character’s motivation and earlier dialogue may stop making sense. Clarify a supernatural rule and discover that a scene three chapters earlier now violates it. Change a reveal and suddenly the foreshadowing needs to be adjusted in several places.
The actual edit may take five minutes. Figuring out everything else that edit affects can take considerably longer.
Document control trained me to ask: What else does this change touch?
That is one of the most useful revision questions I know.
Version Control Is Not Glamorous Until You Need It
Writers have a reputation for filenames like:
BookFinal.docx
BookFinal2.docx
BookFinalREAL.docx
BookFinalREALFINAL.docx
My professional background has not made me immune to version problems, but it has at least made me wary of them.
My usual system is fairly simple. When I start a manuscript or major working file, I date it. If I reach a point where I am making expansive changes that I might want to undo later, I save a new copy with the current date. The older version goes into an Old folder. That keeps the working directory clean enough that I can usually answer the most important question: Which file am I actually supposed to be editing? Usually.
Physical and digital editions complicate things.
An ebook and a print book may eventually need different files. A hardcover may have a different page count than a paperback. A cover file that was perfectly correct yesterday may suddenly have the wrong spine width because the interior gained two pages.
The more versions a project develops, the more valuable it becomes to know which one is the source of truth. That is document control thinking applied directly to publishing.
Traceability Matters More Than Memory
One thing I wish I did better in my writing life is formal traceability. In document control, a good change record should tell you not only what changed, but why. That matters because someone may be looking at that record ten years later.
One of the hardest things to teach engineers is that “updated drawing” is not a useful change description. What changed? Why did it change? What problem were you trying to solve? What requirement or decision drove the change?
Someone who was not in the room—and may not even work for the company yet—should be able to understand what happened.
That is incredibly useful for writers too. Why did I move this scene? Why did I remove that subplot? Was this change based on beta-reader confusion, a continuity problem, pacing, tone, or simply a choice I made because the new version worked better?
I will admit that my own system is not as disciplined as the one I would expect professionally. But I am very good about leaving myself one kind of record: a restart note.
When I stop working, I write down where I stopped and what I need to do next. Something like:
Stopped in Chapter 6 after revising the confrontation. Next: check whether the timeline still works in Chapter 7.
That tiny habit saves an enormous amount of time. I do not have to reopen a project three days later and spend twenty minutes asking myself what past-me was doing. Past-me left documentation. Past-me occasionally behaves like a professional.
Consistency Is Mostly Invisible
Good document control is invisible when it works. Nobody celebrates because they opened the correct revision of a procedure and all the references matched. They notice when they do not.
Readers are the same. They rarely stop to admire the fact that:
a timeline remained coherent,
a character knew only what they were supposed to know,
the magical rules stayed consistent,
a name never mysteriously changed spelling,
or every chapter heading followed the same format.
They simply keep reading.
Continuity failures interrupt that experience. That makes consistency a strange kind of success: the better you do it, the less anyone notices you did anything at all.
I apparently decided that maintaining consistency in technical documentation was not enough and began inventing fictional universes that also require configuration control. This may have been an inefficient career choice.
If You Want People to Follow a Process, Make It Easy
One lesson document control teaches very quickly is that a process can be technically perfect and still fail if nobody wants to use it. Engineers, in particular, are not famous for loving paperwork.
If you want a process followed, it needs to be easy enough to follow and the value needs to be clear. Why are we collecting this information? Why does this approval matter? Why do I need to explain the reason for the change instead of typing “updated”? If the process feels like paperwork for the sake of paperwork, people will work around it.
Writers do the same thing. Endless systems are available for tracking characters, timelines, revisions, scenes, submissions, marketing, worldbuilding, and every other part of the process. A complicated system is not automatically a good system. The best one is the one that reduces friction enough that you will actually use it.
For me, that might mean dated files, an Old folder, comments in the manuscript, and a note telling me what to do when I come back. Someone else may need a full database.
The point is not to build the most sophisticated process. The point is to make the process useful enough that it supports the work instead of becoming the work.
Controlled Does Not Mean Static
This may be the most important lesson of all: A controlled document is not one that never changes; it is one that changes deliberately.
A good engineering change should leave behind enough information that someone can understand:
what was changed,
why it was changed,
what drove the decision,
and what the change was intended to accomplish.
A manuscript deserves the same consideration. Revision is not evidence that the previous version failed. Changing your mind is not inherently inconsistency. Sometimes the story evolves because you understand it better than you did when you began. The important question is whether you know why you are changing it.
If the answer is: This makes the story clearer, stronger, more coherent, or more emotionally effective, then the change has a purpose.
If the answer is: I have read this paragraph eleven times and have now begun rearranging adjectives because they have personally offended me, the proper corrective action may be to close the document.
Some principles survive surprisingly well when transferred from engineering to fiction. Unfortunately, neither profession has yet developed a reliable control system for files named:
FINAL_v8_USE_THIS_ONE_REALLY.docx
Signed somewhere between inspiration and version control,
S.G., Keeper of the Wondrous Ledger
