The Missing Role in AI Transformation

This essay is AI-augmented, as most of my current writing is. Without the machine, the alternative would not be slower output. It would be no output. ChatGPT and Codex executed much of the writing and I steered the argument, structure, and thesis. That is also the point: the machine accelerates execution, but the human remains responsible for intent, judgment, and coherence. The thesis comes from my earlier work on 10x: The Coordination Shift: when AI makes production cheaper, the bottleneck moves to coordination, verification, learning, and decision-making. I have seen this directly in technical delivery and self-organizing product teams, and I have spent much of my career inside the older alternative: siloed, handoff-heavy organizations where ownership is fragmented and feedback arrives too late.

This essay extends that experience upward. My strongest ground is technical transformation: making complex systems explicit, verifiable, teachable, and operational. The enterprise PMO, program, portfolio, and senior-management layer is a larger coordination surface than the one I have directly owned. So read this as a working theory of the scaled coordination shift: grounded in technical delivery, informed by organizational research, and aimed at the next layer of competence I intend to build.

The proposed role (AI Transformation & Operating Model Lead) is an attempt to name a missing organizational function: someone who holds the thread between AI experimentation, workflow redesign, platform capability, risk, evidence, leadership, and portfolio decisions. //Mike

A strange thing happens when a large organization starts using AI seriously.

At first, the activity looks encouraging. A few people save time. Someone summarizes long documents in minutes. Someone else drafts customer communication faster than before. A developer uses an agent to scaffold tests, refactor a service, or produce documentation that previously stayed unwritten. A product manager generates alternative launch plans. A finance team experiments with variance explanations. A legal or compliance function tries controlled document analysis. The internal communication team finds a success story and turns it into a slide.

For a while, the story is simple: people have found a powerful new tool.

Then the organization begins to feel the real problem.

The problem appears between teams. It appears when a local experiment needs access to data owned elsewhere. It appears when a business unit sees value but security sees exposure. It appears when a product team can move faster than the governance process around it. It appears when a project produces impressive outputs but weak evidence. It appears when leadership asks for value realization and receives anecdotes. It appears when the PMO sees more initiatives, more dependency lines, more "AI use cases," and less clarity about what is actually changing.

The tool was the visible change. The coordination surface was the real one.

The first wave: adoption

Most organizations begin with adoption.

They buy licenses. They run training. They appoint champions. They create prompt libraries. They collect use cases. They run inspirational sessions. They ask employees to experiment. They publish guidelines. They create a few safe examples and a few cautionary examples. They try to move the organization from fear to curiosity.

That opening work creates permission. Leaders need enough understanding to own the question. Employees need basic familiarity. Digital shame needs to be reduced. The organization needs a culture where people can ask simple questions without losing face.

The research base supports this human layer. Amy Edmondson’s work on psychological safety and learning behavior in teams frames learning as an interpersonal condition. Teams learn when people can take interpersonal risks: ask questions, admit uncertainty, report errors, challenge assumptions, and expose weak evidence.

AI transformation intensifies that requirement. People need to say: "I do not understand this," "this output is wrong," "this workflow is unsafe," "this metric is fake," and "this governance step blocks learning." An organization that punishes those sentences turns AI into theater.

The adoption wave also needs a precise model of trust. Lee and See’s classic paper on trust in automation argues that automation fails when people rely on it in the wrong way: too much, too little, or with poor calibration. Dietvorst, Simmons, and Massey showed that people often develop algorithm aversion after seeing an algorithm err, even when the algorithm still performs well relative to humans. Together, these findings explain why AI adoption needs more than access and enthusiasm. The organization has to teach calibrated reliance: when to use, when to verify, when to override, and when to refuse.

Adoption is the opening move.

The second wave is operating-model change.

The second wave: the coordination shift

The coordination shift begins when execution becomes cheap enough that the bottleneck moves elsewhere.

AI reduces the marginal cost of producing drafts, analyses, code, plans, summaries, classifications, prototypes, options, documentation, test cases, and decision-support material. More things can be produced by more people in less time.

Microsoft’s 2026 Work Trend Index states the shift directly: as AI and agents take on execution, human agency expands. The report’s central question is whether organizations are built to capture that agency. It also reports that organizational factors such as culture, manager support, and talent practices account for twice the reported AI impact of individual effort alone. That is the coordination shift in organizational language.

The individual gains are real. The organizational capture mechanism is the hard part.

A team can generate ten options. Who decides which option deserves attention?
A department can automate part of a workflow. Who owns the downstream effect?
A project can move faster. Which proof obligations must hold before the result becomes operational?
A business area can save time. What higher-value work absorbs the released capacity?
A local team can discover a useful AI pattern. How does the rest of the organization learn from it?
A platform team can provide tools. Which workflows, risks, and constraints should shape the platform backlog?
A portfolio board can approve AI initiatives. Which evidence should cause scale, pivot, merger, or termination?

