Building the Global,
AI-Native Technology Organization

The 2030 delivery system is a continuous loop — not a linear pipeline. Work enters from six signal sources, moves through an AI-orchestrated prioritization engine, executes inside elastic human-agent delivery pods, reaches production, and the monitoring layer feeds directly back into the next cycle. The diagram below shows the complete system. Hover over any node to see how it works.

The complete flow from signal to production in 2030: A signal is detected across any of the six inputs. The AI generates a structured work item with quantified return, full TCO estimate, effort estimate based on historical delivery data, dependency mapping, and ranked intervention options where relevant. The living prioritization formula is applied transparently and the item appears on the work surface with its ranking, reasoning, suggested pod assignment, and starting artifacts. The Product Lead and operational partner review in their standing cadence, confirm assignments, apply overrides where their judgment differs, and activate items into the delivery pipeline. The assigned pod receives the item with AI-generated starting artifacts — requirements draft, test cases, known dependencies. The Pod Lead directs agent instantiation appropriate to the work. Agents execute in parallel where the work allows it. The Test and Quality Engineer validates output against compliance requirements. The AI Validation Engineer monitors agent behavior throughout. Deployment runs through the governed CI/CD pipeline. The AI Validation and Outcomes Engineer monitors production performance against the defined metric targets. Deviations feed back into the six-input signal layer as the next cycle begins.

Every stage of this flow exists in some form today. What changes is the quality, speed, and continuity with which it operates — and the replacement of the manual, opaque, periodic prioritization calculation with a transparent, continuously improving, AI-orchestrated system that makes the organization's actual priorities visible and actionable in real time.

A successful pilot does not produce a project extension. It produces a standing team with continuous accountability for a business outcome — and that shift is one of the most significant operating model changes in the entire 2030 model.

This section describes what that standing team looks like, how work enters and exits it, and how the offshore GCC team participates as a co-owner rather than an execution resource.

Understanding this is important for both technology and business leadership, because it requires a different set of expectations from both sides. Technology leaders need to understand what they are building and why it produces better outcomes than the current model. Business leaders need to understand what they are co-committing to — and what they are trading in return for something more valuable.

How the team forms. When a pilot produces evidence that a capability is worth owning permanently, the pilot team does not disband. The people who ran the pilot — the Product Lead, the GCC Product Owner, the relevant engineering and AI systems capability — become the standing team for that capability area. The pilot was the audition. The persistent team is the role.

This matters for resourcing decisions. Organizations that treat pilots as temporary assignments and rotate people back to a pool after completion will find that the institutional knowledge built during the pilot — the domain understanding, the agent governance context, the business relationship — evaporates at the moment it becomes most valuable. The pilot team should be assembled with the expectation that successful pilots become permanent teams.

What the business trades, and what it gains. The business co-owner in this model gives up something real: the ability to submit requirements and expect them executed on a defined timeline. That is a genuine loss and it should be named honestly rather than glossed over.

What the business gains in return is substantially more valuable. They gain a Product Lead who is accountable for outcomes, not deliverables — which means the conversation shifts from "did you build what I asked for?" to "did the business metric move?". They gain real-time visibility into production performance rather than periodic reporting. They gain a team that is continuously watching their capability area and surfacing problems before they become crises. And they gain a seat in the roadmap process that gives them genuine influence over strategic direction, rather than the illusion of control that a requirements document provides.

The organizations that have made this transition successfully are consistent about one thing: the business co-owners who experienced it report that they have more meaningful control over outcomes than they did when they were submitting requirements. The requirements model gave them control over what was asked for. The co-ownership model gives them control over what is achieved.

The geography and timezone reality. The destination model described in this paper has GCC Product Owners in the offshore GCC carrying full outcome accountability for their capability scope. That accountability is most credible — and most practically effective — when the business co-owner can have a real-time conversation with the person accountable for their outcome.

Timezone distance between the offshore GCC and US business teams is a genuine operational constraint on co-ownership quality. A business co-owner who can only reach their Product Owner at 7am or 8pm Eastern is not in a co-ownership relationship — they are in an asynchronous review relationship. That is a materially different level of engagement, and it affects the quality of the roadmap decisions that come out of it.

