People are surprised when they learn a ghostwriter spent three decades in data centers.
They shouldn’t be. A book is a long project with a demanding client, a fixed budget, a deadline and a technical problem at its center: getting what’s in one person’s head into a form other people can use. I did that for a living long before anyone paid me to write a book.
My life story is in why I became a ghostwriter. This page is about what the technology years taught me that I still use on every book.
How did explaining technology prepare me for ghostwriting?
It taught me to translate. At Software Techniques and Beck Computer Systems I was VP of Consulting, and much of the job was writing manuals and papers that turned complicated software into instructions its users could follow. As senior designer on SCADA systems for water districts in the Las Vegas Valley, Ojai and New Haven, I had to document systems that operators relied on at three in the morning.
Ghostwriting is the same skill pointed at a person instead of a machine. A client knows their subject far better than I do. My job is to understand it well enough to explain it to readers who don’t, without flattening what makes it expert.
What did running operations teach me about deadlines?
Schedules slip one small decision at a time. The fix is visibility. At Trader Joe’s, operations ran around the clock, and a missed step could stop stores from selling. Books are gentler, but the pattern is the same. A canceled interview becomes a delayed chapter becomes a book that misses its launch.
So every book I write runs on a schedule the client can see: interviews on the calendar, chapters sent as they’re finished, no surprises at the end. My contracts put a project on hold after 30 days of silence and treat it as abandoned after 60, because a long project needs a rule for when it has stopped.
Why does scope control matter so much in a book?
Because I’ve watched technology projects grow many times past their budgets, one reasonable-sounding request at a time. Books do it too. “Can we add a chapter about this?” is how a 50,000-word book turns into 80,000 words and a missed deadline.
The FBI’s Virtual Case File shows how bad this gets.
In 2001 the bureau hired Science Applications International Corp. to build case management software for its agents. After the September 11 attacks, deadlines moved up and requirements grew. One FBI manager estimated that the scope of the larger Trilogy program expanded by 80 percent, according to NBC News.
IEEE Spectrum reported about 400 change requests between December 2002 and December 2003, against a requirements document of more than 800 pages. A 2004 arbitration traced 19 of 59 issues to FBI requirement changes and 40 to SAIC errors. In 2005 the FBI scrapped the project after spending $170 million on it.
I think every writer should read that story before saying yes to one more chapter, because each of those 400 requests probably sounded reasonable to someone at the time.
I don’t blame clients for it. A good book makes people remember more they want to say. The failure belongs to the writer who says yes to every addition and then acts surprised when the deadline passes. My contracts set the book at an “up to” word count. When a client wants more, we agree a change order before I write the extra chapters. Nobody is surprised, and I still finish the book.
How did security work shape how I handle clients’ secrets?
Years of PCI audits and security policy teach you that the details are the dangerous part. I drafted NIST 800-53 and Cybersecurity Framework policies for a multinational firm, and I worked on KnowBe4’s Cyberheist. That background is why I treat everything a client says as confidential from the first call, why I don’t name clients without permission, and why security books I write leave out the specifics an attacker could use.
What did incident response teach me about hard interviews?
To stay calm while someone else is having the worst day of their year. In operations, the person who panics during an outage makes it longer. In a memoir interview, when a client reaches the death of a child or the abuse they survived, the same rule applies: slow down, don’t rush them, and come back when they’re ready. Some of my clients have needed four sessions to tell one story. The steadiness I learned in server rooms lets me wait.
How did managing people prepare me for client feedback?
Managing people teaches you that most feedback is useful if you listen for what’s under it.
People rarely say exactly what’s wrong; they say what bothers them. Clients do the same with chapters. “This doesn’t sound like me” usually means one thing, and part of my job is finding it. At every kickoff, I ask clients to tell me the moment something bothers them, the same way I’d want a team member to raise a problem early.
The writers I’d worry about are the ones who get defensive when a client pushes back on a chapter. A client who feels ignored stops saying what’s wrong, and the book drifts away from them one chapter at a time.
Why do technical clients hire a ghostwriter who worked in IT?
Because they don’t have to teach me the field.
Executives writing about cybersecurity, AI, IoT or digital transformation want a book aimed at boards, clients and managers instead of engineers, and they need a writer who knows which details matter and which to leave out. I’ve ghostwritten books on all of those subjects. My article on why a technical person needs a ghostwriter who gets tech goes further.
What do the technology years mean for your book?
A writer who will treat your book as a project that has to ship, on time and in scope, while treating your story as something that matters. If you’re weighing a book, the Book Discovery Intensive is a short, well-scoped first engagement with a sample chapter at the end, and my ghostwriting services cover the full book.
Writers who treat a book as art with no deadline attached are kidding themselves. Your book has a client, a budget and a date, and the writers who forget that are why so many manuscripts come in late, bloated or not at all.
