Chapter 27: The Unit Economics Shift

Every economic model for technology organizations rests on a foundational assumption: capacity equals people. To deliver more, you hire more. To reduce cost, you reduce headcount. To scale, you grow the team. This assumption is so embedded in organizational finance — in how budgets are constructed, how productivity is measured, how cost is allocated — that it operates as an invisible constraint on how leaders think about the economics of technology delivery.

The hybrid organization breaks this assumption. When a system executes outcomes — decisions, transactions, assessments, recommendations — the marginal cost of each additional outcome is not a function of people. It is a function of infrastructure. The unit economics of the organization shift from cost per employee to cost per executed outcome. This shift does not eliminate cost. It restructures it into a different economic system — one that creates real advantage at scale and real risk if the restructuring is not understood.

Understanding that restructuring requires four things. A clear account of what the cost structure actually looks like in a hybrid model — including costs that automation ROI calculations routinely ignore. A precise separation of recurring governance costs from the one-time costs of building an executor. An understanding of how costs behave at the surface level, not just at the individual executor level. And a decision instrument — the crossover analysis — that must be run before a build decision is made, not before deployment, and not after. Each of these is addressed in this chapter.

THE CORE IDEA

In a human model, cost is tied to capacity. In a hybrid model, cost is tied to infrastructure and governance. That distinction is the entire economic argument for hybrid execution — and it is the one most automation ROI calculations fail to make correctly.

In a human execution model, cost scales with capacity. Each additional outcome requires additional human time. The cost curve is approximately linear: double the volume, roughly double the cost. The relationship is direct and visible. The fully-loaded cost of a decision is the cost of the people involved in making it, allocated across the decisions they produce.

In a hybrid execution model, this relationship breaks at the execution layer. A system-led executor that processes ten thousand transactions per day costs approximately the same in marginal terms as one that processes one thousand. The incremental cost of the ten-thousandth transaction — the compute, the API call, the inference — approaches zero at the scale most organizations operate at. The cost of the next outcome is not the cost of the next person.

What does not approach zero is the governance layer. The Automation and Control Group that authorizes the executor. The governance owner who monitors it weekly. The monitoring infrastructure that generates signals. The recalibration process that corrects drift. These are fixed costs — they do not scale linearly with execution volume. They are part of the governance floor: the minimum cost the hybrid model never escapes, regardless of how many outcomes the system executes.

The governance floor also has a one-time component: the engineering cost of building the executor in the first place, and the ACG onboarding cost at deployment. These are not recurring, but they are real, and they affect whether the economics are positive — particularly in year one.

The economic case for hybrid execution is not that it is cheaper. It is that the cost structure is different — low marginal cost per outcome at scale, combined with fixed recurring governance costs and an upfront build investment. Whether hybrid execution is economically superior depends on volume and time horizon. At low volume in year one, it frequently is not. At scale over a three-to-five year horizon, it frequently is. The decision instrument that resolves this is the crossover analysis.

THE GOVERNANCE FLOOR

The governance floor is the most important concept in the economics of hybrid execution — and the most consistently ignored in automation ROI calculations. Every analysis that concludes a process can be automated at near-zero cost per transaction is correct about the marginal infrastructure cost and silent about the governance cost. The governance floor is what that analysis leaves out.

To make the governance floor concrete: a regional e-commerce retailer automates its returns classification process — the system that determines whether a returned item is resellable, requires refurbishment, or should be written off. The marginal infrastructure cost per classification is negligible. What the ROI model omits is the following. A senior operations engineer serves as governance owner, spending forty-five minutes each week reviewing classification accuracy, drift metrics, and escalation patterns — thirty-nine hours per year at senior engineer fully-loaded rates. The monitoring infrastructure that produces those metrics runs on the platform team's shared infrastructure budget. The ACG review at deployment consumed six hours of senior engineering and legal time. The capability team spent four sprints building, testing, and validating the classifier before deployment. None of this appears in the headline ROI figure.

These costs are the governance floor. They fall into three components, each with a distinct cost profile.