The transitional model addresses this directly: the US-based Product Lead is the business-facing layer precisely because of this constraint. The GCC Product Owner operates under the Product Lead's strategic direction and builds domain credibility over time. The destination model — where the GCC Product Owner carries full accountability — assumes two things that are not yet true: that the GCC Product Owner has sufficient domain depth and track record to hold that accountability credibly, and that the business co-owner has evolved their working model enough to operate effectively across that timezone distance.

The 2030 destination is realistic on the first condition and requires deliberate investment on the second. Domain depth and track record can be built through the transitional model. Business co-owner readiness for async co-ownership requires a change management program that most organizations have not yet designed. This is worth naming as a prerequisite for the destination state rather than assuming it follows automatically from the technology and role architecture changes.

The operating model described in the preceding sections — continuous signal identification, AI-orchestrated prioritization, elastic delivery — does not exist in isolation. It is operated by real teams with real accountability relationships, distributed across geographies, organized into specific roles, and embedded in a governance structure that makes the whole system coherent.

This section describes how new business capability enters that system — how an idea that starts in a strategy conversation becomes a funded pilot, and what the technology-business relationship looks like in a model where technology is a co-owner of outcomes rather than a service provider receiving requirements.

This question matters because the AI-first operating model — built around persistent product teams owning defined outcomes — has an inherent gap. Persistent teams own what already exists. They are the right structure for operating and improving known capabilities. They are the wrong structure for exploring whether a new capability is worth building at all. You cannot assign a net-new idea to a team that doesn't exist yet, funded against an outcome that hasn't been validated.

This gap is particularly acute in organizations transitioning from a split product ownership model, where technology has historically been a service provider responding to business-defined requirements. In that model, new products start with a business requirement. In the AI-first model, new products start with a business outcome hypothesis — and the mechanism that converts a hypothesis into a funded investment decision is the Discovery Team.

The mechanism that fills this gap is the Discovery Team.

The concept is not new. Agile practitioners will recognise it as the sprint-level spike elevated to a team-level practice — a time-boxed, cross-functional group assembled to resolve uncertainty before committing to a build. Product-led organizations use the same concept under names including discovery teams, embedded product teams, and multidisciplinary teams. The distinguishing feature in every case is the same: the output is a decision, not a deliverable.

In the AI-first healthcare technology context, the Discovery Team has a specific shape and a specific mandate.

Two structural points deserve emphasis. First, the business is not funding technology exploration — they are funding a structured decision process that produces a business-case-ready proposal. The framing matters because it changes who initiates, who participates, and what success looks like. A Discovery Team that produces a well-reasoned recommendation not to proceed has done its job correctly. That is a different organizational norm from the current one, where a technology team that recommends against building something has failed.

Second, capital commitment is staged against evidence at every gate. The business funds discovery, then makes an independent decision to fund the pilot, then makes an independent decision to fund the persistent team. Each gate requires its own evidence. This is a fundamentally different investment discipline from the current model, where a business strategy decision commits to a multi-year program before a line of code is written.

The four-geography model is not primarily a cost structure. It is a capability architecture — a deliberate answer to the question of where different kinds of work should be performed to maximize the organization's ability to deliver, improve, and sustain its capability portfolio.

Understanding the geographic model requires understanding what each geography is accountable for in the destination state, not just what work happens to be located there today.

Deloitte's Global Outsourcing Survey 2024, which surveyed more than 500 executives globally, identifies the same convergence: "83% of executives are leveraging AI as part of their outsourced services, and 20% are already developing strategies to manage these digital workers," while "insourcing and Global In-house Centers are surging as organizations rebalance their talent ecosystem."¹⁰ Critically, Deloitte also reports that "70% of executives report that their VMO function is not fully mature,"¹⁰ indicating that the governance infrastructure for managing the resulting extended workforce — human and digital — is lagging the strategic decisions being made.

