The cloud infrastructure world is buzzing right now. AWS, Azure, and GCP are pouring unprecedented capital into AI infrastructure — combined hyperscaler capex is forecast to approach $700 billion in 2026, nearly doubling 2025 levels (Futurum Group, Feb 2026). AWS just launched EC2 M8azn instances hitting 5 GHz CPU frequency — the highest in the cloud (AWS, Feb 2026). Amazon Bedrock now supports PrivateLink across 14 AWS Regions via Project Mantle (AWS Weekly Roundup, Feb 2026). And HashiCorp has launched Agent Skills, baking AI-native capabilities directly into Terraform infrastructure workflows (HashiCorp, Feb 2026). The pace is relentless.
And at the centre of all of it? AI workloads are driving what I’d call a genuine second wave of cloud adoption — particularly across regulated industries like healthcare, defence, and government, sectors I’ve spent over 15 years working in.
But here’s what concerns me.
In the rush to stand up LLM pipelines, deploy AI agents, and chase the next generative AI use case, I’m seeing organisations skip past the principles that made cloud transformation successful in the first place. Principles that mattered when I was helping teams migrate their first workloads to AWS a decade ago — and that matter just as much today.
Rapid iteration still wins
One of the greatest gifts cloud computing gave us wasn’t raw compute power. It was the ability to test ideas fast, fail cheaply, and iterate towards something that actually works.
That hasn’t changed. If anything, it’s more important now. The organisations getting real value from AI in the cloud aren’t the ones building monolithic AI platforms over 18-month programmes. They’re the ones spinning up a proof of concept in a week, putting it in front of real users, learning what breaks, and refining. They’re treating AI adoption the same way we should have always treated cloud adoption — as an iterative discipline, not a big bang event.
I’ve lost count of the number of transformation programmes I’ve seen stall because someone wanted the architecture to be perfect before a single user touched it. Perfection is the enemy of progress. Get something working, get feedback, and evolve. The cloud was literally designed for this.
Value-driven development — not technology for technology’s sake
The temptation right now is enormous. Every board presentation has an AI slide. Every vendor has an AI story. And every technology leader is under pressure to show they’re “doing something with AI.”
But doing something with AI is not the same as delivering value with AI.
I’ve always believed that the best technology decisions start with a problem, not a product. What outcome are we trying to achieve? What does the business actually need? Where is the friction, the waste, the missed opportunity? Then, and only then, do we look at the technology that gets us there.
Cloud adoption went through this exact same growing pain. Remember when organisations were lifting and shifting everything to the cloud just to say they were “in the cloud”? The bills went up, the complexity went up, and the value… didn’t. The organisations that got it right were the ones who understood why they were moving to the cloud, not just how.
We’re at the same inflection point with AI. If you can’t articulate the value an AI workload delivers in plain language that a non-technical stakeholder would understand, you’re probably building technology for technology’s sake. And that’s an expensive habit.
This is where a fractional CTO changes the game
Here’s something I’ve observed repeatedly: organisations know they need to move on cloud and AI, but they’re stuck between two worlds. The board wants a strategy they can understand. The engineering team wants technical leadership that actually gets their hands dirty. And too often, there’s a gap in between — filled with slide decks, vendor pitches, and not enough people who can operate credibly in both rooms.
This is exactly the space a fractional CTO occupies.
The power of the fractional model isn’t just cost efficiency — though for SMEs, scale-ups, and organisations that don’t need a full-time CTO, that matters. It’s the ability to sit in a strategy session in the morning, translating AI and cloud into plain English that a non-technical leadership team can make real decisions from — and then sit alongside engineers in the afternoon, diving deep into architecture, reviewing infrastructure as code, and making sure the delivery actually reflects the value we promised.
That bridge between strategic intent and engineering execution is where most cloud and AI initiatives fall apart. The strategy gets signed off, but the delivery drifts. The technology choices outpace the business case. Nobody is holding the thread from boardroom to build.
A fractional CTO holds that thread. Not as an outsider parachuting in with a framework and a set of recommendations, but as embedded technical leadership — iterating with the team, challenging assumptions, and keeping every decision anchored to the value we set out to deliver.
The fundamentals aren’t glamorous. They’re essential.
Cloud-native design. Cost governance. Security by default. Iterative delivery. Outcome-driven architecture. None of these make headlines. None of them trend on LinkedIn. But they’re the difference between organisations that extract real, lasting value from the cloud — and those that spend millions chasing the next shiny thing.
As we enter this second wave of cloud adoption, fuelled by AI and generative workloads, the question isn’t whether your organisation should be investing. It probably should. The question is whether you’re investing with the same discipline, rigour, and focus on value that separates successful transformation from expensive experimentation.
The principles haven’t changed. The stakes have just got higher.
Leave a Reply