TL;DR
I ghostwrote three digital transformation books for executives, and it taught me something running transformations did not. Each executive did it completely differently, at a scale far bigger than mine, Fortune 500 budgets, whole departments, agile and scrum where I used waterfall. Each had a methodology they wanted captured. Writing those books meant deep interviews and real understanding of what they meant. The lesson: there is no one way to transform, and the best books preserve the specific way one leader actually did it.
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 is 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 sharpened how I think about the whole field.
Three executives, three completely different methods
The thing that struck 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 genuinely different from each other and from how I had done it.
Each had real things to say. Each had earned their method through 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 is one framework everyone should follow, one neat methodology you can buy and apply. The reality, from three people who actually did it at a high level, is that the method is personal and shaped by the specific company, the specific constraints, the specific leader. One led with culture, one led with metrics, one led with a relentless focus on process, and 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 is 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 framework is selling the consulting equivalent of the security theater I describe elsewhere, something that looks authoritative and does not survive contact with a real organization.
A much bigger scale than mine
These executives operated at a scale beyond what I had run. I did transformations at a national retailer, which was substantial. 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 did not 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, which is why their judgment about sequencing and risk was so carefully earned.
They also worked under more stringent standards and methods than we used. Where my shop tended to run waterfall, the older, sequential way of running a project where you plan the whole thing, then build it, then 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; agile suited their fast-moving, large-team environments. The method follows the situation.
The work was understanding, not typing
Ghostwriting those books was not a matter of taking dictation. It required a lot of interviews and a lot of genuine effort to understand what each executive was talking about and what they actually meant. Even though I had done transformations myself, theirs were bigger and different, and I had to learn each one deeply enough to write it in their voice, accurately.
That is the real work of ghostwriting a technical book. Not the writing, the understanding. You have to grasp the methodology well enough that the expert reads the chapter and thinks yes, that is exactly what I meant, better than I could have said it. You cannot fake that. You have to actually understand it, which is why the combination of having run transformations myself and being able to write was what made these projects work. A pure writer would have missed the technical substance. A pure technologist could not have shaped it into a book. The value is in being able to do both.
Ghostwriting a technical book isn’t taking dictation. It’s understanding the method well enough that the expert reads it and thinks: yes, that’s exactly what I meant.Share on X
What the books preserve
What those three books captured was something that would otherwise have been lost: the specific, hard-won method of a specific leader who had actually transformed an organization. Not a generic framework. The real thing, in their words, at their scale.
That is what a good transformation book does. It does not add one more abstract model to the pile. It preserves how one person actually did it, including the parts that do not fit the standard framework, which are usually the most valuable parts. The executives who write these books are not trying to sell a method. They are trying to get down what they learned before it scatters, before they retire or move on and the knowledge leaves with them. That is exactly the kind of book worth writing, and exactly the kind I am 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 is 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 is one framework. The reality is that the method is personal and shaped by the specific company and leader.
Bigger budgets, broader scope, and higher stakes. The principles do not 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, not typing. You have to grasp the methodology deeply enough that the expert reads the chapter and thinks that is exactly what I meant. It takes many interviews and genuine effort to understand what the person actually means. The combination of having run transformations and being able to write is what makes it work; a pure writer misses the substance.
The specific, hard-won method of a leader who actually transformed an organization, in their own words and at their real scale, including the parts that do not fit the standard models, which are usually the most valuable. It captures what they learned before it scatters, before they move on and the knowledge leaves with them.
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.