The Data Center Primer book writing and publishing Journey: Article 3 of 10

How a Depth Crisis, a Mindset Reset, and a Reader Map Unlocked the Second Phase of the Data Center Primer

James Soh

Have You Ever Dreamed of Writing a Book?

I have. Twice, actually, separated by nearly fifty years.

The first time I was in primary school, enamoured with Battlestar Galactica, the original 1980s TV series with its colonial warriors and Cylon raiders and the endless search for Earth. I wrote short chapters of space battles in Chinese and passed them to one or two classmates who enjoyed them. The writer's itch arrived early, was fed briefly, and then went quiet as school and life and career took over.

The second time was last year. A fiction idea surfaced and I found myself thinking about it seriously. Before committing, I did what I tend to do: I checked the foundation. Faster-than-light travel, the engine of almost every space fiction story, would require energy on a planetary scale to achieve. It is pure science fiction in the most literal sense, not a technology with a plausible near-future path. And the genre itself, space opera, was already crowded with formula. Heroic pilot, ancient enemy, chosen crew, jump drive engaged. I had watched enough iterations to know I would be writing inside a box rather than building something genuinely new.

So the fiction idea was set aside. Not abandoned permanently, but honestly assessed and found not ready.

What I had instead was something that had been accumulating since 2008: observations, notes, recurring questions from training sessions, and a gap in the professional literature that no one had filled from the right vantage point. That became the Data Center Primer. A non-fiction technical book that passed the same test the fiction idea failed: is there a real gap, am I the right person to fill it, and does the world need this book to exist?

The answer was yes on all three counts. But knowing the answer and finishing the book are different problems entirely. This article is about the problem in between: the wall that nearly stopped the project, what it was actually made of, and what it took to get past it.

The Wall That Most Authors Hit and Most Books Never Pass

There is a path that this book almost do not exist.

In that version, I hit the wall in early 2024, spent a few months unable to move the manuscript forward, decided the project was too ambitious alongside a full consulting life, and quietly set it aside. The slide deck version of the content got made instead. Useful, reusable, and finished in a fraction of the time. The book stayed as a folder of draft chapters on a hard drive, visited occasionally, never completed.

That version is not hypothetical. It is what happens to most books that reach the wall. The authors who stop there are not less capable or less committed than the ones who continue. They are often more rational. The wall is real, the cost of continuing is high, and the outcome is uncertain. Stopping is the reasonable response.

What this article is about is why I did not stop, what the wall was actually made of, and what it took to get past it. Not as inspiration, but as a specific account of a specific problem with a specific solution that any aspiring non-fiction technical author can apply to their own project.

Phase One: March 2023 to Early 2024

The original estimate was nine months. I started writing in March 2023 and expected to have a finished manuscript by the end of the year.

The first phase was productive in terms of pages. Over roughly nine months of writing alongside consulting work, I produced content across the Introduction, Data Center Business, Project, Design, and partial Operations chapters. After editing to remove overlap and duplication, the manuscript stood at around 130 pages.

But the content had a problem that the page count concealed. It was bloated in some places and thin in others. Chapters kept shifting in scope. Material that seemed relevant to one chapter would get added to another where it also seemed to fit, creating duplication that only became visible when reading front to back. The chapter structure went from eight chapters to thirteen and back toward twelve, not because the structure was improving but because content kept arriving without a firm place to land.

The deeper problem was that no single piece of content had a reliable test it had to pass. Interesting and technically accurate were the only filters, and those filters let almost everything through. The result was a manuscript that knew a great deal and served no one in particular.

The table of contents from that February 2024 version tells the story clearly. The numbering is inconsistent, jumping from section 2.5 to 3.1 to 3.2 and then back to 2.5 again. Section headers mix high-level concepts with operational detail at the same outline level.

Stakeholders appear in Chapter 1, again as section 3.1, and again as section 2.5. "What are the steps to design a Building?" sits at the same level as "Data Center Ecosystem." The duplication and the structural drift are visible in the table of contents itself, before you even open a chapter.

What the Wall Actually Felt Like

By early 2024 the writing had slowed to something close to a stop.

I would sit down to write and produce a paragraph, then stop. The thought that kept arriving was: is this paragraph actually useful? Not useful in the abstract. Useful to whom, and for what?

I skipped the blocked design chapter and moved to the electrical infrastructure chapter. Same problem. The content kept going deeper. More technical detail, more sub-categories, more caveats and qualifications. I skipped again to the mechanical infrastructure chapter. Same pull toward depth.

That pattern, the same problem appearing in every technical chapter regardless of where I started, told me something important. This was not a chapter problem. It was a book problem. The depth was not a symptom of one difficult section. It was a symptom of something wrong with how I was thinking about the whole manuscript.

So I stopped writing and started deep thinking on this book wall.

Finding the Root Cause

The thinking went through several layers before it reached the real answer.

The first layer was obvious: the technical chapters were going deeper than the other chapters, creating a depth mismatch across the book. That was the visible symptom.

