Table of Contents
TL;DR
Executives arrive wanting to write a technical book. What they need, almost every time, is a book aimed at the people who fund, promote, and hire them, and those people are not technical. I learned this fighting an early client, chapter by chapter, over an IoT book. He wanted the technical depth in; his goal was the attention of management. The balance we reached got him promotions and speaking engagements, and taught me to fight that battle earlier.
The pattern repeats with almost every executive who comes to me wanting a book on digital transformation, and it is the same pattern I see with cybersecurity books and every technical subject: they think they want to write a technical book. Deep architecture, methodology internals, maybe implementation detail. The instinct comes from a good place. Technical mastery is what they are proudest of, and the book is supposed to prove they have it.
Then I ask the only question that matters: who is this book for? And the true answer is never “architects.” It is customers for a consulting practice. It is the boards and executive committees who sponsor transformations. It is conference organizers, promotion committees, the managers of the author’s managers. Readers who do not want the bits and bytes, and who will put down any book that leads with them.
The IoT book where I learned the fight
One of my earliest ghostwriting projects was an IoT book, and the client’s goal was explicit: attract the attention of management. The manuscript kept pulling technical, because that was where his enthusiasm lived, and I kept pulling it back: strip this section, your reader runs a division. He wanted the depth in. I wanted his goal met. We argued it chapter by chapter, and he landed on enough of a balance that the book worked, and worked well: promotions, speaking engagements, the standing he was after.
Today I would fight that battle harder and win it earlier, because decades of technical books since have shown me the pattern from every angle. The three transformation books I have ghostwritten each took a different architecture, one built on the people-process-technology framework, one on the author’s own methodology, one written from the executive vantage point, and the ones I can track produced exactly the outcomes technical books rarely do: one became its author’s client-pitching credential, sitting on his LinkedIn as proof of authority; another put its author on the speaking circuit.
Three architectures, three different books
The three transformation books I have ghostwritten also illustrate a decision authors rarely realize they are making: the book’s structural bet. The framework book, built on people-process-technology, borrows the credibility of an established model and spends its effort proving the author’s mastery of it through lived cases; it suits authors whose authority comes from depth of practice. The methodology book is the opposite bet, presenting the author’s own proprietary approach, harder to write because the framework must be taught and defended rather than assumed, and most valuable for consultants whose business is the methodology itself. The executive-vantage book skips frameworks largely altogether and sells judgment: transformation as a leadership experience, aimed at peers. Same subject, three different books, and the right choice depends entirely on what the author’s career needs the book to do, which is a strategy conversation, not a writing one, and it happens before the outline or it happens expensively during it.
Does this page prove expertise to the reader, or perform expertise at them? One advances your goal. The other costs you the reader.Share on X
Where the technical depth goes
None of this means the book is technically empty; a hollow book fails with this audience just as surely, because executives sponsoring transformations have technical people who will be asked to assess it. The craft is placement. Technical substance runs a couple of layers beneath the argument, surfacing as supporting evidence: the detail that proves the author has been in the room, deployed at the moment it wins a point, never as the book’s backbone. My transformation, metaverse, AR/VR, and AI books all carry their depth that way. The reader who needs reassurance that the author knows the stack finds it. The reader who would be repelled by the stack never hits it.
The test I apply to every chapter: does this page prove expertise to the target reader, or perform expertise at them? Proof advances the author’s goal. Performance advances the author’s ego, and costs him the reader his career actually depends on.
The conversation to have before the outline
If you are an executive with a transformation book in mind, settle one thing before any writing starts: name the specific people you need this book to move, the client who has not signed, the board that has not promoted you, the conference that has not called, and hold every chapter to the question of what those people need to believe when they finish it. That single decision, made early, is worth more than any amount of craft applied later, and reaching it, sometimes against the author’s own instincts, is half of what a good ghostwriter is actually for. The other half is knowing the field well enough to write it.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
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.