Systems change. The underlying problems usually don’t.

My early career was deeply hands-on. I designed, deployed and operated enterprise infrastructure across telecommunications, banking, insurance, government and other regulated environments, often supporting thousands of users and endpoints.

The work crossed identity and messaging, virtualisation, high availability, disaster recovery, PKI and digital signatures, storage, backup and endpoint security. In telecommunications, that meant integrating separate Active Directory and Exchange environments. In banking and government, it meant building systems where security, continuity and recoverability could not be left implicit.

Years spent operating these environments shaped everything that followed. By the time I began designing platforms and leading organisations, I had already seen how the underlying systems behave when documentation is incomplete, assumptions are wrong and failure arrives at the least convenient moment.

I joined during the integration of two insurance organisations. The business objective was straightforward; the infrastructure underneath it was not. Separate identity, messaging and file-service environments had to become a consolidated platform while operations continued across countries.

I planned and technically led the infrastructure work with the project-management function, while remaining hands-on during critical stages. The programme covered Active Directory consolidation, Exchange modernisation, the transition between the UK and Germany, capacity and mailbox sizing, DFS and file services, Azure AD synchronisation, migration sequencing and operational cutovers.

Discovery exposed technical debt, historical sizing assumptions and dependencies that were not sufficiently documented. That changed the plan: instead of treating the legacy environment as a fixed starting point, we first stabilised the areas that would have become constraints after the organisations were combined.

The migration used controlled, sequential switchovers with prepared recovery paths. Incidents were not treated as proof that planning had failed; the architecture was designed to keep them recoverable and contained. My wider work included planning for the European headquarters move from London to Luxembourg, email archiving, firewall and storage modernisation, and refinement of ITSM and ISO 27001-aligned practices.

Sky Germany already operated a significant virtualised estate. But virtualisation alone is not a cloud, and much of the operating model remained traditional and dependent on external delivery. The real question was how to turn existing infrastructure into an internally controlled platform.

Working with colleagues across the wider Sky organisation, I helped shape a Virtual Data Centre platform spanning locations in Germany and Italy. It introduced automated provisioning, security hardening by default, a service catalogue, lifecycle management, cost transparency and a direction based on Infrastructure as Code, GitOps and SRE principles.

Building the platform was only the beginning. The existing estate had to move onto it, which required changes across network and security architecture, automation and legacy application support. The wider portfolio grew to include a multi-cloud Kubernetes platform, Puppet-based configuration management, formalised vulnerability and lifecycle management, storage and data-protection modernisation, and managed file transfer.

The organisation evolved with the technology. A small team grew into a broader platform function spanning local and offshore engineering, clearer ownership and dedicated capabilities. My responsibility eventually extended into enterprise licensing, vendor management, procurement, annual budget planning and investment prioritisation.

Moving into C-level responsibility changed the unit of work again. The question was no longer only how technology should be built, but how the organisation should make technology decisions.

One priority was establishing a formal IT service-management capability. The organisation could perform the work but could not consistently answer basic management questions: What is our service level? Where does demand originate? What remains unresolved? Where are the bottlenecks? ITSM created a common service model and measurable operational performance through SLA, volume, resolution and trend data.

I introduced a clearer separation between Build and Run responsibilities, explicit ownership through RACI, and management reporting that made performance visible rather than anecdotal. Collaboration could remain flexible; accountability could not remain ambiguous.

Following wider organisational integration, previously fragmented capabilities began moving toward group standards. Microsoft and AWS licensing portfolios were consolidated, common hardware standards were introduced, support moved toward a shared model and a common ITSM foundation began expanding across the organisation.