Chapter 13: New Roles That Emerge

This is not the same as renaming. An engineering manager whose team now governs AI agents alongside human engineers is not a new role — they are an existing role operating in changed context. Chapter 14 addresses that. What this chapter addresses is different: the responsibilities that fall between existing roles, exist at a level of abstraction that existing roles do not cover, and will remain unowned unless the organization deliberately creates the structures to hold them.

Three roles emerge consistently across hybrid organizations as scale increases. They are not optional innovations or governance add-ons. They are structural consequences of the same underlying shift: when execution is no longer exclusively human, the organization needs people whose job is to design, govern, and improve the execution model itself. In every hybrid organization operating without them, the gap they leave is visible in governance failures, inconsistent standards, and an execution surface that no one can describe in aggregate.

Figure 1: The three roles and their relationships

The execution architect designs the aggregate model. The ACG sets standards and maintains the governance library. Automation owners govern individual executors within product teams. All three connect to the execution surface below.

THE THREE ROLES IN BRIEF

Automation owner — a distributed accountability role, not a separate function. Every significant non-human executor on the execution surface has a named individual whose job description is the ownership framework from Chapter 12. One person can own multiple executors. The role sits within existing product and engineering teams.

Automation capability group — the custodian of the governance library and the owner of the review process. A small function, often starting as one person, responsible for the standards, classification framework, templates, and organizational knowledge that determine whether automation and AI are being deployed, monitored, and governed with appropriate rigor across the entire organization.

Execution architect — a strategic design role responsible for the execution surface in aggregate. Where automation owners govern individual executors and the ACG governs standards, the execution architect governs the model — the coherence and fitness of the execution surface as a whole.

THE AUTOMATION OWNER

The automation owner is the operationalization of Chapter 12. Every non-human entry in the ownership register has an automation owner. One person can own multiple executors — what matters is that each executor has exactly one named owner, and that ownership is explicit and structured rather than informal and assumed.

What the role does. The automation owner carries the five ownership components from Chapter 12 — know the current state, keep the mode honest, maintain relevance, document what you know, hand it over cleanly — for each executor assigned to them. Their specific monitoring obligations depend on the executor type: logic alignment for automations, behavioral drift detection for AI agents, governance boundary maintenance for vendor dependencies.

How many executors can one person own? It depends on executor type, criticality, and monitoring overhead. A senior engineer might own eight stable, low-criticality automations without capacity strain. The same engineer would struggle to actively own more than two or three consequential AI agents, where behavioral monitoring is ongoing rather than periodic. The ownership register should reflect realistic capacity, not administrative convenience.

Does the owner need to be technical? It depends on the executor type. For code-based automations, yes — the owner needs sufficient technical literacy to understand the logic, interpret output anomalies, and assess whether the system's behavior is aligned with current requirements. For AI agents, the owner needs enough ML literacy to interpret behavioral drift metrics and performance trends. For vendor execution dependencies, the role is primarily contractual and operational — a product manager, procurement lead, or operations person can own a vendor dependency effectively if they understand the governance boundary and can manage the vendor relationship. The executor type, not a blanket technical requirement, determines the appropriate owner profile.

What makes it new. An engineer who informally monitors the automation they built is not an automation owner in this sense. They are an author with informal custodianship. An automation owner has a declared executor type, a documented monitoring cadence, an explicit review schedule, an up-to-date behavioral record, and accountability for transfer when their role changes. The difference is the job description, not the person.

What it is not. The automation owner is not the escalation owner, though the same person may hold both roles in smaller organizations. The automation owner governs the system. The escalation owner handles the cases the system defers. In system-led workflows these are distinct roles, typically held by people with different expertise — the system owner maintains the machine, the escalation owner exercises domain judgment on the cases it cannot resolve.

THE AUTOMATION CAPABILITY GROUP

The automation capability group is not an operational team. It does not build automations on behalf of other teams, approve every deployment, or serve as a compliance gate. It is a small function — often starting as one person — whose leverage comes entirely from the quality and reach of the governance infrastructure it maintains.

The best way to understand its function is through two paired concepts: it is the custodian of the governance library, and the owner of the review process.

The governance library is the organization's accumulated intellectual infrastructure for hybrid execution: the execution mode classification framework from Chapter 4, the ownership standards from Chapter 12, the deployment review templates, the monitoring requirement specifications by executor type, the record of past governance decisions and their rationale, and the documented failure patterns the organization has encountered. The ACG maintains this library, keeps it current as technology and regulatory contexts evolve, and makes it accessible to teams building and deploying automations.

The review process is the structured evaluation that significant new executors go through before deployment. The ACG owns this process — the criteria, the templates, and the facilitation. For high-consequence deployments, the ACG runs a formal review. For lower-risk automations, it provides a self-certification framework that teams complete using ACG-maintained templates. The ACG does not block deployment — it ensures the governance work has been done before deployment happens. This review is the organization's authorization decision: the formal confirmation that an executor is permitted to operate on the execution surface.

