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

Dead on Arrival: Version 0.1

Writing with the Intended Readers in Mind, and Using AI Productively

James Soh

Dead on Arrival

Captain Jack Sparrow is many things. Unreliable, rum-soaked, operating on logic that only makes sense three scenes later. But nobody ever called him boring. Pirates of the Caribbean works because every scene has somebody who has been somewhere, done something inadvisable, and carries the evidence on their face. You believe the Data Center sharing because the people sharing their version have battle scars from actual data center work.

I thought about that on a Sunday afternoon, scrolling through sixty-something pages of what an AI had produced when I asked it to write my data center book.

No scars. No rum. No sense that anyone had ever actually been inside the building after the ribbon-cutting.

The pages were correct. The headings were sensible. The progression from definition to concept to application was tidier than most human drafts I have seen. And it was, in the precise meaning of the phrase, dead on arrival. The kind of document you skim the way you skim a safety manual you already know you'll never open again.

Dead men tell no tales, the pirates say. Dead manuscripts tell no stories either. A data center book with no operator's voice in it, no commissioning scars, no 2am equipment failures, no awkward moment when a sales promise meets a physical constraint, is exactly that. Competent. Lifeless. Gone before it starts.

That AI draft was Version 0.1. This article is about what I learned from it, and what I had to do instead.

Straight after the ChatGPT 1.0 Attempt: The 60‑Page Data Center Primer Book Version 0.1

As I wrote in Part 1, I took an outline, fed it into ChatGPT, and out came a 60--70 page "data center fundamentals" manuscript. Outline in, book-shaped object out. If you try something similar today with any mainstream AI chat tool and a prompt like:

"Can you draft a 70 pages (A5 page size, font Inter, font size 11, normal book output formatting and spacing) book on Data Center Fundamentals meant for newcomers and non‑technical professionals?"

you will get something very close to what I saw. The outline typically looks like this:

DATA CENTER FUNDAMENTALS A Practical Guide for Newcomers and Non‑Technical Professionals

• Table of Contents

• Introduction to Data Centers

• Why Data Centers Matter

• Types of Data Centers

• Core Components Inside a Data Center

• Power Systems and Electrical Infrastructure

• Cooling and Environmental Control

• Networking Fundamentals

• Servers and Storage Basics

• Virtualisation and Cloud Computing

• Security in Data Centers

• Reliability, Redundancy, and Uptime Monitoring and

• Operations Sustainability and Energy Efficiency

• Data Center Economics and Business Models

• Compliance, Standards, and Certifications

• Careers and Working with Data Center Teams

• The Future of Data Centers

• Conclusion

  
  

And the opening paragraphs of Chapter 1 usually read along these lines:

Chapter 1 — Introduction to Data Centers Every time you send an email, stream a movie, join a video meeting, use online banking, or store photos in the cloud, you are relying on a data center.

A data center is a physical facility that houses computing infrastructure, servers, storage systems, networking equipment, and supporting systems, that process, store, and deliver digital information.

On paper, that looks reasonable. It is factual. It is neat. It is also dead boring to read.

You can tweak the prompt and ask the AI to "use a warmer voice" or "start every chapter with a question for newcomers and non‑technical professionals." The output becomes slightly friendlier, but it still lives in the same template: correct, generic, and detached from real rooms and real consequences. It is still a straight AI output trying to talk to everyone at once.

The table of contents is a clue. It tries to cover almost the entire technical surface area of data centers, plus economics, careers, and "the future," in about 70 A5 pages. At 250 to 300 words per A5 page, that is not a lot of space per topic. There is nothing wrong with brevity, but it forces you into a very thin, survey-style treatment. That was never the book I wanted to write.

I wasn't trying to pad the Data Center Primer out to 328 B5 pages just to look substantial. And I knew very early that I did not want a "Future of Data Centers" chapter. My view is that if the reader understands most of the book and keeps an eye on industry developments, they will be able to form their own judgment about the future. They do not need my speculative chapter at the end.

After a couple of days with that AI draft, I closed it and went back to search and my own notes.

Technically, most of the AI text wasn't wrong. Correct definitions, reasonable explanations of basic concepts, a sensible progression from "what is a data center" down into racks, power paths, and cooling systems. In terms of structure, it was tidier than many human drafts I have seen.

But as soon as I tried to read it the way one of my intended readers might, it failed.

It read like a slightly warmer version of a vendor whitepaper. The sentences were matter-of-fact and generic. Every section sounded like something stitched together from marketing sites and training manuals. There were no small, specific moments that make things click for someone who actually works in or around a data center. No commissioning scars. No "this looked fine on the single-line diagram, but year three told a different story." No awkward conversations between sales and ops when a promise meets a physical constraint.