Everest Group's 2026 analysis of the GCC operating boundary makes the strategic implication explicit: GCCs that succeed in the agentic era are the ones that own "enterprise reference architecture, integration patterns, data standards, and platform guardrails," treating the technology stack "as a managed product, so improvements compound rather than reset with each market, provider upgrade, or AI release."¹¹ The strategic value of a GCC in 2030 will be determined less by whether it hits its headcount targets and more by whether it has built genuine product, engineering, and architectural capability that can take ownership of business outcomes.

The result, if the GCC build-out is executed against current plans without revision, is a global capability center that lands at its target year with a workforce shape that the organization no longer needs in that distribution. The cost arbitrage that motivated the GCC investment will be partially eroded by the productivity shift in the underlying roles. The strategic reframe is from a workforce relocation program to a capability build program — heavier weighting toward senior engineering, embedded architecture, AI systems roles, and product ownership capability, and lighter weighting toward the mid-level execution categories that are currently dominant. The GCC is, in most large technology organizations, the largest single workforce design opportunity of the next decade. The question is whether it gets used as one, or executed as a relocation program with the role redefinition bolted on later.

The operating model and geographic structure described in the preceding sections require specific roles to function. Some of those roles exist today in recognizable form and will evolve. Others exist today in forms different enough from their future versions that continuity of title is misleading. Four are genuinely new — they have no meaningful current equivalent and must be hired or developed from scratch.

The headcount story is told at the family level, because that is where it is honest. Total headcount across most families contracts — not because the work matters less, but because AI absorbs the execution volume that justified large populations. The same investment produces significantly more throughput. Within that smaller total, the distribution shifts toward judgment, strategy, and governance work and away from execution and coordination work.

The engineering function contracts in total headcount because AI absorbs the execution volume that justified large development populations. But the contraction is not uniform across levels, and seniority title is not the primary differentiator. What determines who remains valuable is the judgment proportion of their current role — not their position on the career ladder. Engineers who are primarily executing, regardless of their level, face the same exposure. Engineers whose work is primarily judgment, design, and direction of others — human and agent — remain essential and operate at significantly higher leverage than before.

A critical implication follows for talent pipeline design. If the organization starts with fewer junior engineers, it must design deliberately for how senior engineers are grown. The traditional apprenticeship model — hire juniors, develop them through progressively complex work over five to seven years — breaks down when AI is performing the work that used to develop juniors. The solution is structured complexity progression where junior engineers reason through problems before directing AI to implement, rotation through AI systems disciplines that build systems intuition through a different path, and deliberate mentoring relationships with explicit milestones rather than assumed proximity. In the GCC specifically, where mentoring cannot rely on physical co-location, this structure must be designed into the operating model from the start — not added later.

The AI Systems family contains the roles that are most directly created by the shift to an AI-native operating model. They have no clean predecessor in the current workforce and cannot be adequately filled through reskilling of existing populations alone. They require a deliberate hiring strategy, and the organizations that build this capability in 2026 and 2027 will operate the future model more effectively than those that build it in 2029, because the institutional learning from operating these roles in production is not transferable through hiring alone.

The Delivery and Operations family contains the roles that exist today and whose continued existence in a regulated environment is not optional — it is compliance-mandated. The separation of duties requirement in healthcare technology is structural: the same individual cannot write code, validate it, and deploy it to production. That requirement does not change because AI is generating the code. What changes is the nature of the human work within each role. AI absorbs the execution volume. The judgment, strategy, and governance work within each discipline expands in importance and scope.

The leadership layer is the most consequential workforce shift and the least honestly discussed in most AI workforce analyses. The coordination, status reporting, ceremony management, and dependency tracking work that defines a significant proportion of current leadership roles at every level is exactly what AI tooling absorbs first. Gartner predicts that through 2026, twenty percent of organizations will use AI to flatten their organizational structure, with direct implications for middle management populations.⁴ What remains, and what becomes the core of every leadership role, is judgment, accountability, and the ability to operate effectively in conditions of genuine ambiguity.

