I ran digital transformations myself for two decades. Then I ghostwrote three books about digital transformation for other executives, and that taught me something running my own never did. There’s no single right way to do this. There are as many ways as there are leaders, and the good ones each have a method worth preserving.
I ghostwrite books for technology leaders, and these three projects hardened my opinion of the firms that sell transformation as a packaged product. I came away irritated with anyone who hands a company a method built somewhere else, and with a lot more respect for executives who built their own the hard way.
What surprised me most was how differently each of them worked. All three wanted a book that described their methodology, their particular approach to transformation. And in all three cases, those approaches were different from each other and from how I’d done it.
Each had real things to say. Each had built their method from their own scars. None of them was wrong, and none of them matched.
That alone was a lesson. The consultant-speak version of digital transformation pretends there’s one structure everyone should follow, one neat methodology you can buy and apply. The reality, from three people who did it at a high level, is that the method is personal and shaped by the company, the constraints, the leader.
One led with culture. One led with metrics. One led with a relentless focus on process. All three succeeded, because each method fit the person running it and the organization they were running it in.
I ghostwrote three digital transformation books. All three executives had a different method. None was wrong. There’s no one way to do this, whatever the consultants say.Share on X
This is the same truth I reached from my own experience in people, process, technology: the order and the principles hold, but the specific method is always shaped by the people and the place. Anyone selling a one-size-fits-all transformation structure is selling the consulting equivalent of the security theater I describe elsewhere, something that looks authoritative and doesn’t survive contact with a real organization.
These executives worked at a scale beyond what I’d run.
I did transformations at a national retailer. That was considerable. They were working at Fortune 500 scale, with bigger budgets and the goal of transforming far more of their organization than I ever had to. The principles didn’t change at that scale, but the stakes and the complexity did. A misstep that would have been a bad week at my scale could be a catastrophe at theirs, so their judgment about sequencing and risk was carefully earned.
They also worked under more stringent standards and methods than we used.
My shop tended to run waterfall, the older sequential way. Plan everything, build it, ship it. They were using agile and scrum, the iterative modern approach where work happens in short cycles with constant adjustment. Seeing how those methods played out at that scale, through the eyes of the people running them, expanded my own understanding considerably. Neither approach is universally right.
Waterfall suited the predictable, infrastructure-heavy work I did, and agile suited their fast-moving, large-team environments. People who call one of them obsolete are wrong. A company that forces a method onto work it doesn’t fit pays for that in missed dates and worn-out teams, and the consultant who sold the method is long gone by the time the bill comes due.
| Factor | My transformations | The executives’ transformations |
|---|---|---|
| Organization | A national retailer | Fortune 500 scale |
| Budget and scope | Considerable, but smaller | Bigger budgets, far more of the organization transformed |
| Method | Waterfall: plan everything, build it, ship it | Agile and scrum: short cycles, constant adjustment |
| Work it suited | Predictable, infrastructure-heavy work | Fast-moving, large-team environments |
| Cost of a misstep | A bad week | Could be a catastrophe |
| Principles | Same principles | Same principles, more stakes and complexity |
I’d be wary of any writer who tells a technology executive the subject matter doesn’t matter on a methodology book.
Ghostwriting those books wasn’t a matter of taking dictation. It required a lot of interviews and a lot of real effort to understand what each executive was talking about and what they meant. Even though I’d done transformations myself, theirs were bigger and different, and I had to learn each one deeply enough to write it in their voice, accurately. One of them, a digital transformation book for a client, was a bitch. I’ve done digital transformation, and I led one myself at a retailer, but that book was still very complicated. It took work, and boy, did we have fun with it.
That’s the main work of ghostwriting a technical book, and the typing is the smaller part of it. The understanding is the job. You have to grasp the methodology well enough that the expert reads the chapter and thinks yes, that’s exactly what I meant, better than I could have said it.
You can’t fake that. Having run transformations myself and being able to write made these projects work. A pure writer would have missed the technical substance.
A pure technologist couldn’t have shaped it into a book either. I’d be wary of any writer who tells a technology executive the subject matter doesn’t matter on a methodology book. The executive’s peers will read it, and they’ll spot a chapter that gets the vocabulary right and the method wrong within a page or two. The writer’s name isn’t on the cover. The executive’s is, and they’re the one who pays for it in credibility.
My take
There’s no single right way to transform a company, and anyone selling one is selling a slogan. Waterfall fit my infrastructure work. Agile and scrum fit the big, fast teams I wrote for. A transformation book is worth reading when it captures one leader’s specific method accurately enough that peers recognize it. That takes a writer who understands the subject. If yours shrugs at the technical substance, find another, because your name’s the one on the cover.
Ghostwriting a technical book means understanding the method well enough that the expert reads it and thinks: yes, that’s exactly what I meant.Share on X
What did three transformation books have in common?
What those three books captured would otherwise have been lost: the hard-won method of one leader who had transformed an organization, in their words and at their scale.
A good transformation book preserves how one person did it, including the parts that don’t fit the standard structure, and those are usually the most valuable parts. The pile of abstract models is high enough already. Too much of this knowledge walks out the door. An executive retires or moves on, and a method that took years of mistakes to build leaves with them because nobody sat down and got it on paper. The company loses it, and so does everyone who could have learned from it.
That’s exactly the kind of book worth writing, and exactly the kind I’m built to write, having both run transformations and written the books about them. You can see how I work on the technology ghostwriting page.
Frequently Asked Questions
That there’s no single right way to transform an organization. I ghostwrote three digital transformation books, and all three executives had completely different methods, one led with culture, one with metrics, one with process, and all three succeeded. The consultant version pretends there’s one structure. The method is personal and shaped by the specific company and leader.
Bigger budgets, broader scope, and higher stakes. The principles don’t change at that scale, but the complexity and the cost of a misstep do. The executives I wrote for transformed far more of their organizations than I did, and they used agile and scrum where my shop tended toward waterfall. The method follows the situation.
Waterfall is the older, sequential approach: plan the whole project, then build it, then ship it. Agile and scrum are iterative, with work done in short cycles and constant adjustment. Neither is universally right. Waterfall suited the predictable, infrastructure-heavy work I did; agile suited the fast-moving, large-team environments of the executives I wrote for.
Understanding, before typing. You have to grasp the methodology deeply enough that the expert reads the chapter and thinks that’s exactly what I meant. It takes many interviews and real effort to understand what the person means. The combination of having run transformations and being able to write makes it work; a pure writer misses the substance.
I think what a good transformation book preserves is the specific, hard-won method of a leader who transformed an organization, in their own words and at their real scale. It captures the parts that don’t fit the standard consulting structures, and those are usually the most valuable parts. I write these books to get down what an executive learned before it scatters, before they move on and the knowledge leaves with them. That’s what makes the book worth writing in the first place.
Yes. I led transformations myself for two decades and ghostwrote three for executives at larger scale. That combination, having done it and having written others’ versions, is rare and is exactly what a technical book needs. You can see how I work on the technology ghostwriting page.
Executives who want a transformation book should know how the process works before they sign. The Ghostwriting Advantage explains how to get your book written for you by a professional.
- Manifesto for Agile Software Development, Agile Alliance (agilemanifesto.org)
- Scrum (project management), Wikipedia
