Chapter 14: What Changes for Existing Roles
The previous chapter addressed roles that did not exist before hybrid execution. This chapter addresses roles that did — and that are now operating in a context their original design did not account for.
The change is not cosmetic. An engineering manager who now governs an execution surface containing AI agents, automated pipelines, and vendor execution dependencies is not simply managing a larger team. They are managing a fundamentally different accountability surface — one where the work they are responsible for is no longer produced exclusively by people they can observe, coach, and develop.
This chapter works through four roles that appear in most technology organizations and examines precisely what changes in a hybrid execution context: what remains, what expands, and what requires a new capability the role did not previously need.
The roles introduced in Chapter 13 create the governance infrastructure. The roles in this chapter determine whether that infrastructure is actually used.
Figure: Role expansion matrix — hybrid execution context
Each role expands rather than transforms. The unchanged column shows what continues. The teal column shows scope additions. The coral column shows genuinely new capabilities with no direct predecessor in human-centric organizations.
THE CORE IDEA
Every existing role in a technology organization was designed around an implicit assumption: the work being produced is done by people. Accountability flows to managers because managers direct people. Capacity is measured in engineers because engineers produce output. Quality is governed through code reviews, design reviews, and testing because humans write the code being reviewed.
In a hybrid organization, this assumption holds for part of the execution surface — but only part. The remainder is executed by systems, agents, and vendor services that do not have one-on-ones, do not appear in sprint velocity, and do not receive performance feedback. They have owners, as Chapter 12 established. But those owners operate under their existing role — engineering manager, staff engineer, head of engineering, VP of technology — with a job description written for a different execution environment.
The adaptation required is not a different role. It is an expanded accountability model within the existing role — one that treats the non-human execution surface as part of what the role is responsible for governing, not as infrastructure that sits outside the management frame.
Four specific adaptations apply across all roles.
Governance replaces observation. In human execution, a manager governs work through direct observation — attending standups, reviewing pull requests, reading design documents. In hybrid execution, a significant portion of the execution surface cannot be governed through observation. It must be governed through structured review: defined monitoring cadences, execution mode audits, ownership register checks.
Capacity accounting expands. Capacity planning in a human organization counts engineers and estimates their output. In a hybrid organization, capacity includes the execution surface that systems provide. A manager who plans capacity by counting engineers only is systematically undercounting the team's actual execution capacity and making investment decisions against an incomplete picture.
Ownership becomes a management responsibility. In a human organization, accountability for work is established through assignment — a manager assigns a task to a person. In a hybrid organization, accountability for non-human execution requires the same explicit assignment through the ownership model. A manager whose team has deployed automated workflows and AI agents without explicit ownership assignment has created accountability gaps that will surface as governance failures.
Technical leadership decouples from execution depth. In a human-centric engineering organization, technical credibility is closely coupled to execution depth — the ability to write the code, resolve the hard technical problem. In a hybrid organization, technical leadership increasingly requires a different capability: the ability to reason about execution surfaces that include non-deterministic systems, to evaluate governance fitness across executor types, and to make design decisions about which work should be allocated to which execution mode.
THE ENGINEERING MANAGER
The engineering manager role sits closest to the execution surface. An EM is accountable for a team's output — for the quality of what gets shipped, the velocity at which it ships, the health of the people producing it, and the fitness of the processes that govern delivery. In a hybrid organization, this accountability extends to the non-human execution surface the team owns.
What remains the same. The EM's accountability for people — their development, their capacity, their performance, their wellbeing — is unchanged. The EM's accountability for delivery outcomes is unchanged. The team still ships product. The EM still owns the team's ability to ship well.
What expands. The EM's accountability surface now includes the execution surface the team governs — every automation, AI agent, and vendor dependency that the team has ownership of. The EM is not personally responsible for running monitoring checks on each executor. They are responsible for ensuring that each executor has an owner who is running those checks, that the ownership register for their team's executors is current and accurate, and that ownership transfers happen cleanly when team membership changes.
The EM's capacity planning model must also expand. When a team's execution surface includes workflows that absorb significant volume without human effort, that capacity is real and should be reflected in how the EM represents the team's throughput to leadership. An EM who presents capacity only in terms of engineer-hours is leaving a significant portion of the team's execution capacity invisible.
What requires a new capability. The EM needs enough fluency in the ownership framework to recognize when an executor on their team's surface is ungoverned or incorrectly governed — when an owner is nominal rather than active, when a mode classification is stale, when a behavioral documentation gap would make a transfer problematic. This is not deep technical expertise. It is governance literacy: the ability to ask the right questions of an automation owner and recognize when the answers reveal a gap.
THE STAFF ENGINEER
The staff engineer role is the organization's senior individual contributor — the person who holds technical accountability for the most consequential engineering decisions without managing a team directly. In a hybrid organization, the scope of consequential technical decisions expands significantly.
What remains the same. The staff engineer's accountability for architectural quality, for technical decision-making, for mentoring and raising the technical standard of the engineering organization — none of this changes. The code still needs to be well-designed. The systems still need to be well-architected.
What expands. The staff engineer's technical accountability now extends to execution surface design. When a team is deciding whether a workflow should be human-led, human-assisted, or system-led — that is a technical decision with architectural, governance, and organizational consequences. The staff engineer is the right person to own that decision framework. Where the execution architect governs the aggregate surface, the staff engineer governs the execution mode quality of individual systems at the design level — ensuring modes are correctly classified at inception, that system-led boundary conditions are well-designed, that AI agent deployments are architecturally sound for the governance requirements they impose.
The staff engineer's technical mentorship also expands. In a human-centric organization, technical mentorship focuses on code quality and engineering craft. In a hybrid organization, it must also develop governance literacy in the engineers they mentor — the ability to own an executor actively rather than nominally, to recognize behavioral drift in AI agents, to design automation that is governable rather than merely functional.
What requires a new capability. The staff engineer needs to develop a working model of execution mode trade-offs that goes beyond the purely technical. Choosing system-led over human-assisted is not only a question of system capability — it is a question of governance overhead, escalation path design, and organizational readiness to maintain that mode. A staff engineer who evaluates execution modes on technical merit alone, without accounting for governance fitness, will make recommendations that create ungoverned execution surface downstream.
THE HEAD OF ENGINEERING
The head of engineering role sits between the management layer and senior engineering leadership. It is typically responsible for the health of the engineering function as a whole — the processes, the standards, the culture, and the operational model that allows engineering to execute effectively at scale. In a hybrid organization, this role bears a specific new accountability: the governance model for the organization's execution surface.
What remains the same. The head of engineering's accountability for engineering process quality, delivery health, and organizational culture is unchanged. The engineering function still needs clear processes, healthy team dynamics, and standards that allow quality work to be produced consistently.
What expands. The head of engineering becomes the primary internal champion for the governance model — the person who ensures that the ACG has the organizational mandate to operate effectively, that the ownership register is treated as a live instrument rather than a compliance artifact, and that execution mode classification is embedded in the engineering organization's standard processes rather than treated as an optional governance layer.
This is different from owning the governance model directly — that sits with the ACG. The head of engineering owns the organizational conditions that allow the governance model to work: the cultural expectation that ownership is real rather than nominal, the process requirements that make governance reviews a normal part of deployment, and the management accountability that ensures EMs are treating executor governance as a real part of their job.
What requires a new capability. The head of engineering needs a working model of execution surface health at the organizational level — the ability to read the ownership register's aggregate health, recognize the patterns that indicate governance fragmentation, and distinguish between an engineering organization deploying automation with appropriate governance discipline and one accumulating ungoverned execution surface under delivery pressure.
THE VP OF ENGINEERING AND CTO
The VP of Engineering and CTO roles represent the senior leadership layer of the technology organization. They are accountable not for the execution surface of individual teams, but for the execution model of the entire organization — the strategic decisions about how the organization uses technology to execute at scale, and whether the organizational design supports those decisions effectively.
What the VP of Engineering owns. The VP owns the operational fitness of the hybrid execution model across the engineering organization. This includes: ensuring the organizational conditions for governance are in place — the ACG has a mandate, the ownership register is maintained, EMs understand their expanded accountability; ensuring that execution surface health is a visible input to organizational planning decisions; and ensuring that the engineering organization's delivery metrics reflect hybrid execution reality — that capacity planning accounts for the system execution layer, not only for the human layer.
What the CTO owns. The CTO owns the strategic design of the execution model. Which domains should move toward more automated execution? Where does the organization's execution surface need to evolve to support the product strategy? How should the platform investment align with the execution surface's direction? Is the governance model keeping pace with the rate of automation adoption, or is ungoverned execution surface accumulating faster than the governance model covers it?
These are questions that did not exist in the CTO role in a human-centric organization, because the execution model and the org chart were the same thing. In a hybrid organization, they are distinct. The CTO must govern both.
What requires a new capability. Both roles require the ability to reason about execution surface health as a strategic indicator — not just as a governance compliance question. An execution surface where significant automation is ungoverned is an execution surface accumulating operational risk that will eventually surface as an incident, a compliance failure, or a strategic capability loss. The CTO and VP who can read execution surface health as a leading indicator of organizational risk — rather than waiting for the lagging indicators of incidents and failures — are the ones who will govern hybrid execution well.
THE FAILURE MODE
The failure mode specific to this chapter is role adaptation that happens in title but not in practice. The engineering manager who attends an AI governance training but does not change how they conduct one-on-ones with automation owners. The staff engineer who approves an AI deployment without reviewing the behavioral monitoring plan. The head of engineering who adds execution surface health to the agenda of one meeting and then does not follow through.
These partial adaptations are more dangerous than no adaptation because they create the impression that the governance model is working. The EM believes they are governing their team's execution surface because they attended a training. The organization believes it is governed because the head of engineering put it on the agenda. Neither belief is grounded in structural change.
The second failure mode is treating hybrid execution governance as the job of the new roles from Chapter 13 — delegating accountability to the ACG and the execution architect while existing roles continue to operate as if the execution surface were purely human. The ACG maintains the standards. The execution architect maps the surface. But neither can substitute for the management accountability of an EM who ensures their team's executors are genuinely owned, or the technical accountability of a staff engineer who ensures that execution modes are correctly classified at design time. The new roles create the infrastructure. The existing roles must use it.