Chapter 6: The Unit of Execution Revisited
Every organizational design begins with a foundational unit. The unit is the thing you build from — the atomic element that, combined and arranged in different ways, produces the larger structure. In traditional organizational design, that unit is the team. A group of people, bounded by a shared mission, with a named owner, a defined scope, and a set of resources allocated to it. Build enough of those units correctly and connect them well, and you have an organization.
That unit still exists in a hybrid organization. But it is no longer sufficient as a description of how work executes. A team in a hybrid organization is not just a group of people. It is a group of people plus the execution surface they govern — the systems, automation, and AI agents that execute alongside them, at their direction, within boundaries they own. The human group is one component of the unit. The non-human execution layer is another. Together, they constitute what a team actually is and what it is actually capable of.
Redefining the unit of execution is the first structural act of the hybrid organization. Everything that follows depends on this definition being correct.
The Core Idea
In a traditional organization, a team's capacity is its people. Five engineers can do the work of five engineers. Ten engineers can do the work of ten. Capacity scales with headcount, and headcount is the primary variable the organization controls when it wants to change what a team can produce.
In a hybrid organization, a team's capacity is its execution surface. Headcount is only one component of that surface. That surface also includes every system, automation, and AI agent the team governs. A team of five engineers with a well-designed automated execution layer may have the effective capacity of fifteen. A team of ten engineers with a poorly governed, partially automated execution surface may have less real capacity than it appears — because significant human effort is being spent managing the gaps and failures in the automated layer rather than producing outcomes.
The unit of execution is therefore not the team as a headcount. It is the team as a governed execution surface — the combination of human judgment and non-human execution that the team operates as a coherent system.
This redefinition has three immediate consequences for organizational design.
First, team sizing is no longer primarily a headcount question. The right question is not how many people this team needs, but what this team's full execution surface should look like — what it should execute in human-led mode, what in human-assisted, what in system-led, what in fully automated — and what human capacity is required to govern and improve that surface.
Second, team capability is no longer fully visible on the org chart. A team that looks like five engineers may be governing a system layer that is doing the work of twenty. A team that looks like twelve engineers may be spending half its human capacity managing an ungoverned automated layer that was never designed for the work it is being asked to do. The org chart shows headcount. The unit of execution — properly defined — shows actual capacity.
Third, the accountability structure must extend to the full execution surface, not just the human portion. The team lead is not accountable only for what the engineers produce. They are accountable for what the team's execution surface produces — including the systems, automations, and AI agents operating within it.
What This Looks Like
A platform engineering team at a software company is responsible for the internal developer experience — the tools, infrastructure, and systems that product engineering teams depend on to build and ship software.
On paper, the team is eight people: a team lead, five platform engineers, a reliability engineer, and a developer experience specialist.
In practice, the team's execution surface is considerably larger. It includes a CI/CD system that runs thousands of pipeline executions per day. A developer tooling suite — editors, linting tools, code analysis systems — configured and maintained by the team. An infrastructure provisioning layer that product teams use to spin up environments on demand. A monitoring and observability stack that tracks the health of production systems across the organization. An incident management system that routes alerts, manages escalations, and generates post-mortem drafts using an AI layer the team integrated six months ago.
The team does not run eight people's worth of execution. It governs a system that executes far beyond its headcount. If the CI/CD system fails, that is a platform team failure — not a vendor problem or an infrastructure problem. If the incident management AI begins routing escalations incorrectly, that is a platform team problem — the team owns the system, and its behavior is their responsibility. If the infrastructure provisioning layer develops a bottleneck that slows product teams down, the accountability sits with the platform team — not distributed across the product teams experiencing the friction.
This is what the unit of execution looks like when it is defined correctly. The team is eight people. The execution surface they govern is the platform that enables the entire engineering organization to function. Sizing, structuring, and holding that team accountable to only the eight people misses the actual scope of what the team owns and operates.
The Failure Mode
The failure mode that emerges from an incorrectly defined unit of execution is persistent underestimation — of capacity, of risk, and of accountability scope. The organization is consistently smaller than the system it is responsible for.
When teams are defined by headcount only, the organization consistently underestimates what a well-designed team can do. A team of five with a sophisticated automated execution layer is treated as a team of five — constrained by the planning model to the output of five humans — when it is actually capable of producing at a significantly higher scale. The automation investment is invisible in the planning model, so its capacity contribution is never credited, never measured, and never deliberately grown.
The same definition consistently underestimates risk. A team of twelve with a poorly governed automated layer is treated as a team of twelve — given accountability for what twelve engineers produce — when in reality a significant portion of the system's behavior is ungoverned and unmonitored. The risk is not in the twelve people. It is in the execution surface they are not governing.
And it consistently misframes accountability. When something goes wrong in the automated layer, the instinct is to treat it as an infrastructure problem, a vendor problem, or a technical failure rather than a team accountability failure. Because the automated layer was never formally part of what the team owns, the accountability has nowhere to route.
Each of these underestimations compounds over time. The organization builds planning models, risk frameworks, and accountability structures on an incomplete definition of what a team is — and the gaps accumulate until they produce a failure significant enough to force recognition.
The Structural Correction
Redefining the unit of execution requires two explicit changes to how teams are described, resourced, and held accountable.
First: teams are defined by their execution surface, not their headcount. A team charter in a hybrid organization describes not only the team's mission and the people on it, but the full execution surface the team governs — the systems, automations, and AI agents it owns, the execution modes those elements operate in, and the governance model that covers each. This is not a documentation exercise. It is a design act — one that makes explicit what the team is responsible for producing, how it produces it, and what governance the non-human portion of its execution layer requires.
In practice, this means a team charter has two sections where traditional charters have one. The first covers the human team: its mission, its members, its ways of working. The second covers the execution surface: the systems and automations it governs, the AI agents it operates, the execution mode of each, the monitoring in place, and the named owner for each non-human executor. The two sections together define what the team actually is. What is not described in the execution surface is, by definition, unowned.
Second: team capacity is measured against the full execution surface. Capacity planning for a team in a hybrid organization does not begin with headcount. It begins with the execution surface: what does this surface need to produce, across what volume, at what reliability? From that starting point, the design question is how much of that production should be human-led, how much human-assisted, how much system-led, how much fully automated — and what human capacity is required to govern and improve the surface that results.
Headcount is the output of that analysis, not its starting point. The number of engineers on a team is determined by what the governed execution surface requires of its human layer — judgment, design, governance, improvement — not by the volume of work the team is expected to process.
This reframing does not eliminate headcount as a planning variable. It relocates it to its correct position: a consequence of execution surface design, not a substitute for it.