Does the ACG do approvals? The ACG owns the review criteria and confirms they have been met. Their authority is the authority of the standard, not a veto. A team that circumvents the process is creating ungoverned execution surface — that is an accountability failure for the team and the CTO, not an enforcement failure for the ACG.

Is this a full-time dedicated team? At early stage: no. One person with explicit responsibility for governance standards is sufficient. At growth stage: one to two dedicated people. At scale: two to four people. The ACG should never be large. A large ACG is a symptom of bureaucratic centralization — the goal is to make distributed teams capable of governing themselves well, not to create a central team that governs on their behalf.

Where it sits. Typically within the CTO's organizational structure — adjacent to or within the platform team, or as a function within engineering leadership. It should never sit within compliance, legal, or risk functions. Its job is to make teams capable of deploying automation well, not to audit them for compliance failure.

THE EXECUTION ARCHITECT

The execution architect is responsible for the design of the execution surface in aggregate. This is the role no existing organizational structure covers: not individual executor governance (that is automation owners), not governance standards (that is the ACG), but the strategic question of what the organization's execution model should look like — which workflows should operate in which modes, where the surface is misaligned with the organization's current capability and scale, and what the migration sequence should be.

The execution architect does not define standards — that remains with the ACG. It defines how those standards apply across the execution surface: which workflows are correctly classified, where mode transitions are overdue, and what the aggregate design of the surface should become.

The execution architect's primary output is not a system. It is clarity.

What the role does. The execution architect maintains the aggregate execution surface map — the two-map model from Chapter 2 at the organizational level, kept current rather than produced once. They identify structural mismatches: workflows in execution modes that are no longer appropriate for their maturity or criticality, areas where automation has outpaced governance, gaps where the surface is growing faster than the ownership model covers it. They develop and maintain the migration roadmap — the sequenced set of execution mode transitions that represent the organization's planned execution model evolution. The migration roadmap is the primary instrument for model-level decisions about where the surface is going. And they ensure the platform investment roadmap is aligned with where the execution surface is going, not only where it currently is.

Is this a technical role? It requires architectural thinking, not deep engineering execution. The execution architect needs enough technical literacy to understand execution mode capabilities and constraints, but their primary work is organizational design — identifying structural mismatches, sequencing transitions, making the case to leadership for execution model investments. A strong senior engineering leader, a VP of Engineering, or a technically fluent chief of staff can hold this role effectively.

Where it sits. At early stage, the CTO absorbs this function directly. At growth stage, it often emerges as an explicit responsibility within engineering leadership. At scale, it is a distinct role — typically a staff-level position within the CTO's organization, with explicit accountability for the execution surface as a strategic asset.

ORG CHART: WHERE THESE ROLES SIT

Figure 2: Scale-stage org chart placement

At scale stage the execution architect sits as a staff role to the CTO. The ACG is a small dedicated function of 2–4 people. Automation owners are embedded within each product team. At growth stage, the CTO absorbs the execution architect function and the ACG is a single person with an embedded mandate.

WHAT THIS LOOKS LIKE

A consumer technology organization reaches one hundred and twenty engineers. The CTO has been informally covering all three functions, which was manageable at eighty engineers but has become a structural problem. The execution surface has grown to forty-seven non-human executors, the governance library exists in fragments across several documents, and the last aggregate surface review was eight months ago.

The correction is sequential, not simultaneous.

First: the ACG function is formalized. A senior engineer with deep automation experience is allocated 30% of her time to own the governance library, deploy the self-certification framework to all product teams, and facilitate reviews for the four significant AI deployments planned for the next quarter. This is not a new hire. It is an explicit allocation and mandate for a function that was previously informal.

Second: automation ownership is audited and formalized across the ownership register. Twenty-three of forty-seven executors have named owners with no structured ownership practice — no cadence, no documentation standard, no review schedule. Each automation owner receives their executor type designation and the corresponding job description from Chapter 12. Owners are asked to confirm their monitoring cadence and complete documentation for their assigned executors within sixty days.

Third, at one hundred and fifty engineers: the execution architect function is created as a staff role. A VP of Engineering who has been managing execution surface questions informally is given the explicit mandate, the time allocation, and the accountability for the aggregate map and migration roadmap.

The organization did not hire three new people. It made three accountability structures explicit that were previously informal — and gave each one a job description.

THE FAILURE MODE

The failure mode of this chapter is creating the titles without creating the accountability. Organizations under governance pressure often respond by naming roles without defining what those roles actually do, what authority they carry, or what the organization expects from them. The result is governance theater: roles on an org chart that do not change the organization's behavior because their accountability is too vague to act on.

The second failure mode is making the ACG too large or too powerful. An ACG with approval authority rather than standard authority becomes a bottleneck. Teams circumvent the process, governance standards lose legitimacy, and the function becomes compliance theater rather than enablement infrastructure.

The third failure mode is mislocating these roles. Placing the ACG in compliance or legal disconnects it from the engineering culture it needs to influence. Placing the execution architect in project management disconnects it from the strategic decisions it needs to shape. Proximity to the work is not optional for any of these roles.