The governance floor is not optional. It is the cost of making system execution safe, correct, and accountable. An organization that believes it can automate without incurring these costs is not running a hybrid model — it is running an ungoverned one. The question is never whether to pay the governance floor. It is whether the volume of execution justifies it.

Governance infrastructure comprises the ACG operating overhead, the monitoring systems, and the ownership register that tracks authority grants. These costs are largely fixed up to a capacity threshold — the ACG does not cost significantly more to operate with forty executors than with twenty. Monitoring infrastructure scales with the number of executors, not with the transaction volume any individual executor processes. A fraud detection model that handles one million transactions per year carries approximately the same monitoring cost as one handling ten million.

Ownership model costs are the time commitment of the governance owner, purpose owner, and escalation owners assigned to each executor. The governance owner's forty-five-minute weekly monitoring commitment is the same whether the executor processes ten thousand transactions or ten million. These costs scale with the number of executors on the surface, not with the volume of outcomes any individual executor produces. An organization with thirty executors carries thirty governance owner commitments regardless of whether those executors collectively process one million or one hundred million outcomes.

Capability infrastructure is the engineering capacity that builds, maintains, recalibrates, and improves the executors. This cost scales with the ambition and complexity of the execution surface — more executors, more sophisticated models, more frequent recalibration — rather than with transaction volume directly. It is partially shared across the surface and partially specific to individual executors depending on their complexity.

The governance floor matters economically because it determines the volume and time horizon at which hybrid execution becomes cost-advantageous. A governance owner committing thirty-nine hours per year at fully-loaded rates of £120 per hour costs the organization approximately £4,700 per year, before any allocation of monitoring infrastructure or ACG overhead. That cost does not change with volume. What changes with volume is the per-outcome cost that floor generates — and whether that per-outcome cost, combined with marginal infrastructure cost, falls below the equivalent human cost.

THE ONE-TIME BUILD COST

Separate from the recurring governance floor is the one-time cost of building the executor. It is important to distinguish two components that are often conflated in ROI models but have different economic characters.

Executor build cost is the engineering effort required to design, develop, test, and deploy the specific executor — the work that is unique to this executor and would not exist if this executor were not being built. It also includes the ACG onboarding process — the authority grant review, compliance documentation, and deployment approval — which is consumed once at deployment and does not recur. This cost is properly amortized over the executor's expected operational life, because it is an asset whose value is consumed as the executor processes outcomes over its life.

Platform cost allocation is the executor's share of the shared platform build cost — the execution environment, model serving layer, integration framework, CI/CD infrastructure. The platform is not an executor-level asset. It is a surface-level asset, built once and shared across all executors that run on it. Its cost should be amortized over the platform's expected operational life — typically five to ten years — and allocated across the executors in production, declining on a per-executor basis as the surface grows. An executor is not responsible for the full platform cost; it is responsible for its proportional share of the annual amortization. This distinction matters: an executor whose economics look marginal when carrying the full platform cost may be clearly justified when carrying only its share of the annual amortization.

The one-time executor build cost matters for two reasons. First, it makes year-one economics materially different from year-two and beyond. An executor with an executor build cost of £120,000 and an annual governance floor of £40,000 carries a total first-year cost of £160,000 plus its platform cost allocation. In year two, the total cost is £40,000 plus the platform allocation — the recurring floor only. An ROI model that evaluates the automation decision based on year-one economics alone will understate the long-run economic case. An ROI model that ignores the build cost will overstate it.

Second, the executor build cost sets the minimum volume required for positive economics in year one. If the executor replaces a human process costing £80,000 per year and the executor build cost plus year-one governance floor is £160,000, the organization is economically negative in year one regardless of volume. The question is whether the trajectory — the volume growth over the executor's expected life — justifies the investment. That is a three-to-five year calculation, not a year-one calculation. The crossover analysis, discussed below, makes this explicit.

