DCD Connect London 2026 was 6RG’s first real dip into the data center world, and it was very much a fact-finding mission.

We wanted to better understand the sector, listen to the people already working within it, and consider whether our experience could bring a different perspective to the established QA/QC roles and services already supporting data center delivery.

6RG provides independent client-side MEP Clerk of Works and QA/QC services. A large part of our approach is based on listening and understanding the different perspectives of the client, designers, contractors, and end users, and providing a measured, independent view across those groups.

That was the lens we took with us to DCD Connect.

We were not there to assess how the industry is doing things or to arrive with answers. We were there to listen. After two days of discussions, presentations and conversations, we came away with a number of observations that challenged some of our own thinking.

Interestingly, many were not purely about MEP or construction quality. They were about stakeholders, social value, local engagement, “social licence”, due diligence, infrastructure, changing technology, and how information and commitments move through a project.

These are our DCD takeaway thoughts.

“Social licence” — or simply local engagement?

One of the first things that caught our attention was the terminology.

“Social licence” was one example.

Coming from outside the data center sector, we found ourselves asking whether the data center community was putting complicated terminology around something that is fundamentally much simpler: local engagement.

But even “local engagement” can suggest that the starting point is talking to people. From our own experience, listening and understanding the different groups around a project is fundamental to building trust. What interested us at DCD was how strongly that same principle appeared in discussions around data center development.

Some local concerns will be physical and relatively easy to identify: power, water, drainage, noise, traffic, jobs, and local economic benefit.

Others may be much wider: who benefits, who pays, who controls the infrastructure, what the development means for the area, and whether investment in data centers is happening while other local needs remain unmet.

Those questions cannot always be answered by another technical explanation.

One of our first takeaways was therefore simple: before explaining the benefits of a data center, it is important to understand what the community is actually worried about.

Listen first, then understand the technical question

A developer will naturally bring people who understand different parts of a project — designers, engineers, construction teams, technical specialists, communications teams, and others. Each has their own professional knowledge and language.

What caught our attention was the potential gap between the technical question a project team thinks it is answering and the concern a stakeholder is actually raising.

Take power. A local resident might ask why a data center is going to use so much electricity. The technical response could explain demand, capacity, grid infrastructure, or efficiency.

But perhaps the question behind the question is: “My electricity bill is already expensive. How can this development secure all this additional power? Who is paying for the infrastructure needed to provide it, and could any of that cost ultimately come back to us?”

That is a different question.

For us, the observation was less about simplifying technical language and more about making sure the technical response addresses the concern that was actually raised.

Listen → understand the concern → establish the facts → respond clearly.

The closed-loop car analogy

Water provided another interesting example.

An analogy discussed around cooling was the comparison with a car. A petrol or diesel car needs cooling. Water or coolant circulates through a closed-loop system, and some data-center cooling systems work on a broadly similar principle.

It is a useful analogy, but a closed loop does not mean that no water has been used.

A new car’s cooling system still needs to be filled. Coolant needs checking, treating and topping up, and during major maintenance it may need to be drained or replaced. The principle can be similar for a data center system, albeit at a completely different scale.

That does not make the analogy wrong. It made us think about where an analogy stops.

The problem is not the car analogy. The problem is stopping the analogy at the point where it gives the most reassuring answer.

A more complete explanation might acknowledge that water is used, explain why and at what stages, describe how demand is reduced or managed, and show how flushing, commissioning, treatment, maintenance, and eventual discharge are controlled.

The same principle could apply to power, drainage and other environmental impacts: acknowledge the impact, explain how it is managed, and retain the evidence.

How early is early enough?

Another discussion that stayed with us concerned an engineer presenting RIBA Stage 2 information during early local engagement.

The challenge was clear. At Stage 2, the design is still developing, and many of the detailed answers simply do not exist. However, from a local perspective, being asked to engage with a proposal that is still at an early stage can make it difficult to understand exactly what the finished development will mean for the area.

Leave engagement until later, and there may be more information available, but there is also less opportunity for what is heard to influence the developing project.

That was the interesting part for us. The issue wasn't simply whether engagement should happen early or late, but what early engagement is actually trying to achieve.

