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.
I have strong feelings about technical books written by people who’ve never been responsible for a system that went down. They insult the reader who has, and they cost the author the one audience whose respect he wanted. When a technology leader hires a ghostwriter, I think the minimum bar is a book his own auditor could read without wincing.
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. I value that endorsement more than any review, because it came from the one person paid to doubt me.
It says the writer was in the room. 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 wins 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’ve 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 or 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 right there. I think that’s an expensive failure to hand a client, because he was the one audience the book was built to win, and he won’t come back for chapter three.
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 has to hold both. A writer who offers only one of the halves is selling the client a book that fails somebody, and the client finds out after it’s printed.
Who should hire a ghostwriter with technology leadership experience?
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 can’t 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 do ghostwriting interviews with a technology leader sound like?
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 serving it. I push back hard when a draft slides the other way, because a book of war stories gets a laugh at the conference and then gets forgotten. 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. Confidence will impress any general reader, and I have no patience for books that settle for that. Write for the reader who has audited the author, the one hunting for the vague paragraph, and win his endorsement 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.
A technology leader who hires a writer who has to learn the field on his dime is paying to be embarrassed in front of the exact people he wrote the book for. A writer who flattens a good career into generalities that way cheats the client. Hire somebody who has been checked.