An important distinction must be made between two responsibilities that are currently bundled into the same leadership role but that scale very differently in the AI-native model. Delivery oversight — ensuring the team produces the right outcomes, that blockers are cleared, that agent and human performance is within bounds — scales with AI tooling. A leader can oversee a significantly larger delivery scope because AI handles the monitoring and synthesis. People development and career stewardship — growing individuals, supporting career transitions, providing honest feedback, advocating for people — does not scale the same way. People in a major workforce transition need more coaching attention, not less. Organizations that expand spans of control uniformly, without separating these two responsibilities, will systematically underinvest in the people development work that determines whether the transition succeeds.

Understanding how current roles map to future roles is important both for workforce planning and for the individuals in those roles who need to understand what their own trajectory looks like in this transition. Three distinctions are important for reading the mapping correctly.

The composite picture across all five role families is not a smaller version of the current workforce. It is a different shape. Roles oriented toward execution compress across all levels — the differentiator is the judgment proportion of the work, not the seniority title. Roles oriented toward governance, strategy, AI systems oversight, and outcome ownership hold or strengthen in relative terms. New role categories emerge that do not exist in meaningful population today.

Whether the absolute total grows, holds, or shrinks depends on what the organization chooses to do with the productivity gains AI enables. Gartner's data is both instructive and cautionary: while headlines through 2025 emphasized AI-driven layoffs, Gartner found that "fewer than 1% were due to actual productivity gains,"⁹ and forecasts that AI will drive role redesign rather than mass elimination, projecting that "more than 30 million jobs each year will be redesigned, not eliminated, by AI-driven innovation."⁴ Organizations that reduce headcount aggressively in advance of measurable productivity gains face "skills gaps, morale issues, and the risk of rehiring at higher cost."⁹ Reinvested deliberately into expanded throughput and new capability, the same workforce investment produces significantly more. These are choices — and they need to be made deliberately rather than by default.

The operating model described in this playbook does not activate itself. Before the 2030 delivery system can function — before elastic delivery pods can operate with confidence, before GCC teams can hold genuine accountability for business outcomes, before the work surface can be trusted as the primary prioritization mechanism — certain governance and leadership foundations must be in place.

Most capability migration challenges that appear to be workforce or technology problems are actually governance problems. This section addresses what has to be true first.

Business partner resistance is the first constraint layer, and the one most often managed rather than resolved. US-based business leaders who have built working relationships with US-based technology teams over years are being asked to accept accountability for outcomes delivered by a team twelve time zones away that they have never met, in a context where the institutional knowledge of how their business actually works has not been systematically transferred. Their resistance is frequently characterized internally as political or parochial. It is usually neither. It is a rational response to a real accountability gap.

The business partner who resists a capability migration is asking a legitimate question: if something goes wrong, who is accountable, how do I reach them, and do they understand my business well enough to fix it? If the honest answer to any of those questions is unclear, the resistance is not the problem. The governance design is the problem. Organizations that treat business partner resistance as a change management issue to be communicated through are making a category error. The right response is to demonstrate, not persuade: sequence migrations to build a track record on progressively higher-stakes capabilities, establish governance mechanisms that give business partners real visibility and escalation paths, and build GCC-based leadership credibility through delivery performance rather than through reassurance. Trust is earned through results. It cannot be managed through communications.

Client contract restrictions are the second constraint layer, and the one most often discovered after a decision has been made. In healthcare technology, the contract landscape creates real limitations on where certain work can be performed. Protected health information handling under HIPAA has nuanced implications for offshore processing. Commercial client contracts with large employers frequently include data residency requirements or explicit restrictions on where member data can be processed. Government program contracts, including those governing Medicare and Medicaid administration, often include domestic processing requirements. A full legal and compliance review of every material client contract needs to happen before any capability is declared fully transferable to a GCC. That review will almost certainly identify a subset of capabilities or data processing functions that cannot move in their current form, or that require contract amendments with their own timeline and cost implications.

Regulatory restrictions are the third constraint layer. For payer and PBM technology organizations, CMS oversight of Medicare Advantage and Part D creates specific constraints on where certain processing and decision-making functions can be located. State insurance regulations add a further layer — requirements are not uniform across the states in which a national payer or PBM operates. The prior authorization regulatory environment adds particular complexity for any capability touching PA processing — CMS PA rules phased in from 2026 through 2027 create documentation, interoperability, and turnaround time requirements that have specific compliance implications for how PA-adjacent work is governed in a distributed delivery model.

