I decided to stay in the industry and continue my career elsewhere. The direction was right, although neither I nor anyone else could have described exactly what the market would look like twelve years later. We could see the growth of data, but not the precise workloads, equipment or power densities that would follow.

I think about that experience often because data centre developers are again making long-term decisions amid considerable technological uncertainty, now at far greater scale and pace. A facility may cost more than a billion dollars, take years to build and operate for fifteen years or longer. Meanwhile, the AI technology it is intended to support can change while it is still under construction. We are building 15-year assets for technologies that can change every six months. That is the defining challenge of the AI era.

Much of the industry discussion is understandably about meeting immediate demand. Customers want capacity, power is difficult to secure and nobody wants to miss a period of exceptional growth.

However, I am concerned that we are allowing the urgency of AI deployment to narrow the way we judge infrastructure. We hear how many megawatts a project will deliver, how quickly it can be energised and what rack densities it will support. We hear much less about whether the same facility will be straightforward to maintain, safe to operate and capable of adapting once the first generation of equipment is no longer there. The biggest risk in AI infrastructure is no longer underbuilding or overbuilding; it’s building for the wrong generation of AI.

Forecasting used to mean estimating how much capacity a customer might need. Today, the uncertainty extends much further into the technical design. Developers must form a view on future rack densities, cooling methods, electrical distribution and the type of customer the facility is likely to serve. Those choices affect one another, and they are being made before the industry knows which AI architectures will become established.

An anchor tenant can reduce some of this uncertainty. It gives the project a defined requirement and supports the commercial case for investment, which is why finding the right anchor tenant has become almost as important as securing land and power. Nevertheless, there is a risk in treating the first customer’s requirements as a permanent description of the asset. A facility designed very closely around one platform may work extremely well at launch and then prove difficult to use for the next platform.

I would therefore begin a new design by asking where change is most likely to occur and how much of that change the facility can absorb. This does not mean installing every possible system in the first phase. Overbuilding can damage returns just as surely as underbuilding can restrict growth. The practical objective is to create a route between stages: modular power capacity, cooling systems that can accommodate different operating conditions, monitoring that provides a useful view across the facility, and enough physical and electrical flexibility to make later expansion realistic.

There is often pressure to minimise capital expenditure by installing only what present demand supports. Financially, that can be reasonable. It becomes a problem when future capacity exists only as an assumption in a presentation. Adding critical power or cooling inside a live facility is disruptive and usually more expensive than expected. If the expansion route has not been engineered at the beginning, it may not be a route at all.

Some of the strongest projects I have seen were not the cheapest in their first phase. Their advantage became apparent later, when demand changed and the owner still had choices. In a market where nobody can forecast the workload mix with confidence, retaining choices has a measurable commercial value.

The industry should apply the same reasoning to redundancy. We have become accustomed to describing reliability through additional systems and paths. If one component fails, another is available; if one path is isolated, another continues to carry the load. The engineering logic is sound, but the operational result depends on how the complete system behaves.

Every additional layer has to be controlled, tested and maintained. It creates more operating states and more interfaces between equipment. During normal conditions, the architecture may appear straightforward. During maintenance or a fault, operators have to understand which elements are genuinely independent, how controls will respond and whether an action in one part of the system changes the risk somewhere else.

One of the most useful lessons from my early career was that reliable equipment does not necessarily add up to a reliable facility. Individual products may perform exactly as specified while the wider system still fails because of an integration issue, an incomplete procedure or a maintenance error. The interfaces are often where the surprise occurs. This is difficult to capture through a list of component specifications because the quality of each product is not the question; the question is whether their combined behaviour has been properly understood.

For this reason, I am cautious when complexity is presented as resilience without equal attention to operability. A design can have impressive redundancy on paper and still leave the operating team uncertain during an abnormal event. That uncertainty matters because decisions then have to be made under pressure, perhaps with incomplete information and little time to test an assumption.

Maintainability should be discussed while the architecture is still being developed. It is too late to discover at handover that routine work requires difficult switching arrangements or leaves the facility in a condition the operators do not fully trust. The people who will run the site need an effective role in design reviews, and the design needs to be assessed through realistic operating and maintenance scenarios rather than only against its intended steady state.