The executor build cost also affects the decision about whether to automate at all. A narrow, well-scoped executor with a build cost of £30,000 crosses into positive economics at a much lower volume threshold than a complex, broad-scope system costing £300,000. Build cost is not a fixed parameter — it is a design variable. An organization that designs executors with the crossover analysis in mind will scope them to minimize build cost where volume is uncertain, and invest in broader capability where volume trajectory is strong.

THE FULL EXECUTION SURFACE

The governance floor analysis applies at the individual executor level — the costs associated with governing and maintaining a single executor. But the hybrid organization also carries costs at the surface level that do not reduce cleanly to individual executors. Understanding the economics requires both levels.

The platform infrastructure on which executors run — the compute environment, the model serving layer, the data pipelines — is a surface-level cost. It does not double when the number of executors doubles, because much of it is shared. An organization running twenty executors on a shared platform pays less per executor than one running four executors on isolated infrastructure. The surface-level platform cost distributes across the executor portfolio, meaning the per-executor platform cost falls as the surface grows — a meaningful economic argument for consolidating execution on a shared platform rather than building each executor in isolation.

The ACG itself is a surface-level fixed cost. Its operating overhead — the governance review cadence, the authority grant process, the compliance function — is approximately constant within a capacity range. An organization with ten executors and one with thirty executors pay roughly the same ACG operating cost, because the ACG's overhead is driven by its operating model, not by the number of executors it governs up to a capacity threshold. Above that threshold, ACG capacity must expand — but the expansion is step-function, not linear.

This has an important economic implication. The marginal cost of adding a new executor to a mature surface is lower than the cost of the first executor, because the platform and ACG infrastructure is already in place and its cost is already being borne. The decision to add executor twelve is economically different from the decision to build the first. The crossover analysis for executor twelve needs only to justify the incremental governance floor for that executor — the governance owner commitment and the monitoring addition — not the full platform and ACG cost, which is already sunk.

Organizations that evaluate every executor as if it were the first one systematically understate the economic case for expanding a mature execution surface. Organizations that ignore surface-level costs entirely when evaluating the first executor systematically overstate the case for building it. The correct model allocates surface-level costs across the executor portfolio at a point in time, recognizing that this allocation changes as the surface grows.

FIGURE 1 — The Governance Floor: Fixed Cost Components by Group
Cost Component	What It Comprises	Cost Behavior
GOVERNANCE INFRASTRUCTURE	ACG operating overhead (review cadence, authority records, grant management)	Fixed up to capacity threshold; does not scale with transaction volume
	Monitoring infrastructure (dashboards, alerting, drift detection pipelines)	Fixed per executor; scales with number of executors, not transaction volume
	Governance owner time (weekly monitoring, recalibration, escalation handling)	Fixed per executor per year; same hours whether volume is 10K or 10M outcomes
ONE-TIME BUILD COST	Engineering build cost (design, development, testing, initial deployment)	One-time; amortized over the executor's expected life in the crossover model
	ACG onboarding (authority grant process, compliance review, deployment approval)	One-time at deployment; feeds into year-1 economics and amortization schedule
CAPABILITY INFRASTRUCTURE	Platform and tooling costs (shared infrastructure on which executors run)	Scales with surface size, not individual executor volume; allocated across executor portfolio
	Engineering capacity for maintenance, recalibration, and improvement of executors	Scales with executor count and complexity; partially independent of transaction volume