More importantly, there was no sense of who the book was really for.

An operator, a salesperson, an investor, and a newcomer from cloud or finance all showed up in the same bland paragraphs. The model had assembled an average voice for an average reader who doesn't exist. It could describe a UPS or a chiller, but it could not decide which parts an operator would lose sleep over, which parts a salesperson would get in trouble for mis-stating, or which details an investor needed to understand to sign off on a deal.

That was the moment something clicked.

The operator's view, the view from inside the building after the design and construction, is still not well represented in the public material these models are trained on. Most public content tilts toward design, marketing, or very high-level cloud abstractions. The data center books that exist are usually written by design practitioners or academics, and a lot of online material is marketing-oriented. On top of that, there is now a huge volume of content from AWS, Microsoft, Google and others about "their data centers," but those are mostly from a cloud service provider point of view.

The vast in-between, the data center operator space, has far less written by people who actually run sites day to day. I am not claiming to be especially good; I am only willing to write from that space and accept that it will be critiqued.

The AI experiment wasn't a failure in the sense that "the model did a bad job." It did exactly what it is designed to do. The failure was assuming that straight AI output could ever substitute for the judgment, priorities, and scars that my real readers needed on the page.

Writing with the Intended Readers in Mind

The straight AI version behaves as if there is one generic "curious person" who wants to know everything about data centers in thin slices. That person does not exist. In real life, the room is mixed: an operator who has to live with the facility for 20 years, a salesperson who has to talk about it without overpromising, an investor or non-technical stakeholder who wants to understand risk and economics, and newcomers who are simply trying to understand where they might fit.

So I wrote down, explicitly, who I was writing for and what they needed:

• I want the book to be for newcomers or people evaluating a career in data centers, to learn about data centers in a realistic way.

• I want the book to be for non-technical professionals, so they can understand both the technical and business parts of data centers well enough to function credibly.

• I can only be fully authentic when I write from the data center operator's perspective, given my background and experiences.

Then I added what I wanted the book to do at an industry and ecosystem level:

• I want to explain the data center industry, which is being pushed by both scale and time pressure, using concepts such as the data center ecosystem.

• I want the "inside the operator" workings to be generalised enough to apply to most operators, via a data center operator value chain.

• The South East Asia data center operators' experience, given the impressive growth in this decade, would be valuable to incoming and current operators in this region.

• I believe operations is the least-covered content for data center operators, and yet, because of growing scale, it is becoming more important.

• I want to cover data center design and the electrical and mechanical infrastructure to just-enough depth. This point, in particular, triggered the six-month re-thinking and reboot phase.

• I want the book to be a tool for newcomers and experienced professionals to map their own "data center knowledge map" and see which knowledge subdomains they need to strengthen for the roles they are in or aiming for.

• I want to provide a reading map for different reader types, so they do not have to read every chapter, only the ones that help them.

And I also wanted the structure of the book to reflect the reality of how work and conversations actually flow inside a data center. After the introductory and concept chapters, I made a deliberate choice to write "from the inside out," starting with the IT and network side, and the meet-me room, because for most clients their requirements show up there first. That is where services are delivered, where circuits land, where handshakes between "cloud" and "facility" become real.

From that starting point, design, projects, and operations can flow more naturally. Once a reader sees how IT, network, and the meet-me room have to behave, it becomes easier to explain why the electrical and mechanical systems are built the way they are, why certain redundancies were chosen, and why operators who involve operations teams early usually face fewer problems down the road.

Once I was clear on these principles, I still didn't use the AI-drafted content. The chapters didn't align with my initial list of eight chapters, which grew to thirteen and then combined and dropped back down to twelve at around month fifteen.

The Slow Information Gathering, Reading and Writing

I had accumulated content and written portions of about 60 pages over the years. When I started writing the Data Center Primer, I had gathered six data center books and read two of them almost cover-to-cover and others for the parts that were useful. I checked the correctness of my concepts against them, and against Google search results, especially for operations content I had not dealt with recently.

I was so worried that my content would be mistaken as AI-generated that I used AI content-checking tools on my first couple of chapters. Negative, of course.

I had been writing for about six months and had produced over 260 pages. Introduction, Data Center Business, Project, Design, and partial Operations chapters were then whittled down to about 130 pages because of overlap and editing, which mainly removed duplicate content across chapters.

However, I then hit major roadblock caused by a few problems:

1. After starting the design chapter, it had grown to 40 pages and I had not yet finished the chapter.

2. The electrical infrastructure chapter and mechanical infrastructure chapter were each about 30 pages long.

3. If I fleshed out the Operations chapter, which I had decided to split into two chapters, it would be about 70 pages long in total.

