Latest
What an AI Detector Score on Your Manuscript Is WorthThe One-Hour Call Before I Quote Your BookWhen a Client Thinks the Ghostwriter Used AIMonthly or Milestone: How Ghostwriting Gets BilledWhen Your Memoir Should Be a NovelWhat It Costs to Fix an AI-Written ManuscriptThe Clients Who Pay and VanishThe Quotation Marks That Get Authors SuedThe Work You Would Never Have StartedWhen Your Own Memoir Sounds Like BraggingWhat Belongs on a Copyright PageThe Hugging Face AI Agent Attack: An Operations ReadingBehind the Book: The Mysterious Island, Neb’s SideHow to Organize Decades of Memories Into a MemoirWhy Rotten Tomatoes Sucks: The Score Does Not Mean What You ThinkWhy Amazon KDP Sucks: They Terminated My Account OvernightIngramSpark: How I Publish Now and WhyWhy Fiverr Sucks for Ghostwriting: The Buyer’s SideWhy eBay Sucks Now: A Seller’s Numbers and a Buyer’s WarningThe Ghost Story TraditionThe Gothic TraditionThe Christmas Ghost Story TraditionResurrection as a Narrative StructureBooks to Give a WriterThe Beach Read ArgumentWhy It’s a Wonderful Life Failed on ReleaseWhat to Read in SpringWhat to Read in SummerWhat to Read in OctoberHow Warner Bros. Dismantled a $17 Billion Cartoon EmpireThe Imaginary Scarcity TrapThe Graph That Goes Vertical Is Usually Somebody Else’sSubstack Is Not Collapsing. The Promise Was.The Disasters That Happen to Ordinary PeopleToba: The Winter That Almost Ended UsJay Stifflemire: Nothing Ever Gets Written DownGeorgie-Ann Getton: I Forgot I Had Free WillAI Detection Cannot Be Evidence, and Publishing Is Using It That WayAI Consciousness Left Philosophy and Entered the LaboratoryThe Office Block Where the Bedrooms AreThe Web Got Fenced: What AI Search Costs Small SitesBlack Tuesday: The Web Ring War Nobody Outside It NoticedWhat the AI Visibility Industry Sells, and What the Evidence SaysBlack Tuesday: The Original ring-master.net Page, 2000Behind the Book: Peacekeeper, The Dissolution WarsBehind the Book: Real World SurvivalBehind the Book: Publish Your BookBehind the Book: ReincarnationBehind the Book: Sell Your BooksBehind the Book: Show Don’t Tell

The Audit That Lasted a Decade

This entry is part 6 of 13 in the series How a Book Gets Written
TL;DR: For twenty years I was Director of Computer Operations and Technical Services at Trader Joe’s, and Steve Levinson, a CISSP-certified VP of Security, spent a decade auditing the systems I ran. When I wrote Family Cybersecurity, he endorsed it as someone who had audited the author. A technical book has to meet that standard, because the reader you want is the one who can tell. The failure I see most is a technology leader’s book written by someone who learned the field from Google, and the board member who ran operations spots it on page two.

A security auditor spent ten years testing the systems I ran. Then he endorsed my book. I think about that sequence whenever a technology leader asks me what a ghostwriter needs to know about their field, because the answer is: enough that the auditor would sign off.

For twenty years I was Director of Computer Operations and Technical Services at Trader Joe’s. Budgets, vendors, outages, migrations, the vendor who overpromised, the board that wanted to know why the expensive option was the right one. And every year, Steve Levinson, a CISSP-certified VP of Security, came to find what I’d missed. A decade of audits is a long apprenticeship in being checked. The book had to pass the same inspection.

What does an auditor’s endorsement mean for a book?

When I wrote Family Cybersecurity, Steve read it as someone who had audited the author. He knew what I’d gotten right and wrong over ten years of inspection, and he endorsed the book with that knowledge. That endorsement says something a marketing blurb cannot: the writer was in the room, not researching it. He’d run the systems, made the mistakes, fixed them under inspection, and then written about it.

That’s the standard a technical book has to meet, because the reader you want is the one who can tell. A CISO reading a book about security operations knows within two pages whether the author has ever stood in a data center at 2 a.m. The book either earns that reader or loses him, and there’s no middle.

Why do technology leaders’ books fail?

Because the writer learned the field last week. Most ghostwriters come from journalism or publishing. They’re good writers, and they have never run a change-control board, sat through a vendor escalation, or explained an outage to a CFO. So they research the field for a week and write around what they don’t understand, and the manuscript reads fine to everyone except the reader it was written for.