AI did not create the power challenge; it simply accelerated a transition that the industry could postpone for years but can no longer ignore. Efficiency improvements were pursued within relatively familiar AC power architectures for many years. The industry reduced conversion losses, improved equipment performance and lowered PUE. This work remains relevant, but high-density AI has changed the scale of the power distribution problem inside the facility.

When a rack requires hundreds of kilowatts, the implications extend beyond the rating of one piece of equipment. Current levels, cable quantities, conversion stages, available space, heat rejection and maintenance access all become more difficult. Electrical and cooling design can no longer be treated as parallel workstreams that meet at the rack. They are parts of the same problem, because almost every decision about delivering power also affects how heat can be removed and how much usable space remains.

I have supported greater adoption of DC power architectures for several years. Previously, I made the case mainly in terms of efficiency. Reducing the number of conversion stages could lower losses and improve overall energy performance. AI has given the discussion a different urgency. Higher-voltage DC distribution may become important because it offers a practical way to deliver very large amounts of power without some of the current, cabling and space constraints that conventional distribution encounters at extreme densities.

I do not expect every facility to move to the same architecture, nor do I think DC should be treated as the latest universal solution. Existing systems, customer equipment, regulation, operational capability and project economics will all influence adoption. What has changed is the reason for examining it. The conversation is moving from whether DC offers an efficiency improvement to whether established architectures can remain practical as the power required at rack level continues to rise.

This is also why energy availability will define the next phase of digital growth. The industry has spent decades discussing advances in servers, storage and networking as the drivers of capacity. Increasingly, the limiting factor is whether reliable power can be secured and converted into usable compute capacity at an acceptable cost. A company may have access to capital and the latest IT platform, but neither can compensate for a grid connection that will not arrive or a facility unable to distribute the available power effectively.

There is a visible imbalance in the way many projects allocate attention and money. Buildings, generators, UPS systems and cooling equipment receive enormous investment. The operating workforce and the systems that give them visibility across the facility often receive less consideration, even though they will be responsible for protecting that investment every hour of the year.

Operational capability is easy to undervalue before a facility is live. It is difficult to place a number on the outage that an experienced operator prevents, or the equipment life gained through better maintenance and control. Problems become visible later, when teams have incomplete information, procedures do not reflect the actual system or an issue in one discipline is not recognised as part of a broader pattern.

Digital tools can improve that situation if they support decisions rather than simply generate more data. Operators need to understand individual equipment and how capacity, energy performance and resilience are changing across the system. A large volume of alarms is not operational visibility if the relationships between them remain unclear.

The operating model should consequently be developed alongside the engineering design. Staffing, competence, maintenance philosophy and system information affect what level of complexity can be managed safely. A technically possible architecture is not automatically an appropriate one for every organisation. If the operating team cannot test it, maintain it and respond to it confidently, the gap will eventually become a business risk.

This point also belongs in the sustainability discussion. Much of a facility’s environmental performance is determined through ordinary engineering and operational decisions: conversion losses, cooling set points, equipment life, maintenance quality and the ability to reuse infrastructure for changing workloads. A building that requires substantial rework after a few years is not a particularly sustainable outcome, even if its first-year figures were strong.

My decision in 2014 was based on a broad conviction that digital infrastructure demand would grow, not on an accurate prediction of the systems we are installing today. There is a useful lesson in that distinction. We need a view of where the market is moving in order to invest, but we should not confuse confidence in the direction with certainty about the destination.

The data centre industry clearly needs more capacity, and AI will account for a significant share of it. The difficult work is deciding which parts of the current requirement should define a fifteen-year asset and which should be allowed to change. In my experience, that decision cannot be made by engineering or finance in isolation. A technically elegant solution can fail commercially if it cannot support customer outcomes, while a low-cost solution can become expensive if it removes the owner’s ability to respond later.

I began my career believing that the strongest technical proposal would be recognised automatically. Over time, I learned that customers do not invest in technology for its own sake. They invest because they need capacity, continuity, manageable risk and the ability to serve their own customers. Engineering expertise becomes valuable when it helps them achieve those outcomes and understand the consequences of the choices in front of them.

As AI development accelerates, there will be pressure to make each project answer the immediate market as precisely and quickly as possible. Some of that pressure is unavoidable, and some of it is healthy. But a data centre will live through several technology cycles, changes in customer demand and countless maintenance events. We should judge its design with those years in mind, rather than allowing the requirements of its first day to become the limits of its future.