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 honest 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 had 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 had 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 had run the systems, made the mistakes, fixed them under inspection, and then written about it.
That is 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 is no middle.
Why do technology leaders’ books fail?
Because the writer learned the field last week. Most ghostwriters come from journalism or publishing. They are 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 do not 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 did not 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 have 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 would do differently. That is 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 is 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 does not 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 has to hold both. That is 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 is also for the executive who has explained the same decision to a hundred boards and wants it written down once, correctly, by someone who does not 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 are how the decision is judged, and a writer who does not 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 had 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 are 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 have 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.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.