The transition from the current model to the destination model does not happen to a workforce — it happens with one. The people in today's organization are the people who will either build the 2030 model or exit before it is complete, and how the organization manages that reality determines whether it arrives at the destination with the institutional knowledge and talent it needs or with a capability gap that takes years to close.

The reskilling track is for the population that can credibly move into the new role distribution: engineers whose work is already judgment-heavy and who can develop into AI-augmented generalists, strong product analysts who can develop into product leads, systems analysts who are the strongest candidates for AI Workflow Designer roles, testers with deep domain knowledge who can move into Test and Quality Engineering strategy roles or toward the AI Validation and Outcomes Engineer discipline. McKinsey's case study of a global healthcare company that reorganized into a product-based operating model found that when the company mapped skill proficiency across its technology workforce, "half of people were proficient in their core skills" — enabling targeted development and elimination of overlapping roles rather than wholesale workforce replacement.¹ This population is real, but it is meaningfully smaller than most organizations assume. Identifying it accurately, rather than optimistically, is the foundation of the rest of the strategy.

Reskilling must be role-specific and workflow-integrated to be effective. The dominant pattern in the market right now — purchasing enterprise AI literacy licenses and measuring completion rates — produces completion rates, not capability. Training that is not applied immediately in a changed workflow is not retained. The reskilling investment needs to be sequenced with the workflow changes that create a context for application, not delivered in advance of them. It also needs to be differentiated by role: an architect's AI reskilling looks nothing like a product manager's, and neither looks like a DevOps engineer's. Generic AI fundamentals curricula are a starting point at best and a distraction at worst.

The redeployment track is for the population that cannot credibly make the technical role transition but has durable value in adjacent functions: operations, support, business analysis, training, compliance, vendor management, change management. Building deliberate adjacency paths for this population is one of the highest-leverage workforce decisions available, and it is consistently the one that gets deferred. The cost of deferral is high — this population tends to be most affected by uncoordinated late exits, which simultaneously damage institutional knowledge, morale, and the organization's external reputation.

The managed exit track needs to be honest with the affected population early enough to give them real options. Some proportion of the current workforce will not make the transition regardless of how good the training is — not because they lack intelligence or commitment, but because the judgment work that defines the future role requires a combination of domain depth, systems thinking, and comfort with ambiguity that not everyone has or can develop quickly enough to keep pace with the transition timeline. Pretending that the right training program solves this for everyone sets people up for a worse experience than being told the truth early enough to make real choices. The cost of being late on this track is high in human, legal, reputational, and institutional knowledge terms.

Running all three tracks simultaneously requires a change management function with genuine enterprise mandate — not a communications team and not a project management function. Change management in this context is an operational discipline: it owns the transition experience for each population, builds the psychological safety that allows people to engage honestly with the transition rather than performing compliance with it, maintains the feedback loops between leadership and the affected populations, and measures adoption in terms of behavioral change rather than training completion. Gartner's research frames the ambition clearly: "organizations that win won't chase headlines or cut staff. They'll orchestrate a 'talent remix,' blending people, autonomous agents, contractors and digital avatars into resilient teams ready for constant change."¹² The workforce that arrives at that destination is not the one managed reactively — it is the one shaped deliberately through all three tracks running in parallel. Gartner also issues a clear warning on the cost of inaction: "by 2030, half of enterprises will face irreversible skill shortages in critical job roles due to GenAI accuracy decline, skills erosion, and uncompetitive pay."¹³ The organizations that avoid that outcome are the ones that start the deliberate workforce shaping now.

The destination described in this playbook does not materialize from a single program decision or a technology investment. It is built across three distinct horizons, each of which creates the conditions for the next. The sequencing is not bureaucratic caution — it is the practical reality that certain foundations must exist before later-horizon capabilities can function.

The roadmap below reflects the context of a payer or PBM technology organization expanding its global delivery footprint while scaling an AI investment agenda, often alongside core platform modernization. The three horizons are not calendar commitments — they are sequenced capability builds, where each horizon's output is the prerequisite for the next.