The hidden capex line item: social license to connect in Denmark

I have sat in enough project reviews to recognise a familiar kind of optimism. The grid connection will come through. The permits are “in progress”. The heat reuse agreement is “being discussed”. Someone has “a good dialogue” with the municipality.

Then the room gets surprised when the public meeting turns into a confrontation, the timeline slips, and the project suddenly needs a new narrative, a new technical design, and a new set of promises. As if legitimacy was something you could bolt on at the end.

The pattern is not unique to data centers, but data centers make it visible. When 300+ citizens show up at a town hall meeting and say they do not feel heard, you are no longer managing a permit. You are managing a clock, and a reputation that will follow you into every future application.

I call it “social license to connect”. Not because it is a slogan, but because it behaves like a connection agreement: you do not get to energise the project without it, and the penalties for getting it wrong arrive as delays, redesign, and a higher cost of capital.

My position is simple: treat social license as a capex line item. Price it. Staff it. Gate it. If you cannot do that, you are not ready to build.

Why this risk is different in Denmark

Denmark is not hostile to infrastructure. It is demanding about legitimacy. The surprise for many teams is that legitimacy is not granted by having a legally valid plan or an old zoning framework. You can be allowed and still be unwelcome. And unwelcome projects get slower, noisier, and more expensive.

What makes Denmark tricky is the combination of four drifts that compound each other:

• Permitting drift: the formal process is not just a checklist, it is a sequence of moments where objections can reshape scope.
• Planning drift: a project can be “compatible” with an area on paper and still collide with how residents experience noise, traffic, aesthetics, and risk.
• Commitment drift: heat reuse, local benefits, and sustainability claims start as intent and end up as expectations. If they are vague, they will be interpreted against you.
• Contract drift: grid-connection terms, curtailment clauses, and commissioning timelines are not independent of the above. Public pressure changes political appetite, which changes how hard every interface becomes.

The result is a new type of uncertainty. Not “can we engineer it?”, but “can we keep permission stable long enough to finish it?”

The expensive mistake: treating legitimacy like PR

Many teams respond to public tension with messaging. More slides. More renderings. More talking points about jobs and growth.

That is backwards. Legitimacy is not won by persuasion. It is won by making the project legible and constraining its downside in ways that ordinary people can verify.

When citizens say they are not being heard, as reported in the Tårnby meeting coverage, they are rarely arguing about compute. They are reacting to powerlessness. The fear is personal: property value, noise, traffic, security, and a sense that decisions are happening to them, not with them.

If you answer powerlessness with a brochure, you should expect escalation. Complaints become organised opposition. Opposition becomes media. Media becomes political pressure. Political pressure becomes tighter conditions. Conditions become redesign. Redesign becomes delay. Delay becomes cost.

This is why I want you to think of social license like any other engineering constraint: if you ignore it, physics wins. Just a different kind of physics.

The operator’s checklist for “social license to connect”

This is the practical checklist I would run before I let a team call a project “ready”. Not as paperwork. As a risk budget with named owners.

1) Define the community contract in plain language

• Write one page called “What we will not do”. Noise limits, traffic routing, construction hours, visual screening, security posture, and expansion boundaries. If you cannot commit, do not imply.
• Translate benefits into measurable obligations. “We will reuse heat” is not a commitment. “We will deliver X grade of heat at Y reliability to Z interface by date” is.
• Decide what you will publish. Trust comes from verifiability. Choose metrics you can report quarterly without spin.

2) Put a price on drift

• Create a social license contingency budget. Use it for design changes, extra studies, mitigation measures, and additional engagement. If it is unfunded, it will be stolen from construction later.
• Model schedule risk as scenarios, not a single date. Base case, delayed case, redesign case. Tie each to triggers you can observe.
• Make “reputational risk” a number. Not in the abstract. In cost of delay, cost of capital, and probability of additional conditions.

3) Lock heat reuse and local infrastructure promises early, or do not sell them

• Heat reuse is a technical interface, not a press release. Treat it like any other integration with external parties: clear specs, responsibilities, commissioning plan.
• Pre-commit to failure modes. What happens if the district heating counterparty is not ready? What if your load profile changes? Who pays for what, and how will residents experience the gap?
• Do not let “future potential” become “guaranteed impact”. If you talk about it publicly, assume it will be remembered as a promise.

4) Treat the grid-connection contract as a reputational document

• Align grid terms with what you have told the public. If you have promised low noise and low local impact but your contract implies diesel backup running tests at inconvenient times, you have a conflict.
• Stress-test curtailment and commissioning timelines against municipal uncertainty. A slip in permits can cascade into missed windows, changed terms, or expensive workarounds.
• Make one person accountable for interface coherence. Not “the team”. A single owner who can stop the train.

5) Design the public process like a product release

• Ship clarity early. A vague concept creates imaginary worst cases in people’s heads. Publish constraints, not aspirations.
• Build feedback loops you can act on. If you collect input and do nothing, you are training people to escalate.
• Decide what you will change and what you will not. A process that can change everything is as frightening as a process that changes nothing.

6) Put “municipal drift” on the risk register, explicitly

• Track plan dependencies. If a local plan from decades ago is the enabling mechanism, assume scrutiny will rise when the project becomes real.
• Map decision points and election cycles without cynicism. Not to manipulate, but to avoid being surprised by timing.
• Agree escalation paths. When a narrative turns against you, who meets whom, with what authority, and what concessions are allowed?

One lived lesson: interfaces fail where ownership is fuzzy

I learned this the hard way while rebuilding a connected-products portfolio: the projects that looked safest on paper were the ones with the most hidden interfaces. Hardware to cloud. Cloud to installers. Installers to residents. Everyone assumed someone else owned the seams. When issues appeared, they did not appear as “bugs”. They appeared as distrust and churn.

Infrastructure projects have the same seam problem, just with different labels. Municipality to developer. Developer to grid company. Data center to district heating. Construction to neighbours. If no one owns the seams, the seams become the story.

If this topic resonates because you are building energy or grid assets, you will recognise the same logic in curtailment risk allocations. The technical clause becomes a commercial fight later if you do not price it and assign it up front.

What I would do this quarter if I had a live project

I would make three moves immediately.

1. Create a single “license to connect” dossier that includes permits, grid-connection terms, heat reuse commitments, construction constraints, and what has been promised publicly. One source of truth.
2. Run a pre-mortem with named owners: “It is 18 months from now, and we are delayed. What happened?” Force the team to write down the drift scenarios and the early warning signals.
3. Fund the mitigation plan. If you cannot fund it, shrink the project scope or slow down. Speed without legitimacy is fake speed.

The point is not to be loved. The point is to be predictable, fair, and verifiable. That is what keeps schedules intact.

Technology is only worth building when it changes something real for people. A data center that destabilises a neighbourhood, even if it is legal, is not changing the right thing. If the project is genuinely good, you should be willing to make its impact legible and its downsides bounded. If you are not willing, you are telling on yourself.