The second layer was the cause of the depth: there was a lot of available content on electrical and mechanical infrastructure, and I was using most of it. The availability of content was driving the depth rather than the reader's need for it.

The third layer was the cause of the cause, and this one took longer to reach: I was writing the technical chapters to a standard that would satisfy senior technical data center professionals. Not explicitly. Not consciously at first. But the internal question I was applying to each technical paragraph was something close to: would an experienced data center engineer find this credible?

That was the wrong question entirely, and it was the source of every problem in the manuscript.

The Credibility Trap

Here is the insight that reset the book, stated plainly.

Senior technical experts do not buy guidebooks written by other senior technical experts. Not because the books are bad. Because of how expertise works.

Imagine a thirty-year data center electrical design expert who writes a technical guide. Another thirty-year expert in the same field looks at it and finds reasons it does not quite apply: different project types, different region, different era, different client base, different approach to a specific design decision. The more deeply someone knows a subject, the more precisely they can identify where another expert's framing diverges from their own.

Expert to expert book sales are blocked by the credibility comparison problem. There is no depth that satisfies all experts, because each expert's credibility test is built from their own specific experience.

So I was writing to a depth that would convince an audience that would never buy the book regardless. And in doing so I was producing content that was wrong for the audience that would.

The reset was this: if a senior data center professional picks up the Data Center Primer, the right and achievable outcome is that they assess it as good enough for their new staff. That is a meaningful and valuable outcome. It does not require the book to prove itself to the expert. It requires the book to serve the newcomer well enough that the expert trusts it as a starting point for the people they are responsible for developing.

That reframing changed what credibility meant for this book. Credibility was no longer: will a thirty-year expert find nothing to disagree with. Credibility was: will a newcomer finish this book with an accurate, useful, and honest picture of what data center work actually involves. Those are completely different tests. The second one was both more achievable and more important.

The Fork: Slide Deck or Book

During the pause I had two viable options in front of me.

The first was to create a teaching and sharing slide deck from the existing content. Faster, lower risk, immediately usable for training sessions and consulting engagements. The material was already there. The slide deck would have been done in weeks.

The second was to reboot the book, fix the structural problem, and finish what I had started.

The slide deck was the easier path and I considered it seriously. What pushed me back toward the book was a combination of conviction and market reality.

I had been wanting to write this book since 2012. I had been collecting material and observations since 2008. In fourteen years of working in and around data centers across Southeast Asia, I had looked repeatedly for a book that covered the full operator journey, from planning and design through construction, testing and commissioning, and into operations, written from the operator's perspective rather than the designer's or the academic's. That book did not exist. The closest candidates covered one part of the journey, usually design, and rarely touched operations because most authors had not worked in data center operations themselves.

A slide deck would not fill that gap. A book would.

I also knew that stopping at the wall was a real possibility and that many authors in the same position do not come back. That awareness made the decision feel more deliberate. I was not drifting back to the manuscript. I was choosing to return to it, for specific reasons, with a specific plan for what had to change.

The Reframe and the Restart

The restart was not about writing more. It was about reorganising what already existed around a reader who was now precisely defined.

The primary reader was confirmed: newcomers and non-technical professionals who interact with data centers. The secondary reader: mid-career professionals looking to broaden their options. Not senior technical experts. Not designers. Not the people who would find reasons to critique the depth of the electrical chapter.

With that confirmed, every piece of existing content had a new test. Is this the right depth for a newcomer? Does this serve the non-technical professional who needs to function credibly without becoming a designer? Is this detail for the operator's reference shelf, or does it belong in a primer for someone encountering the subject for the first time?

Content that failed the test was cut or shortened. Not because it was wrong but because it was not for this reader. The design chapter that had grown to 40 pages came down. The electrical and mechanical infrastructure chapters were recalibrated. The depth mismatch that had caused the first stall resolved because the test was now consistent across every chapter.

But the reboot was not only about reduction. Once the reader was firmly defined, it also became clear where the book needed to go deeper than any comparable title had gone. Operations content, which most data center books either omit or treat superficially because their authors have not worked in data center operations, warranted two full chapters. Chapter 8, the Data Center Operations Management Framework, and Chapter 9, Operational Practices for Newcomers and Mentors, provided the systematic operations view that the industry needed. Chapter 10, covering the inner workings of a data center operator, and Chapter 11, covering facility renewal, addressed areas where the gap between what practitioners needed and what was publicly available was widest.

Most data center professionals spend the majority of their careers working in existing facilities rather than building new ones. A large proportion of them will face facility renewal decisions at some point. That content needed to exist, written from the inside, and it did not.

The reboot gave it a home. Reducing depth where the reader did not need it, and expanding coverage where almost no one else had written it, is what a reader-first editorial test actually produces in practice.

The most tangible structural output of the reboot was Section 1.11 of the published book, "Navigate the Rest of This Book," which contains Table 1.3, the Suggested Reading Flow. The table maps four distinct reader types to specific chapter sequences and key focus areas. Technical and operations staff follow one path. Project, construction and engineering teams follow another. Business, investment and market professionals follow a third. Newcomers, career explorers and general readers follow a fourth, directed to Chapter 2, Chapter 12, Appendices A, C and E, and the Glossary.

