The pattern repeats with almost every executive who comes to me wanting a book on digital transformation, and it’s 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’re proudest of, and the book is supposed to prove they have it.
Then I ask the only question that matters: who’s this book for? And the true answer is customers for a consulting practice.
It’s the boards and executive committees who sponsor transformations. It’s conference organizers, promotion committees, the managers of the author’s managers. Readers who don’t 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’d fight that battle harder and win it earlier, because the technical books I’ve written since have shown me the pattern from every angle. The three transformation books I’ve ghostwritten each took a different architecture: one built on the people-process-technology framework, one on the author’s own methodology, and one written from the executive vantage point. The ones I can track did what technical books rarely do. One became its author’s client-pitching credential on his LinkedIn, and another put its author on the speaking circuit.
Three architectures, three different books
Same subject, three different books, and the right choice depends entirely on what the author’s career needs the book to do.
Those three books also show a decision authors rarely realize they’re making: the book’s structural bet. The structure 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, and I think it’s the safest bet for a career operator, because it lets the war stories make the case.
The methodology book is the opposite bet, presenting the author’s own proprietary approach, harder to write because the structure must be taught and defended instead of assumed, and most valuable for consultants whose business is the methodology itself. The executive-vantage book largely skips structures 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. That’s a strategy conversation, and it belongs before the outline. I get frustrated when it surfaces halfway through a manuscript, because by then chapters have to be torn down and rebuilt, and the author pays for the same book twice in time and patience.
| Architecture | How it works | Best fit |
|---|---|---|
| Structure book | Borrows an established model like people-process-technology and proves mastery through lived cases | Career operators whose authority comes from depth of practice |
| Methodology book | Presents the author’s own approach, which must be taught and defended | Consultants whose business is the methodology itself |
| Executive-vantage book | Skips structures and sells judgment as a leadership experience | Authors writing to peers |
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 does the technical depth go in a transformation book?
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 the stack would repel 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 moves the author toward the goal. Performance feeds the ego and costs the author the very reader the career depends on, and I’ll argue for cutting a performing page even when it’s the one the author loves most.
My take
Aim the book at the people who fund, promote and hire you, because they aren’t technical. Keep the technical depth a couple of layers under the argument, where it proves you’ve been in the room without driving off the reader your career depends on. Pick the structure before the outline, a framework, your own methodology, or the executive view. Cut any page that performs expertise at the reader, even the one you love most.
What conversation should happen before the outline?
If you’re 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 hasn’t signed, the board that hasn’t promoted you, the conference that hasn’t 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 for. The other half is knowing the field well enough to write it.
A transformation book written to show off the stack is a vanity project, and it’ll go unread by exactly the people the author needed to reach. I’ve got no interest in helping anyone spend months on that. The author who writes for the board, the client and the conference organizer gets a book that keeps working for years, and the author who writes for other architects gets polite applause from people who can’t promote them.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
Transformation books land when they speak to the people who fund and hire you. The Ghostwriting Advantage shows how to get that book written for you by a professional.
