The north star I keep coming back to is a data centre that runs itself: a site that measures what's happening, decides what to do about it and acts, with people setting the goals rather than turning the dials. I work in data centre systems engineering, and that's the lens I bring to most problems now. Most of the conversation about autonomous data centres is about the last step, the control layer, the models and the robots. I've found the more useful question is what has to be true before any of that can work, and the answer is mostly decisions about data, made long before anyone writes a controller.

One way to break it down is the lifecycle: land and power, design, construction and operate, with one metric for each that tells you whether it's going well. Nothing can be automated until it's measured, and nothing can be measured well until you know where the numbers come from. What follows is how I approached it, and the decisions I'd make again.

How I approached it

I joined a team that was already doing a lot. There were plenty of good pieces of work in flight, plans, decks and a long backlog, but there were gaps between them, and the vision we were heading towards was clear as an ambition and blurry as a plan. That's normal for a young team with a big goal, and the risk in that situation is either piling more activity on top or tearing it all up and starting again. I didn't want to do either.

I started with a single number. Rather than trying to define autonomy, I picked one number the whole business already cares about and that autonomy should ultimately move: how much value we get from every unit of capacity we build and power. It doesn't have to be perfect, but it does have to be one the business recognises, so it isn't a systems team inventing its own scorecard. It gives everyone the same question to ask of their work, whether it helps move the number or helps measure it, and that turns a vague vision into something you can argue about concretely.

I didn't decide the inputs myself. I worked back from that number with the people who run each part of the business and asked what drives it, which gave one metric per lifecycle stage: what we pay for power at land and power, how efficient a site is meant to be against how efficient it actually is at design, whether capacity is ready on plan at construction, and value per unit of capacity at operate. One metric per stage rather than ten means each part of the business can see its own contribution, and the conversation stays on outcomes rather than activity. The business owns the definitions, and the systems side's job is to make them measurable.

Only then did I break each metric down into systems: what data it needs, which system holds that data today, who owns that system, and whether the data is metered, billed or modelled. That's where the vision becomes a concrete list of sources, owners and access asks, and it's also where the gaps between the existing pieces of work show up clearly, because you can see which sources nobody is working on and which work doesn't feed any metric.

With the number, metrics and systems laid out, I went back through everything already in flight and sorted it into keep as it is, keep but change, park for later, or stop. Most of it carried straight across, it just hadn't been connected to an outcome before. Nothing was deleted, and parked work stays visible so it can come back when its metric is ready. Treating it as a transition rather than a reset kept the team's momentum and made the whole conversation much easier.

The last step is planning backwards. Each metric moves through the same stages: the number is defined, its sources are connected, and then it's live and signed off by the business. Working back from those stages tells you when you need each source, and from there when you need to ask for access, which is where the rest of this article comes in.

What I like about this is that it's top-down for direction and bottom-up for reality. The single number gives direction, the business gives the metrics, and the systems tell you what's actually possible. It gives a new team a shared language quickly, because everyone can say which metric their work feeds, and it avoids two common failures: building a platform first and hoping it's useful, or chasing the vision directly and getting stuck at what autonomy even means. One number at the top sounds reductive, but it's what makes the rest of the structure possible.

There are two things I'd do differently. I'd go to the business for the metrics even earlier, before looking at any systems, because their definitions change what data you need. I'd also present the mapping of existing work as what carries across from day one. My first instinct was to list gaps, and that reads as a judgement on people's work even when it isn't meant as one.

Decide what kind of number you're looking at

Ask for any number and someone will point you at the source everyone uses. Quite often that source is a planning model, with usage estimated from capacity and assumptions. That's a reasonable thing to have and it does the job it was built for, but it isn't actuals, and it's easy for a model to quietly become the number because it's always been good enough.

So the first question I'd ask about any source is whether it's metered, billed or modelled. Metered means a device measured it, billed means someone charged you for it so it's been reconciled against something real, and modelled means someone did a calculation. All three are useful for different things, but only the first two are safe to automate against. Real-time data is nice to have, and batch or even manual updates from bills are a perfectly good start, as long as they're actuals.

What goes wrong if you skip it

Build a metric on a modelled source and it will look fine. The dashboard renders, the numbers are plausible, and every measurement downstream is off. The first time someone reconciles it against a bill you lose trust from the business, and trust is the thing an autonomy programme can least afford to lose, because the end goal is letting the system act on its own numbers.

I wrote about a version of this in AI without a system of record is just chat: the intelligence layer is only as good as the record underneath it, and in a data centre a lot of that record is physical.

Decide who owns each source before you build

The next decision is about people rather than pipes. For every source you'll need, work out who owns it, who can say yes to access, and when you actually need the data. Missing owners turn up more often than you'd expect, and finding one usually takes longer than anything technical. The engineering to pull data from a system is days of work while getting access approved is weeks, so the asks go out before anything gets built.

In theory of constraints terms, access is the constraint, so that's where the plan starts (I've been building a small site on software constraints if that framing is useful). Before designing a new way to get data out of a site I'd also look for one that already exists, because reusing it can save a lot of security and approval work.

Decide what you can't ship without

Not every source will be clean, available and deployed, and understanding that early is better than assuming you can just get everything. So I'd tag every source for every metric as one of three things: required, which means the metric can't ship without it, enhancer, which makes it better but doesn't block it, and alternative path, where there's another route to the same number if the first one doesn't come through.

That tag is what sets the order, because a metric goes live once its required sources are in, without waiting for the rest. A metric missing an enhancer or two is still far more useful than a perfect one months later. I'd do the tagging before writing a roadmap, not after, because it's what tells you what the roadmap should be.

Existing sites are harder, and they have the history

A new build lets you design the data in from the start. An existing site has controls that were built to run the building rather than to be read by anything else, and documentation that rarely matches reality. It's also the only place with history, and you can't learn how a data centre behaves from one that hasn't run yet, so I'd start those conversations early rather than leave them to the end.

Lesson

None of this is the exciting part of autonomy, and none of it needs any code. The order I'd recommend is to find out whether the data is metered, billed or modelled, find the owner, tag what's required, and ship each metric as soon as its required sources are in. The control layer comes later, and it stands on whatever you got right here.