Sovereign Cloud Programme Delivery Across 3 National Clouds

⚡ The Challenge

Some countries require that their data, and the people who can touch it, stay inside their own borders. Running cloud services under that constraint means rebuilding, per country, what the global platform already does once — and none of the groundwork existed yet.

No existing structure: no delivery framework, no documentation baseline, no agreed definition of “ready to operate”
Three countries: France, Germany and Singapore, each with its own legal boundary and its own local operations team
No direct authority: the engineering, product and partner teams involved sat under different leads — several inside the same organisation, none of them reporting to me
Audit from day one: everything had to stand up to inspection, not just work

The frameworks did not need improving. They did not exist.

🧭 My Approach

Make the invisible explicit, then hand it over.

1. Own the delivery end to end

I took responsibility for the whole chain that makes in-country operation possible: the infrastructure itself, the locked-down machines administrators use to reach it, round-the-clock security monitoring, the controlled routes by which staff in one country can work with another, and the migration of services into each environment.

Treating those as one programme rather than five separate projects is what made the dependencies visible — and dependencies are where this kind of environment actually fails.

2. Write the operating manual that did not exist

Over the programme I wrote 47+ standard operating procedures from scratch — the step-by-step instructions a local team follows to run the platform — plus the roadmaps for bringing all three countries onto a common standard.

The test for every document was blunt: can someone in another country follow this without asking me? Anything that failed was rewritten.

3. Govern without authority

None of the teams involved reported to me — several sat in the same organisation, just under different leads — so the governance had to earn its place rather than be imposed. I introduced:

Prioritisation rules, so competing teams argued about the criteria rather than the outcome
Go-live checkpoints, so “ready” was a shared, checkable state rather than an opinion
AI-assisted planning, to keep the coordination effort proportionate to the actual work

4. Enable, then step back

The goal was never to be the person who knows how it works. Training was rolled out and signed off in all three countries, so local teams and partners could run it without me.

📈 Results

100% audit-compliant results across every part of the programme
40% faster delivery lead times
Training signed off in all three countries
Partner organisations enabled to operate independently
Common platform standard adopted as the planning baseline across the organisation

📚 Lessons Learned

Starting from zero is an advantage, once. There is no legacy process to argue with — but you only get one chance to set a baseline before habits harden around whatever you shipped first.

Documentation is an interface, not an artefact. A procedure nobody can follow without asking the author is just a note. The handover test has to be applied while writing, not at the end.

Regulatory boundaries are organisational before they are technical. The hard part is rarely the control itself; it is agreeing who owns it, who proves it works, and who gets woken up when it fails.

Governance without authority runs on legibility. People align to a framework whose logic they can see. Clear prioritisation criteria and go-live checkpoints did more for alignment than any escalation path.