Beyond the Cable: Resilience in the Shift from Infrastructure to Culture

And it’s not just the new kids on the block that need a helping hand to get started, get momentum, or find their balance. I’ve been struck more and more recently by how cloud migration, change management in IT, and the shift from Waterfall to Agile is not actually dependent on the technology, products, or platforms — but on a deeper cultural shift within organisations.

We’re moving from environments where expertise was built on physical systems — coax, cabling, server rooms, on-prem infrastructure — to cloud ecosystems where those physical touchpoints disappear entirely. Cloud providers will never step inside most organisations’ data centres, because there often aren’t any anymore. Even the idea of “knowing where things are” has fundamentally changed.

For many experienced engineers, that shift can feel unsettling. It can look like redundancy — like the skills that once defined your value are no longer needed. There’s no longer a need to carry pliers around the office if your entire environment now exists as code, APIs, and managed services. So the question becomes: where is your place now? How do you find your next step in an industry that is moving this fast?

This is where Agile thinking starts to matter in a more meaningful way. Not just as a delivery methodology, but as a mechanism for exploration. Creating a spike to understand dependencies in a data migration project, or experimenting with how cloud-native data platforms are structured, becomes a way of rebuilding confidence and context. Setting up cloud environments, working with infrastructure-as-code, or experimenting with services like identity platforms, data pipelines, or serverless functions are often the first practical steps back into relevance.

In larger organisations, there is often support in the form of technical advocates or enablement teams who can guide engineers through those early stages of transformation. But even with that support, the real shift happens when people engage with the change itself — not just as a project requirement, but as a personal evolution in how they work.

For me, it helped to actively explore. Attending conferences, listening to how others approached migration journeys, and understanding what actually worked in practice versus what looked good on paper. There is real value in seeing how different organisations solve the same underlying problems in different ways.

It also becomes important to play with the technology directly. Not in a production sense, but in a safe, experimental way. Setting up data structures, provisioning infrastructure through code, deploying small services, or experimenting with identity and security tooling. These are no longer heavyweight exercises — most of this can now be done in virtual environments, often quickly and at low or no cost. They become “taster environments” for learning, without the pressure of production responsibility.

Because ultimately, it’s not access to technology that is the barrier anymore. It’s not even training — the resources are everywhere. The real challenge is mindset. The cultural shift in how we see ourselves inside these systems, and how we adapt when those systems no longer look like the ones we built our careers on.

That shift is particularly hard when it happens at scale — when entire teams, deeply embedded in legacy systems, are expected to move together. It’s not just a technical migration; it’s a human one. And that’s where leadership, patience, and structured change become just as important as any architecture or platform decision.

Because in the end, resilience isn’t just about systems staying up. It’s about people being able to move with them.