At an early stage, perhaps the value is not in arriving with all the answers. It is in explaining what is currently known, being clear about what is still developing, and most importantly listening to the concerns that should be investigated as the project moves forward.

Those concerns can then be taken away, understood properly, and brought back with clearer information as the design develops.

That left us with a simple sequence: Listen early → understand the concerns → investigate them → respond as the project develops → keep listening.

Where does due diligence fit?

This was where several of our DCD takeaway thoughts began to join together.

Land, planning, power, water, drainage, connectivity, and technology all need to be understood before major commitments are made. The discussion around due diligence highlighted how quickly a simple answer can become a dependency.

Take power availability. The question might be: Does the site have access to the required power? The answer could be yes. But the complete answer might actually be: Yes — provided the local grid is upgraded first.

That is a very different “yes”. The data center is now dependent on another project.

A conditional yes is a dependency, and a dependency is a risk that needs to remain visible until the condition has actually been satisfied.

One of our observations was that good due diligence can sometimes look like a bottleneck, precisely because it exposes the complexity hidden behind a simple answer. It has not created the complexity; it has made it visible.

Should local concerns receive the same visibility?

This brought us back to stakeholders, social value, and local engagement.

At the earliest stages, due diligence may ask: Do we have the land? Can we get the power? Is the water available? Can drainage and discharge be achieved?

The DCD discussions made us consider whether significant local concerns should sit much closer to those same early questions: What are the local communities' red lines; what can they not accept? What do they want to see happen?

That does not mean every objection determines whether a project proceeds, or that every request can be accommodated. It means understanding the concern, the reason behind it and whether it introduces a condition, commitment or risk that should remain visible.

There is another side to this. Local people may hold knowledge that does not immediately appear in a desktop assessment — the history of an area, flooding, traffic, previous developments, infrastructure problems or environmental conditions.

That made us consider local engagement not only as communication, but also as a potential source of due-diligence information.

Build on firm ground and firm relationships.

And then what happens to what was said?

This may have been our biggest takeaway.

If a concern is raised and the project responds with an explanation, evidence, mitigation, or a commitment, what happens to that information afterwards?

If something was said to build local confidence and help a project move forward, does it remain visible when responsibility moves from development into design, construction, commissioning and ultimately operation?

Or does it remain in consultation records and presentations?

That led us to a simple thought: If it's said to gain local confidence, then record it, carry it out, and prove it.

We could see a clear connection between engagement, due diligence, and delivery:

Local engagement identifies the concern. Due diligence captures the response, evidence and commitments. Delivery demonstrates whether they were honored.

The same principle applies to a technical dependency. If power availability relies on a grid upgrade, that dependency does not stop being important because construction starts. The discussion made us ask why a significant stakeholder commitment should be treated differently.

Equal visibility at due diligence should mean continued visibility through delivery.

Due diligence in a fast-moving sector

There was another dimension to the due-diligence discussion that particularly interested us: time.

A data center development can have a long journey from initial site identification to operation, while the technology it is intended to support can change much faster.

That raises a useful question: should due diligence only establish whether a technology is appropriate at the point of review, or should it also consider the rate at which that technology is changing?

Some decisions need to be fixed early. Others may need to remain flexible. Some conclusions may benefit from a planned point at which they are deliberately reopened and reviewed.

Our takeaway was that good due diligence does not only look for the answer. It also looks for what could change the answer.

What did we take away from DCD?

DCD Connect gave us exactly what we went looking for: a better understanding of the sector and plenty to think about.

Looking at the discussions through our own experience of independent client-side QA/QC also left us with a question to explore: could an independent MEP Clerk of Works perspective enhance the QA/QC structures already established within data center delivery?

For us, enhancement does not mean replacing existing QA/QC teams, designers, contractors, commissioning specialists or technical advisers. It means considering whether an additional independent client-side view could strengthen the connection between what was required, what was designed, what was installed, what was tested and the evidence of what was ultimately delivered.

That question needs more than two days at an industry event to answer.

But DCD Connect gave us a valuable first look at the sector, a different perspective on several familiar project challenges and, most importantly, a clearer set of questions to investigate further.