Data centres are bringing completion bonuses back – but Reward needs to design them properly

If you want to understand why employee “completion bonuses” are having a moment, don’t start with remuneration theory. 

Start with the labour market. Or, more specifically, start with what the labour market is doing to data centre delivery teams.

In data centres, the final stretch of a build has become a predictable pinch point: long hours, complex interdependencies, commissioning pressure, heightened incident risk and intense scrutiny from investors and customers. It is also the moment when attrition becomes more damaging. One commissioning lead or design authority moving at the wrong time can turn manageable slippage into something much more serious.

And in this asset class, missed energisation or readiness dates do not just delay revenue; they can reprice financing, disrupt customer commitments and knock on across an entire pipeline.

That is why completion bonuses are back.

Not as a gesture. Not as a generic “thank you”. And not because everyone has suddenly rediscovered milestone pay.

They are back because, in some situations, the cost of losing key people in the final stretch is much higher than the cost of paying them properly to stay.

Why schedule certainty is now a reward issue

Data centres sit at the intersection of capex intensity and revenue timing. When capacity is scarce and demand is hot, the incremental value of hitting commissioning dates is disproportionate. It is not unusual for financing, tenant commitments and future phases to depend on the first tranche of capacity going live on time.

So yes, data centres are “all the rage”.  And you can read more of our data centre content and coverage here.

But what boards, investors and customers actually care about is more basic: can you deliver the asset, energise it, commission it and get it operating reliably under real load, without drama?

Once that becomes the commercial objective, the reward implications are not far behind.

Employers face a relatively simply choice. 

Do we embed the scarcity premium in base salary (forever)? Or, do we pay it as a targeted, time-bound upside tied to the hardest phase of the programme?

Completion bonuses are the second answer.

They are not always elegant. They are not always perfect. But they are often a more honest solution than permanently increasing fixed pay to solve a temporary, acute delivery problem.

The contracting logic is moving into reward design

Completion bonuses are not new. Construction contracts have long used early-completion incentives, liquidated damages, holdbacks and acceptance regimes to align behaviour around delivery risk.

What is newer is how explicitly that logic is being mirrored internally, which makes sense.

The commercial risk is not just whether the building exists. It is whether it works.

A data centre can be technically complete and still be carrying operational debt. Cooling problems. Controls issues. Alarm volumes. Network latency. Tuning defects. Customer ramp-up problems.

In other words, the project can “finish” on paper while the real operational risk has simply moved to someone else.

That is the danger with a badly designed completion bonus.

It can reward “build and bail”:

• get the project over the line;
• trigger the bonus;
• move on; and
• leave the operating team to discover what was missed.

That is not reward design. That is just paying for paper completion.

What “completion” should actually mean

A reward scheme fails fast if “completion” is treated as a vibe rather than a definition.

In a data centre build, completion is usually a chain. For example:

1. Energisation (utility connection achieved and evidenced).
2. Commissioning / integrated systems testing (agreed systems passed).
3. Handover and early-life performance (the facility works reliably for a defined period after handover).

That third stage is the important one.

Without it, the bonus pays when the project appears to be finished, not when it has proved it can operate.

That matters because the awkward issues often appear only once the site is live: thermal instability, controls tuning, alarm overload, network issues, customer ramp-up friction. Those are the things that damage customer confidence and create cost long after the delivery team has moved on.

This does not mean the standard should be “everything must be perfect”. That is unrealistic and unfair.

It means the plan needs a small number of clear, high-signal tests that reflect how the site is actually delivered and operated.

A simple micro-example

A sensible structure might look like this:

Not a perfect model, but it shows the point.

The plan should not pay merely because someone can point to a date in a programme tracker and say “milestone achieved”.

It should pay because the relevant milestone has been evidenced, tested and has commercial substance.

The reward design point

The hard part here is deciding what you are buying.

Are you buying retention? Are you buying speed? Are you buying quality? Are you buying a stable handover? Or are you buying all of those things, but at different stages?

If the answer is not clear, the plan will probably become a dispute.

The main design points are usually these:

• Be tight on scope. If everyone is included, the plan becomes an entitlement. If too few people are included without explanation, it becomes a grievance.
• Define the milestones properly. If it cannot be evidenced, it should not drive pay.
• Do not pay only for speed. That is how safety corner-cutting creeps in.
• Deal with external delays. Grid, utility and supplier issues may sit outside employee control, but carve-outs need to be documented rather than left to discretion.
• Make leaver treatment sensible. Absolute forfeiture may be commercially attractive, but it can feel unfair where someone has already delivered most of the relevant value.
• Avoid double payment. Map employee incentives against contractor incentives and ordinary annual bonus outcomes. Do not pay twice for the same delta.
• Keep malus and clawback usable. Focus on serious issues: misconduct, fraud, safety breach, material misstatement or certification error.

Failure modes to call out (because they will happen)

Completion bonuses go wrong in fairly familiar ways. 

They create “get it over the line” behaviour. They encourage teams to argue about who really delivered the milestone. They reward visible heroics rather than boring operational discipline. They turn into quasi-contractual entitlements.

Or they pay out just before everyone discovers that the site “passed”, but cannot yet cope properly under live load.

None of that means completion bonuses are a bad idea.

It just means they need to be designed like reward, not copied across from a contractor schedule and dropped into employment documents.

Final thoughts

Data centres are forcing Reward to do something it doesn't always like: be explicit about what it is buying. Not effort in the abstract but continuity and safe, stable delivery through commissioning, handover and early-life performance.

Design the bonus like reward: clear line of sight, objective evidence, early-life performance that actually bites, fair leaver mechanics and quality / safety gates. Otherwise, it will behave like a contractor payment: gamed, disputed and ultimately ineffective.

At Burges Salmon, we work with employers to design completion bonuses for data centre delivery teams that actually function in the real world: the measures are evidential, the line of sight is credible, the leaver treatment is defensible and the plan dovetails with annual bonus, contracts and governance.