That table could not have existed before the reboot because the reader types were not yet firm enough to map. Once they were firm, the table became both a navigation tool for the reader and an editorial discipline for the writing. Every subsequent chapter had to justify its content against at least one of those four reader paths.

The writing restarted in March 2025. The first alpha edition was dated 20 September 2025. The second phase produced the bulk of the final manuscript, approximately 328 B5 pages and around 120,000 words, in roughly six months. The first phase had produced less in more time. The difference was not effort. It was clarity.

Why the Second Phase Moved Faster

This is worth stating directly for any aspiring author who is currently in their own first phase.

The second phase was not faster because the writing got easier. Technical content does not get easier to write. The data center design chapter required a complete rewrite and included five consecutive days of thirteen-hour sessions, with one Saturday running from 8:30am past 4am the following morning. That is not easy writing. That is hard writing done with a clear purpose.

The second phase was faster because the decisions were faster. When you know exactly who you are writing for and what they need from each chapter, the question of what belongs and what does not resolves quickly. The content that had previously resisted placement because it had no firm home now had a test it could pass or fail. Most of the resistance of the first phase was not writing difficulty. It was decision difficulty. Remove the decision difficulty and the writing follows.

What Other Authors Do at the Wall

Fiction and non-fiction authors alike describe hitting a wall at some point in a long project. The accounts on YouTube writing channels and in author interviews follow recognisable patterns: re-analyse the problem, reframe it, or find another path through.

What those accounts share, beneath the different genres and different specific problems, is that the wall is almost never a motivation problem. It is almost always a structural or purpose problem in disguise. The author who cannot write the next chapter is usually stuck because something earlier in the book has not been resolved, or because the book's purpose has not been fully defined, or because they are writing for the wrong reader in their head.

The practical question to ask at the wall is not: how do I find the motivation to continue? It is: what is the book actually for, and who is it actually for, and is what I have written so far in service of that? If the answer to those questions is clear, the wall usually has a path through it. If the answer is unclear, the wall is telling you something important that more writing will not resolve.

For aspiring non-fiction technical authors specifically, the credibility trap is the most common hidden cause of the wall. Writing to prove yourself to an expert audience that was never your target reader will push every technical chapter deeper than it needs to go, create a depth mismatch across the book, and eventually make the manuscript feel unfinishable. The fix is not more research or more writing. It is a precise and honest answer to the question: who is this book for, and what do they actually need from it?

Reaffirm the Conviction can Brings You Back on track

Not every paused book deserves to be restarted. Some projects hit the wall because the original idea was not strong enough to justify the effort required to complete it. The pause is useful precisely because it forces that question into the open.

What brought me back was not discipline or willpower. It was the specific and verifiable knowledge that the book needed to exist and that I was the person positioned to write it. The gap in the market was real. The operator's perspective was genuinely missing from the available literature. Fourteen years of accumulated material, observations, and teaching experience were sitting in notes and drafts, waiting for the structure that would make them useful to the reader who needed them.

Every aspiring author sitting at their own wall should ask the same question directly: why does this book need to exist, and am I the person who can write it? If the answer is strong and specific, the conviction will carry you back to the desk. If the answer is vague or could apply to anyone, the pause may be telling you something worth listening to.

The conviction is not a feeling. It is an assessment. And it is the most reliable tool any author has for deciding whether to restart or to stop.

What This Means for Your Book

A few things from this phase worth taking seriously:

Define your reader before you write the first chapter. The question of who this book is specifically for is not a marketing question to answer after the writing is done. It is the first editorial decision, and the answer to it will shape every decision that follows. Writing without a firm reader in mind is how bloated, duplicated, and uneven manuscripts get made.

Watch for the credibility trap. If you find your technical chapters going deeper than your intended reader needs, ask honestly who you are writing for in your head. If the answer is an expert peer rather than your actual target reader, you have found the source of the depth problem.

When you hit the wall, diagnose before you push. The wall is almost always a structural or purpose signal, not a motivation problem. Ask what the book is for and who it is for before deciding whether the answer is to write more or to reframe what you have.

The reboot is not only about cutting depth or cutting content. Once your reader is defined, it will also show you where the book needs to go deeper than existing titles have gone. The areas where your experience is most distinctive and the available literature is thinnest, are where your book earns its place.

The pause is not a failure. It is part of the process for any book that is genuinely difficult to write. The authors who do not return from the pause are not weaker than those who do. They often write books that the public correctly identifies as unnecessary. Know why your book needs to exist before you return to it.

The conviction to finish is not found in motivational advice. It is found in a specific and honest answer to the question: who will be worse off if this book is never written? If you can answer that question with names, roles, and a genuine gap in what they currently have access to, you have your reason to restart.

Or better still: decide first on your target readers and focus on what they need, before you write a single chapter, and you may never face the wall at all.

If this journey resonates with you and you work in or around data centers, you may find The Data Center Primer a useful companion as you team your colleagues and staff to navigate planning phase, data center build project phases, and operations.