Figure 1: The governance floor comprises three cost groups with distinct scaling behaviors. Governance infrastructure and ownership model costs are fixed per executor and do not scale with transaction volume. One-time build costs comprise the executor build cost (amortized over that executor's expected operational life) and the executor's proportional share of the shared platform build cost (amortized over the platform's expected operational life, typically five to ten years). Capability infrastructure scales with surface complexity rather than individual executor volume.

OUTCOME-BASED COSTING

The shift from cost per employee to cost per outcome requires a different measurement model. Organizations accustomed to headcount-based costing measure technology delivery in terms of team size, sprint velocity, and engineer allocation. These metrics are valid for the human work layer. They are structurally inadequate for the system execution layer, because the system execution layer has no headcount to measure and its velocity is not a sprint metric.

Outcome-based costing measures what the execution surface actually produces: decisions made, transactions processed, assessments completed, recommendations generated. The cost of each governed outcome has two components.

The governed cost per outcome is the annual governance floor for that executor — governance owner time, monitoring infrastructure, ACG overhead allocation, and capability maintenance allocation — divided by the annual volume of outcomes the executor produces. This is the recurring unit cost of making each outcome governable. It falls as volume grows, because the floor is fixed while the denominator increases. At ten thousand outcomes per year with a £40,000 governance floor, the governed cost per outcome is £4.00. At one hundred thousand outcomes, it is £0.40. At one million outcomes, it is £0.04.

The amortized build cost per outcome is the one-time build cost divided by the total outcomes the executor is expected to produce over its operational life. A build cost of £120,000 amortized over five years at one hundred thousand outcomes per year equals £120,000 ÷ 500,000 = £0.24 per outcome. In year one only, this adds £1.20 per outcome (£120,000 ÷ 100,000). By year five, the cumulative amortization is complete and this component disappears.

The total governed and amortized cost per outcome is the sum of these two components plus the marginal infrastructure cost — the compute, API, and inference cost of processing each transaction. For most executors operating at meaningful scale, the marginal infrastructure cost is the smallest of the three. The governance floor, expressed per outcome, is typically the dominant component at moderate volume. At high volume, it becomes negligible.

This measurement model produces the result that most automation ROI calculations avoid: a precise comparison between the human cost of the equivalent process and the fully-loaded hybrid cost. If a human analyst reviews a claims document at a fully-loaded cost of £18 per review, and the hybrid executor processes the same document at a total governed cost of £0.60, the economic comparison is unambiguous at scale. If the hybrid executor processes two hundred claims per year, the comparison is not economically positive in any year.

The outcome costing model forces the volume question that most automation decisions avoid. It is not enough to know that the marginal cost per outcome approaches zero. The relevant question is: at what volume, and over what time horizon, does the total hybrid cost — governed cost plus amortized build cost plus marginal infrastructure — fall below the equivalent human cost? That is the crossover calculation. And it must be run before the build decision is made.

THE CROSSOVER ANALYSIS

The crossover point is where the total hybrid cost falls below the equivalent human cost. It is not a fixed threshold. It depends on three variables: the governance floor for the specific executor, the fully-loaded human cost of the equivalent process, and the volume of outcomes the executor produces. All three must be estimated before the decision to build — not before deployment, not after deployment, but before any significant engineering investment is committed.

This sequencing is deliberate and important. The crossover analysis is not a post-build validation exercise. It is the decision instrument that determines whether to build at all. An organization that runs the crossover analysis after committing a capability team to a four-sprint build has already made the investment decision. The crossover analysis at that point can confirm or regret, but it cannot redirect. The economic discipline the hybrid model requires is running the analysis at the architecture stage, when scope, volume assumptions, and build investment are still design variables.

Most organizations estimate one of the three variables — the marginal cost saving — and ignore the other two. The governance floor is assumed to be negligible or is not counted. The volume estimate is taken from current state rather than modeled against the growth trajectory the automation is expected to serve. The human cost benchmark uses direct labor cost rather than the fully-loaded cost including management, oversight, and the residual human work the automation does not eliminate.

A complete crossover analysis requires all three, structured as follows.

The governance floor calculation uses the ownership model — governance owner time at fully-loaded rates, ACG overhead allocation, monitoring infrastructure allocation, and capability maintenance allocation — to establish the annual fixed cost of governing this specific executor. This is an estimate, not a measurement, but it should be grounded in the actual time commitments of the roles involved and the actual cost of the infrastructure components allocated.

The build cost estimate captures the expected engineering investment required to design, develop, test, and deploy the executor, plus the ACG onboarding cost. It sets the year-one economics and the amortization schedule. The build cost estimate should be made before the build, not after — which means it must be based on scoping and architecture work, not on assumptions. An executor whose scope is not well-defined enough to estimate a build cost is not ready for an economics evaluation.

The human cost benchmark is the fully-loaded cost of the human process the executor replaces or augments. This includes the direct labor cost of the people performing the work, the management overhead of coordinating that work, and the cost of any quality assurance or error-correction processes that exist because human execution is imperfect at scale. It is not the salary of the analyst whose work is automated — it is the total organizational cost of the process.

The volume trajectory projects the expected outcomes per year over the executor's operational life — typically three to five years. This is not a forecast of current volume. It is an estimate of the volume the executor will process when the process is fully transitioned to hybrid execution and when the business conditions that drive volume are understood. An executor built to handle current volume of fifty thousand outcomes per year that is expected to grow to five hundred thousand within two years has a very different crossover profile than one where volume is stable.

With these four inputs, the crossover analysis answers the question directly: at what year, at what volume, does hybrid become cheaper than human — fully loaded, including build cost, governance floor, and marginal infrastructure? If the answer is year four at a volume the organization does not expect to reach, the automation should not be built. If the answer is year two at a volume well within the forecast trajectory, the automation is economically justified. The analysis makes the decision legible.

FIGURE 2 — Crossover Analysis: Human vs Hybrid Cost at Varying Volume
Annual Volume	Human Cost	Hybrid Total Cost	Decision
10,000 outcomes	£120,000	£218,000 (Y1) £98,000 (Y2+)	❌ Below crossover in Y1 ✓ Above crossover from Y2
50,000 outcomes	£600,000	£258,000 (Y1) £138,000 (Y2+)	✓ Above crossover from Y1
200,000 outcomes	£2,400,000	£398,000 (Y1) £278,000 (Y2+)	✓ Strongly positive; scale advantage clear
500,000 outcomes	£6,000,000	£698,000 (Y1) £578,000 (Y2+)	✓ Hybrid delivers 8-10× cost advantage at scale

Figure 2: Illustrative crossover analysis for a document classification executor. Human cost is fully-loaded at £12 per outcome. Hybrid total cost comprises a £80,000 executor build cost (Year 1 only, amortized over executor life), a £38,000 annual governance floor, and £0.05 marginal infrastructure per outcome. Platform cost allocation is shown separately and declines per executor as the surface grows. The crossover point — where hybrid becomes cheaper — shifts significantly with volume. At 10,000 outcomes per year, the executor only becomes economical from Year 2. At 50,000 and above, it is economical from Year 1. These are illustrative figures. The model must be built from actual estimates for each executor.

THE FAILURE MODE

The failure mode is the organization that builds an automation ROI model based on marginal cost savings alone and ignores the governance floor. Every automation project shows a positive return. The governance infrastructure — the ownership model, the monitoring, the ACG overhead — is treated as a sunk cost, allocated to an overhead line, or simply not counted. Headcount reductions are claimed as full savings without accounting for the residual human work that remains. Build costs are treated as a one-time technology investment, not as an amortisable cost in the economic model.

The organization is not saving what it believes it is saving.

Over time, this measurement model produces an organization that believes it has generated significant savings through automation while carrying a governance infrastructure whose true cost it has never accounted for. The gap between claimed savings and actual economic benefit accumulates quietly until it surfaces in a budget review or governance audit. By then, the automation portfolio is established, the governance infrastructure is embedded, and the correction requires not just a measurement fix but a structural one.

The correction begins with the measurement model. Every automation ROI calculation should include the governance floor as a line item, not a footnote. The build cost should appear in the model as a year-one cost and an amortization schedule, not as a capital expense that disappears from the operational view. The human cost benchmark should be fully loaded. The volume trajectory should be explicit. And the crossover analysis should be completed before the build decision is made — which means it must be completed while scope and volume are still negotiable.

The chapter that follows — automation ROI as a design input — addresses how to operationalize this model: how to run the crossover analysis at the architecture stage, how to make volume uncertainty explicit in the model rather than hidden in optimistic assumptions, and how to use the analysis as a genuine decision gate rather than a post-hoc justification. The next question is not whether the economics work after deployment, but how those economics shape the design decisions before it.