Is AI coming for your tech job? Maybe, but the actual data tells a more complicated story. In 2024, AI created approximately 119,900 direct jobs while only 12,700 were confirmed lost to automation, a 10-to-1 ratio that rarely makes headlines. Gartner tracked 1.4 million layoffs in 2025 and found less than 1% were directly caused by AI productivity gains. Most analysts point instead to post-pandemic right-sizing and high interest rates. AI is, at least for now, a convenient excuse more than a root cause.
The real structural shift started much earlier, and it came from the cloud.
For most large in-house tech teams, "the cloud" means hyperscaler services: AWS, Azure, Google Cloud. Over 94% of enterprises now use cloud services, and as organisations went all-in, many of those in-house roles didn't disappear so much as transfer from your payroll to theirs. Cloud migration typically reduces IT infrastructure costs by 25–30%, largely by eliminating the need for in-house staff to manage hardware, cooling, and physical security. Efficient, yes. But the consequence is that an estimated 70% of traditional IT staff now lack the deep expertise to manage their own infrastructure, because those skills have been ceded to third parties.
That created real efficiencies, no argument. But hyperscalers exist to grow their own revenue, not to protect your long-term capability. The end result: they are quietly removing your ability to choose a future without them.
It's worse inside the hyperscalers themselves. AI is now being used to replace the lower-level configuration and maintenance roles that once built foundational cloud knowledge. Broad, non-specialised knowledge workers, the people who understood how things connect, are being cut in the name of efficiency. This works well at hyperscaler scale, where the job is to replicate the same products and services across thousands of clients. It does not work well for client organisations that need long-term stability. Business strategy cycles are now shorter than three years, and the roles being eliminated today will be needed again at the next horizon.
The irony is that the hyperscalers built this dependency deliberately. The cloud transformation wave, native builds, hybrid migrations, the push that took combined hyperscaler revenues to over USD$220 billion annually, required armies of specialist cloud engineers, architects, and sales staff. Huge financial incentives were structured to offset upfront project costs with ongoing operational spend, often locked in over multi-year terms. "Pay as you go" became "pay as we say." That lock-in is now structural, and AI is simply the latest mechanism to deepen it.
The Tech jobs that stopped being backfilled
It's no shock that the affected roles are largely related to technology and project delivery. But the shift is doing two things simultaneously: creating large capability voids inside client organisations, and quietly eroding the career value of the tech professionals who made the move to vendor-side roles thinking it was a step forward.
The jobs most significantly redefined are those now tied to specialisation in specific cloud products and services, with hyperscaler tools increasingly embedded into day-to-day tasks:
Business analyst — Functional and non-functional requirements have become less human-centred as business stakeholders become more cloud savvy, narrowing the analyst's independent scope.
Business architecture — Capability models, information mapping and organisational design are increasingly shaped by prescriptive cloud processes rather than business need.
Change and communications manager — User experience mapping and journey design are now constrained by what hyperscaler products allow, not what users actually need.
Enterprise architecture — Increasingly reduced to incorporating cloud products into a technology map, rather than governing the full business, application, data and technology landscape.
Financial analyst — Cloud cost modelling now requires hyperscaler certifications or dedicated FinOps roles. The old model of product times quantity no longer cuts it.
Product owner — The shared responsibility model embeds hyperscaler logic directly into agile squads, with certifications becoming the escalation currency.
Solution architecture — In practice, often a cloud engineer with deep product knowledge but limited architectural methodology experience. The title has drifted from the discipline.
Technology lead — Coordinates cloud professionals in design and deployment, with certifications increasingly standing in for genuine governance capability.
Test analyst — Test cases are now built around cloud product behaviour, requiring fluency in multiple testing tools across both cloud and generic environments.
For organisations, this represents a quiet but serious concentration of risk. As architecture capability migrates to the hyperscaler ecosystem, so does independent judgement. Decisions about what to build, how to build it, and whether to build it at all are increasingly made through a hyperscaler lens — by people whose certifications were issued by the vendor with a commercial interest in the answer.
For tech professionals, the picture is equally uncomfortable. Many made the move from in-house roles to vendor or cloud-specialist positions expecting career progression. What they often found instead was a narrower role, tied to one ecosystem, with market value that depreciates every time that hyperscaler updates its product set or restructures its certification pathway.
The most significant casualty is enterprise architecture. The certification pathway for cloud architecture now requires engineering proficiency as a prerequisite — a fundamental departure from formal architecture methodology, where broad functional knowledge and communication skills matter more than deep product specialisation. The result is that enterprise architecture is being routinely misrepresented: a cloud architect with multi-cloud certifications is not an enterprise architect.
Enterprise architecture is the definition, mapping and governance of business, application, data and technology architectures — ensuring organisational change is managed within the strategic vision of the business, with deviations controlled and roadmaps evolved across the strategy lifecycle.
Hyperscaler architecture is something different. It is the assembly of known products using known patterns to make a system work within one vendor's ecosystem. That is a valuable and complex skill. But it is not the same discipline, and treating it as equivalent leaves organisations without an independent view of their own capability, their own data, or their own future direction.
As an industry, we stood by and let them do it. Here's how.
The hyperscalers' need for cloud talent drove the development of entirely new professional development models, ones built as much around brand advocacy and stickiness as genuine skills transfer. Think of it as the McDonald's marketing principle applied to career pathways: get them early, make the next step feel achievable, and ensure every milestone deepens their dependency on your ecosystem.
The certification pathways were cleverly constructed. Starting at entry level, a professional could attain a cloud architect certification after only a handful of steps: engineer to practitioner, practitioner to associate, associate to professional. Fast, structured, gamified. Each step reinforced deep engineering experience within one vendor's product set before teaching professionals how to assemble those products into client systems.
It worked extraordinarily well for the hyperscalers. For the broader industry, it created a generation of professionals whose career progression was measured in vendor certifications rather than architectural capability. Pay scales shifted within timeframes far shorter than traditionally expected, and many professionals moved into architect roles while remaining engineers in knowledge and instinct. That's not a criticism of individuals — the incentive structures made it rational. But the outcome is that true architectural capability, the kind that operates independently of any vendor's product catalogue, became increasingly rare and increasingly undervalued.
Here is why that matters, and why it should concern every organisation that depends on technology to compete.
Your business and technical architecture is a competitive edge. If every organisation is using the same hyperscaler platforms, configured by professionals trained and certified by those same hyperscalers, assembled using pre-defined patterns from the same playbook, the differentiation disappears. You are not building capability. You are consuming a commodity, at a premium, and calling it strategy.
Beyond competitive differentiation, there is a more fundamental problem: who is providing the critical, independent assessment of your tools and your suppliers? Genuine architecture capability is not just about designing systems. It is about asking whether a system should be built at all, whether the vendor is the right one, whether the contract protects the organisation's long-term interests, and whether the roadmap serves the business or the hyperscaler's revenue targets. When the people responsible for answering those questions are certified by, employed by, or commercially dependent on the vendor being assessed, the answer is predictable.
Who watches the watchmen?
Organisations allowed this to happen gradually, either through deliberate outsourcing decisions or organically through technology transformation and effective sales strategies. In both cases, the result was the same: the loss of architects who focus on the critical early steps, mapping needs to capabilities, defining functions, and making vendor-agnostic decisions before any product is selected.
The void this creates is not just an IT problem. It is a governance problem. Without independent architecture capability, organisations lose their end-to-end view of business functions, the design context connecting strategy to technology, and crucially, the ability to hold their suppliers to account. The enterprise architecture is not just missing. In most organisations, nobody has noticed it's gone.
Architecture is your IP. Don't give away the crown jewels
What IS architecture anyway?
Architecture is the culmination of art and science in the design, planning, development and testing of structures. The ratio of art to science varies depending on what is being built. Bridges are significant mechanical structures requiring scientific load modelling across payload, mass, tensile stress, wind, harmonics and geology. Gardens are human-centred, artistic structures designed for relaxation, contemplation and exploration. Both are architecture. Both require a disciplined process.
The first recorded architect was Imhotep, in ancient Egypt, roughly 4,650 years ago during the construction of the Pyramid of Djoser. Humans had been building shelters, rafts and animal traps for thousands of years before that. It is impossible to imagine they were not applying architectural thinking to do it.
The process has not changed much since.
The first step is definition: what needs to be built, and under what conditions. Scope, goals, budget and constraints are established before anything else. A 500-storey mixed-use building, carbon neutral, built to withstand a category 4 cyclone on a site 30 metres above bedrock, with a AUD$2 billion budget, is a very different problem to solve than a garden. But both start here.
The second step is conceptual design: exploring options for size, shape, characteristics and function. Drawings, floor plans, site plans and elevations are produced. Models are built. Engineers and clients review and refine until one option is selected.
The third step is detailed design: the concept becomes a reality. Engineering specialists are engaged, materials and products are selected, blueprints are developed, bills of materials are defined, cost models are refined and construction partners are formally engaged. Nothing is built yet. But everything that will be built is accounted for.
The fourth step is oversight: handover to the construction team, with the architect maintaining frequent and diligent oversight throughout to ensure compliance with design specifications.
Now apply that to your organisation's technology. Which of those four steps is currently being performed by someone who is vendor-neutral, accountable to your business strategy, and capable of telling a hyperscaler their recommendation is wrong? If you cannot answer that question confidently, you have already given away the crown jewels.
Independent architecture isn't optional. It never was.
Your architecture is not a service you consume. It is the intellectual property of your organisation, the accumulated knowledge of how your business works, how your systems connect, and how your strategy translates into technology decisions. The moment you outsource that capability entirely, you lose the ability to think independently about your own future.
Your organisation's competitive edge is not the platform you run on. Every one of your competitors has access to the same hyperscaler services, the same certification pathways, and the same pre-defined patterns. If your architecture is being designed by people whose frame of reference is a single vendor ecosystem, you are not differentiating. You are the same as everyone else.
And then there is the harder question: who is critically assessing your tools and your suppliers? If your supplier provides the technical depth, there is an inbuilt conflict of interest. Their employer succeeds by maximising revenue, not efficiency for you. They are paid by the vendor, trained by the vendor, and their career progression runs through the vendor. Expecting them to objectively challenge the vendor's recommendations is not realistic, and it is not fair to ask them to.
Independent architectural capability is what gives you that critical voice. It is what allows your organisation to evaluate suppliers on your terms, challenge roadmaps that serve the hyperscaler more than the business, and make technology decisions that compound into genuine competitive advantage over time.
Who watches the watchmen? In most organisations right now, nobody. That is the gap worth closing.
John Welsh
APRIL, 2026