4. Most crucially, the depth was diverging: the design, electrical, and mechanical infrastructure chapters were going longer and deeper than the chapters I had already written.

Those four problems, sitting together on the page, told me something a rewrite couldn't fix. The book didn't need better sentences. It needed a different decision about what kind of book it was going to be. That decision, and the six months it took to make it, belongs to Part 4.

The Transformation: Injecting Human Experience and Voice into Known Content

I did use ChatGPT to generate some section content, but mostly to see if my version was different or if ChatGPT's output contained something I had missed. I would then rewrite it and add my take on that point.

The key is transformation, adding value by informing and reinforcing with true experience, even if I need to replace or generalise the company or person involved to avoid causing problems.

To see what transformation actually looks like, consider something as simple as how you describe a UPS system. The AI version reads like this: “A UPS system provides backup power during utility supply interruptions, protecting critical IT loads from downtime.” That is correct. It will pass any technical review. It will also mean nothing to a newcomer standing next to one for the first time, or to a salesperson who has just promised a client four hours of backup runtime.

After transformation, the same point reads like this: “The UPS buys you time, usually ten to fifteen minutes, and in that window you find out whether your procedures are real or just laminated paper on a wall.”

The definition is the same. The voice and the intent are different. One version wants you to pass a quiz. The other wants you to survive a project. That was the moment I realised I wasn't editing sentences. I was deciding whose experience the book was written from, and for whom.

When I looked at the UPS again from an operator’s perspective, the real point clicked: the UPS‑plus‑battery combination is not “backup power” in the marketing sense; it is a ride‑through device. Its job is to buy you a small window while the generators start and your procedures are tested in real conditions, not to run the data center on batteries for half an hour. At modern loads, trying to hold long runtimes would turn the battery room into a small warehouse and still miss the real failure modes operators worry about. So I rewrote that section to talk mainly about ride‑through in the data center context. That kind of “viola” moment still doesn’t come from straight AI output; it comes from years of seeing how things actually fail.

In practice, transformation looked like:

• Reordering content around the questions I kept hearing in training sessions and corridor conversations, rather than following the AI-style table of contents mechanically.

• Putting in real cases. These stories are not decoration; they are not AI-generated. They resonated with the draft book reviewers who saw the alpha version.

• Explicitly ranking importance, being clear when something is critical for most readers, when it is useful context, and when it is specialist detail you can safely leave to designers or subject matter experts.

• Using diagrams and mental models, like the data center infrastructure stack and the operator value chain, to help readers orient themselves and see where their role fits.

• Reframing, reorganising, even rewriting a chapter when it is not right for the intended readers.

The same principle of transformation applied not just to AI-generated content but to my own original creation. The Data Center Knowledge Map was something I was passionate about from early in the project. I had conceived it as a comprehensive theoretical framework, the conceptual core that would anchor the entire book, sitting in Chapter 2 and explaining everything that followed in one diagram.

Testing it against the actual reader revealed the problem. The newcomer who needed orientation did not need a grand theoretical framework at the front of the book. They needed to get into the content and build their understanding progressively. The Knowledge Map, as originally conceived, was serving my ambition more than the reader's need.

It was eventually trimmed, repositioned in Chapter 12, and reframed as a practical tool: a template for any data center professional to build their own career-specific knowledge map, with mine as the example. The concept survived. The ego attached to it did not. That is what transformation looks like when applied honestly, even to your best ideas.

A Sustainable Workflow: Human in Driver Seat, AI as Checker

By the time I finished the Data Center Primer, my workflow had settled into a simple division of labour.

On the human side:

• I choose who the book is for, what outcomes I want for them, and which trade-offs I am willing to make in depth and scope.

• I decide the structure, the emphasis, the order of ideas, and which stories and diagrams earn their place on the page.

• I write and rewrite until the sentences sound like something I would actually say to a real person in a real room, with my name and reputation attached.

On the AI side:

• I use it to surface the "default AI answer" on a topic, then ask what a human reader would need and where I can add value to make it original.

• I use it to suggest missing subtopics I might have overlooked, especially outside my core operator comfort zone.

• One prompt I find useful is to ask: "If you are the target reader, would this be too much or too little content?"

• Occasionally, I use it to rephrase or tighten a sentence, but those sentences still go through my judgment and, usually, another round of editing.

The boundary is simple: AI is allowed to tell me "this information is already widely available" and "here's what the generic version sounds like." It is not allowed to decide what matters for my readers, how much space to give an idea, or what tone to take. That part is my job.

Part 1 of this series was about recognising the gap, testing the AI shortcut, and deciding that the book was worth 18 months of real work. Part 2 is about what happened next: refusing straight AI output as the core of the book, and instead putting the intended readers at the centre, using AI only as a background check while I did the real work of transformation.

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.