The scarce resources become shared intent, decision quality, verification capacity, integration discipline, risk clarity, and learning speed.

McKinsey’s 2025 State of AI survey shows the same pattern from another angle. It reports regular AI use in 88 percent of organizations, while only 39 percent report EBIT impact at enterprise level. McKinsey also reports that high-performing AI organizations are far more likely to redesign workflows, show senior leadership ownership, embed AI into business processes, track KPIs, and define when model outputs need human validation. Broad use is common. Enterprise impact comes from operating-model change.

The organization needs a role that can work across those boundaries.

A name for the role

One possible name is AI Transformation & Operating Model Lead.

The title is less important than the function. The function is to help the organization turn AI from scattered experimentation into governed, evidence-producing, AI-augmented work.

This role belongs near the PMO, P3O, or portfolio coordination surface because that is where projects, programs, investments, dependencies, benefits, risks, and executive visibility already meet. It also needs direct access to divisions, product teams, platform teams, architecture, security, legal, compliance, data, HR, and executive leadership.

The role is a translator, designer, and operating-system steward.

It translates between leadership intent and team-level execution.
It translates between business value and technical constraints.
It translates between AI enthusiasm and risk reality.
It translates between project reporting and actual evidence.
It translates between local experiments and reusable organizational capability.
It translates between human change and workflow architecture.

The role exists because AI transformation crosses the boundaries where organizations already struggle.

The hybrid organization

Most organizations today are hybrid systems.

They have divisions or departments that own business outcomes, budgets, operations, customers, costs, and regulatory obligations.

They have product teams that sit closer to systems, users, journeys, and day-to-day delivery.
They have platform teams that provide shared technical capability: cloud, identity, data access, CI/CD, observability, AI tooling, integration, security controls, and developer experience.
They have projects that deliver bounded changes.
They have programs that coordinate several related changes.
They have portfolios that decide where money, attention, people, and executive support go.
They have a PMO or P3O surface that tracks status, risk, dependencies, benefits, governance, and reporting.
They also have matrix structures. A person can belong to one function, work in a product team, report through another line, deliver into a program, depend on a platform team, and serve a divisional priority at the same time.

This structure creates flexibility. It also creates friction. AI increases both.

When work moves slowly, unclear coordination can remain hidden. When execution accelerates, ambiguity becomes expensive. The organization can generate more output than it can judge, verify, integrate, or align.

The AI Transformation & Operating Model Lead works inside this hybrid reality. The role helps each layer understand its part in the new production system.

From use cases to workflow experiments

The first practical move is to change the unit of transformation.

Many organizations collect AI use cases. That creates a catalogue of possibilities. It also creates a trap. A use case described outside a workflow usually lacks ownership, risk context, evidence, and a path to scale.

The stronger unit is the workflow experiment.

A workflow experiment starts with real work. Customer onboarding. Claims handling. Incident response. Procurement comparison. Proposal writing. Month-end closing. Software delivery. Compliance reporting. Product discovery. Portfolio reporting. Operational planning.

The experiment asks five questions.

Situation: What happens today? Who does the work? Which systems are involved? Where does waiting occur? Where does rework occur? Where does quality fail? Which decisions are made? Which evidence is trusted?

Decision: What changes? What may AI do? What must a human judge? Which team owns the result? Which decision can move locally? Which decision needs escalation?

Risk: What can fail in this specific workflow? Confidential data exposure, false information, biased recommendations, weak auditability, poor source quality, overreliance, unclear accountability, loss of domain learning, customer harm, operational rework.

Change: What is the smallest useful change we can test in real work? Which signal tells us whether the change improves reality?

Pushback: What resistance should we expect? Unclear permission, overload, fear, status threat, weak tool trust, valid risk, cross-department friction, previous transformation fatigue.

This method turns change leadership into operating discipline. Fear becomes input. Risk becomes design material. Pushback becomes evidence. The workflow becomes the unit of learning.

It also aligns with the risk-governance direction in NIST’s AI Risk Management Framework, which frames AI risk management through govern, map, measure, and manage functions. The practical point is simple: AI risk is contextual. The same model behavior can be useful in one workflow and unacceptable in another. Risk has to be mapped to actual use, actual impact, actual accountability, and actual controls.

Project, program, portfolio

At the project level, the role helps teams run bounded experiments. The project defines intent, constraints, success signals, proof obligations, decision rights, and learning points. The team may use AI aggressively for execution, but the result must pass through evidence before it becomes trusted work.

At the program level, the role looks across several experiments. Which risks repeat? Which guardrails repeat? Which platform needs repeat? Which workflow patterns deserve reuse? Which teams need the same support? Which failures teach something that should change the system?