That reader, the board member who ran operations, the CTO who evaluated the same vendor, spots the vague paragraph on page two, where the writer didn’t know the mechanism and covered it with generalities. He stops trusting the book there, and he was the one audience the book was built to win.

What changes when the writer has made the decisions?

The interviews go three levels deeper. 33 years in enterprise technology came before I ghostwrote a single book, and when a CIO describes a decision, I’ve made a version of it. Nobody has to explain what a failover is. We skip that and talk about why he chose the expensive one, what the board said, how he sold it, and what he’d do differently. That’s the material a peer reads and respects, and it only surfaces when the writer can ask the second question.

A researcher-writer asks the first question and writes down the answer. A writer who has been there asks the second and third, because he knows where the interesting decision hides. The difference in the manuscript is the difference between a summary and a briefing.

Does field knowledge make someone a writer?

No, and that’s the other half. Knowing the field gets the facts right. Being a writer gets a reader through 60,000 words of them. 113+ books under my own name and 54+ ghostwritten for others is the second half, and it took as long to build as the first. A technical expert who cannot write produces an accurate book nobody finishes. A writer who doesn’t know the field produces a readable book the experts put down.

Both halves, or the book fails one of its readers. The peer needs the facts right. The general reader needs the pages to move. A technology leader’s book usually has both readers, and it’s to hold both. That’s why the combination is rare and why it matters.

Who this is for

CIOs, CTOs, operations leaders, and founders of technical companies. People whose story is a series of technical decisions and whose readers will judge the book on whether those decisions are described the way they happened. The stakes are higher for these books than for most, because the audience can check the work, and a book that fails the check does damage the author cannot undo.

It’s also for the executive who has explained the same decision to a hundred boards and wants it written down once, correctly, by someone who doesn’t need the explanation. The guide to ghostwriting covers how the interviews run, and the case studies include books that passed their auditors.

What the interviews sound like with a technology leader

Short questions and long answers, with the writer asking for the number. Which vendor, what did it cost, what was the alternative, who objected, what did the outage cost per hour, how long did the migration take against the plan. A technology reader wants those numbers because they’re how the decision is judged, and a writer who doesn’t know to ask for them writes a book of adjectives.

The other thing the interviews do is separate the decision from the war story. Every technology leader has both. The war story is entertaining and the decision is instructive, and the book needs the decision with the war story in service of it, not the other way around. Knowing which is which requires having made a few of the decisions.

The inspection

An audit is a strange kind of relationship. The auditor is paid to find your mistakes, and after ten years he knows your work better than anyone who likes you. An endorsement from that person is worth more than one from a friend, because it comes from someone who spent a decade looking for reasons not to give it. The book earned it by being right about things he’d checked.

A technical book should be written to survive that inspection. Not to impress a general reader, who will be impressed by anything confident. To survive the reader who has audited the author, and to be endorsed by him afterward.

Bring the decision you’re proudest of, the one the board argued about and you were right. The Book Discovery Intensive starts there, and by the end we know what the book argues and which readers have to be able to check it. If that sounds like the book you’ve been putting off, send me a message on LinkedIn. Part of the Technology of Writing Hub.

Ten years of audits. Then an endorsement. Write the book that survives the inspection.

Frequently Asked Questions

Why should a technology leader’s ghostwriter have a technical background?
Because the readers can check the work. A board member who ran operations or a CTO who evaluated the same vendor spots the vague paragraph where the writer didn’t understand the mechanism, and the book loses the audience it was written for.
What background does Richard Lowe have in technology?
33 years in enterprise technology, including 20 years as Director of Computer Operations and Technical Services at Trader Joe’s, before ghostwriting 54+ books.
Who is Steve Levinson?
A CISSP-certified VP of Security who audited the systems Richard Lowe ran at Trader Joe’s for a decade and later endorsed his book Family Cybersecurity.
Is subject knowledge enough to write a technical book?
No. Field knowledge gets the facts right; writing skill gets a reader through the pages. A technology leader’s book usually has both expert and general readers and has to hold both.
Who is technical ghostwriting for?
CIOs, CTOs, operations leaders, and founders of technical companies whose story is a series of technical decisions and whose readers will judge the book on whether those decisions are described accurately.

📝 Disclaimer

The views and opinions expressed in this blog post are solely those of Richard Lowe and are based on personal experience and research. This content is for informational purposes only and should not be construed as professional legal, financial, accounting, or business advice. Always consult with qualified professionals before making important business or legal decisions. Richard Lowe is not a lawyer, accountant, or licensed professional advisor, and this content does not establish any professional relationship.

0 comments

No comments yet. Yours can be the first.

Was this useful?

Leave a comment