At the portfolio level, the role helps leadership allocate attention based on evidence. Which initiatives deserve scale? Which should merge? Which should stop? Which platform investments unlock several teams at once? Which governance steps slow learning? Which business assumptions changed because AI changed the cost of execution?

This is where the PMO changes character.

The old PMO often reports progress.

The coordination-shift PMO steers learning.

It gives leadership a live view of intent, evidence, risks, dependencies, decisions, and value. It helps the organization stop weak work, scale strong patterns, and move investment toward real signals.

The jagged frontier

The case for this role becomes stronger when we look at the empirical performance pattern of generative AI.

In the Harvard/BCG field experiment Navigating the Jagged Technological Frontier, consultants using GPT-4 completed more tasks, worked faster, and produced higher-quality results on tasks inside the AI capability frontier. On a task outside that frontier, they were 19 percent less likely to produce correct solutions than the control group.

That result is crucial. AI creates a jagged frontier: strong in some tasks, weak or misleading in others, sometimes within the same workflow.

This makes generic adoption dangerous. The organization needs domain-specific frontier maps. Where does AI help? Where does it mislead? Which outputs require human validation? Which tasks require expert review? Which risks can be bounded with guardrails? Which tasks should remain outside AI-assisted workflows for now?

That work belongs at the coordination surface between workflow ownership, domain expertise, platform capability, risk governance, and portfolio decision-making.

The platform as acceleration layer

The platform team plays a central role, and its work should be pulled from repeated organizational need.

If several workflow experiments need secure document retrieval, the platform builds the approved pattern.

If several teams need prompt and context versioning, the platform builds it.

If several teams need evaluation harnesses, audit trails, model access controls, human-review workflows, or integration components, the platform turns repetition into shared capability.

The platform team makes safe speed possible.

This is how local learning becomes organizational leverage. Without the platform layer, every team invents its own path. With a strong platform layer, the best patterns become easier to reuse than local improvisation.

The human layer

The role also needs a serious human-change posture.

AI transformation creates emotional pressure. People feel curiosity, shame, excitement, threat, relief, cynicism, and overload. Leaders may feel digital shame. Specialists may feel status threat. Employees may wonder whether their work is disappearing. Risk functions may fear uncontrolled adoption. Delivery teams may fear yet another initiative layered on top of existing work.

These reactions are part of the system.

Psychological safety gives the organization access to truth. People must be able to say: I do not understand this. This output is wrong. This metric is fake. This workflow is unsafe. This customer value is unproven. This governance step blocks learning. This AI use saves time but damages accountability.

That honesty requires leadership.

If leaders reward polished demos, the organization will produce demos. If leaders reward evidence, the organization will produce evidence. If leaders punish uncertainty, the organization will perform certainty. If leaders ask better questions, the organization will learn faster.

The AI Transformation & Operating Model Lead therefore works with leaders as much as with teams. The role helps leadership move from AI as technology sponsorship to AI as operating-model ownership.

Skill formation and the apprentice problem

AI transformation also changes how people learn.

The short-term productivity story is real. In a controlled experiment on GitHub Copilot, developers with Copilot completed a coding task 55.8 percent faster. Similar productivity results appear across several professional domains.

The long-term competence story is more complicated. Shen and Tamkin’s 2026 study How AI Impacts Skill Formation found that AI assistance impaired conceptual understanding, code reading, and debugging ability when participants used AI while learning an unfamiliar programming library. Some interaction patterns preserved learning, especially those involving conceptual inquiry and active comprehension. Full delegation produced speed at the cost of understanding.

This is a serious organizational design problem. Many junior employees historically built judgment by doing routine work: research, first drafts, debugging, reconciliation, documentation, analysis, and operational follow-up. AI can now absorb much of that work. The organization gains speed and risks weakening the training ground for future judgment.

That means AI transformation must include deliberate skill design. Which work should be automated? Which work should remain a learning path? Which AI patterns preserve understanding? Which roles need apprenticeship through review, explanation, simulation, and supervised judgment rather than mere output production?

The AI Transformation & Operating Model Lead should treat skill formation as part of the operating model.

If the role lands on a technical person

A developer, DevOps engineer, platform engineer, architect, or other highly technical person may understand the production system better than anyone else in the room. That is a strong starting point.

They already understand integration, failure modes, automation, observability, testing, deployment, security boundaries, operational drift, and the difference between a demo and a production system. They understand that speed without verification becomes fragility. They understand that a tool only becomes useful when it fits the workflow around it.

The learning gap is usually the human and organizational system.

A technical person stepping into this role needs to learn how decisions move through the company. Who owns budget? Who owns risk? Who owns the customer outcome? Who can approve a workflow change? Who controls data access? Who can stop an initiative? Who has informal veto power? Who feels threatened? Who carries the operational consequence when something fails?

The technical instinct is often to fix the platform first. Build the tooling. Define the architecture. Create the golden path. Automate the guardrails. Those moves are valuable, but they become powerful only when attached to business intent and behavior change.

The technical person must therefore learn to ask different questions.

What outcome does this workflow support?
Which decision becomes better if AI is introduced here?
What evidence would convince the business owner?
What fear or resistance will appear in the affected team?
Which manual work currently creates skill and judgment?
Which policy boundary needs clarification?
Which executive trade-off blocks progress?
Which metric would create false confidence?
Which platform capability would help several teams at once?

The technical person also needs to translate technical reality into management language without diluting it. "We need evals, audit trails, context control, and source grounding" becomes "we need a reliable way to prove that AI-supported work is accurate, traceable, and safe enough for this workflow." "We need CI/CD guardrails" becomes "we need governance that runs continuously inside the production path rather than waiting for a meeting."

The technical person should resist the hero role. The task is to build a system where many teams can act safely, not to become the central expert through which every AI decision passes.

The strongest technical candidate becomes effective when they combine three postures: architect the guardrails, study the organization, and let evidence steer the change.

If the role lands on a PM, change manager, or former agile coach

A project manager, change manager, transformation lead, or former agile coach may understand the human and coordination system better than anyone else in the room. That is also a strong starting point.

They may understand stakeholder mapping, facilitation, resistance, leadership alignment, portfolio reporting, benefits realization, communication, adoption, governance, and the social mechanics of change. They may see the political and emotional system clearly. They may know how to create movement across departments.

The learning gap is usually the technical production system.

A non-technical person stepping into this role needs enough technical literacy to keep the trust of builders and platform teams. They need to understand the basic shape of AI systems, data flows, model behavior, integration paths, security boundaries, observability, evaluation, retrieval, prompt/context management, and software delivery. They need to understand why engineers care about versioning, testing, reproducibility, source quality, latency, cost, permissions, rollback, and auditability.

They do not need to become a machine-learning engineer. They do need to ask technically serious questions.

Where does the data come from?
Who owns the source system?
What is the model allowed to see?
How is context assembled?
How do we know the output is grounded?
What happens when the model is wrong?
Who reviews the result?
What is logged?
Can the decision be reconstructed later?
How does this integrate with the existing workflow?
How does this fail in production?
Which guardrail runs automatically?
Which guardrail depends on human judgment?

The non-technical person must avoid turning AI transformation into workshops, ceremonies, maturity models, and storytelling alone. Those instruments can help, but they become hollow when detached from production reality.

The safest pattern is pairing. Work closely with a platform architect, staff engineer, security architect, data lead, or technically respected product engineer. Let the technical counterpart protect implementation reality. Let the change-oriented lead protect adoption, governance, decision flow, and human behavior. Together they can hold the full system.

The non-technical person also needs to learn when technical pushback is valid. Engineers may sound negative when they are actually describing physics: data quality, integration cost, security exposure, untestable outputs, unreliable retrieval, weak observability, or brittle automation. Treat that pushback as design input.

The strongest PM/change/agile candidate becomes effective when they combine three postures: respect the technical system, protect the human system, and force every AI initiative back to workflow evidence.

Time saved is raw material

Generative AI often enters organizations through time savings. A process takes nine weeks and now takes three. A report takes two days and now takes one hour. A draft takes half a day and now takes ten minutes.

This is useful. It is also incomplete.

Time saved becomes value when the organization knows what the released time is for.

More customer contact. Faster decision cycles. Better quality. More experiments. Stronger compliance evidence. Shorter incident recovery. Better onboarding. More strategic work. Lower cost. Higher throughput. Better learning.

Without that conversion, time savings become a vague benefit claim. The organization feels faster without knowing whether it became better.

The coordination-shift question is sharper: what higher-value work absorbs the released capacity?

The end-state

The target state is an organization that can move faster and stay coherent.

Leadership owns AI as a business and operating-model question.
Divisions define valuable workflow outcomes.
Product teams run small experiments close to reality.
Projects produce evidence as well as deliverables.
Programs turn repeated experiments into reusable capabilities.
The platform team converts repeated needs into safe shared services.
Risk, security, legal, and compliance provide usable boundaries.
The PMO gives leadership a live view of evidence, dependencies, risks, and decisions.
Portfolio governance reallocates funding and attention based on learning.
People gain confidence because the new system gives them permission, support, guardrails, and a meaningful role.

This is the missing role in many AI transformations. Someone must hold the thread between strategy and workflow, between experimentation and governance, between platform and behavior, between risk and speed, between output and evidence.

AI makes production cheaper. That is the easy part.

The hard part is building an organization that can decide, verify, coordinate, and learn at the new speed.

Operator