Chapter 18: Pushing Decisions Down — and Knowing When Not To
A growing organization has a natural tendency to centralize decision authority — not by design, but by inertia. The first version of almost every governance model is a person: the CTO who reviews automation deployments, the senior engineer who approves architectural changes, the VP who signs off on mode transitions. This works at small scale because the volume is manageable and the person at the center has the context to add genuine value to each decision. It breaks at larger scale not because the person becomes less capable but because the surface they are governing grows faster than any individual can meaningfully review.
The response to this breakdown is usually to push decisions down — to distribute authority to teams, to establish self-certification processes, to define what requires central review and what does not. When this is done well, it resolves the bottleneck without sacrificing governance quality. When it is done poorly — authority distributed without governance infrastructure at the receiving level, or distributed faster than the organization can verify that the infrastructure is functioning — it resolves the bottleneck by eliminating governance rather than decentralizing it.
This chapter addresses a different question: how decision authority is distributed across the organization as the execution surface grows.
THE CORE IDEA
In a hybrid organization, the distribution of decision authority across organizational levels is an active design variable. It is not an emergent property of team structure or an output of individual role definitions. It is something the CTO must explicitly shape, and must reshape as the organization grows, the execution surface expands, and the governance capability of teams develops.
The critical word is distribution. A single delegation decision — the explicit leadership choice to authorize an executor to operate in a specific mode with a specific scope of authority, as established in Chapter 17 — is a point decision. Distribution is the aggregate of all such decisions across the organization at a point in time, plus all the informal authority that has accumulated by practice rather than by design.
Distribution fails in two directions. Authority concentrated too high produces governance theater: central review gates that teams route around, approval processes that add delay without adding decision quality, nominal oversight that signals control while the actual decisions are made elsewhere. Authority distributed too low produces governance gaps: teams with formal authority over decisions they do not have the infrastructure to make well, execution surface behavior that no one at a high enough level is monitoring, and accountability that diffuses at the boundary between human authority and system execution.
In practice, both failure modes exist simultaneously in most hybrid organizations above a certain scale. The right half of the execution surface has too little central oversight. The wrong half has too much. The distribution is wrong in both directions at once — not because the organization intended this, but because distribution was never explicitly designed.
Figure: How decision authority should be distributed — and how it drifts
Correct placement by decision type and organizational level, with the two failure modes: drift up under governance pressure, drift down under growth.
HOW DISTRIBUTION DRIFTS
Distribution is not stable. It drifts from its designed state in four predictable ways, each of which produces a different corrective requirement.
Authority drifts up under pressure. When a significant governance failure occurs — an ungoverned deployment causes an incident, a recalibration is missed and produces a visible outcome failure — the organizational reflex is to add a review gate at the level where accountability for the failure landed, typically senior leadership. The gate resolves the immediate accountability question. It does not address the structural cause.
Authority drifts down under growth. As teams develop capability and establish practice, decisions that previously required central review become routine — and informal practice adjusts before formal authority does. Teams begin making decisions technically above their designated authority level because the decisions are routine for them and the central review adds no value. The informal adjustment is often correct. The governance problem is that no one has validated that it is correct, documented the new boundary, or confirmed that governance infrastructure at the team level is adequate for the expanded scope.
Authority distributes unevenly across teams. Different teams develop governance capability at different rates. A uniform authority model — the same self-certification rights for every product team — produces strong governance where capability is high and inadequate governance where capability is low. The organization believes the distribution is coherent because every team has the same formal authority. The actual governance quality varies significantly.
The system layer grows faster than the human authority model tracks. As the execution surface expands, a growing proportion of consequential decisions are made by systems rather than by people. The human authority model — who has standing to approve what, at what level, through what process — was designed for a surface where humans made the decisions. As systems take over more of the decision load, the human authority model becomes increasingly incomplete: it governs the decisions humans make about the surface but not the decisions the surface makes itself. Chapter 19 addresses this directly; the point here is that human authority distribution cannot be designed in isolation from the system delegation design that sits alongside it.
THE RIGHT LEVEL FOR EACH DECISION CLASS
The practical design question is not a universal theory of delegation. It is a working answer to the question: for this decision class, in this organization, at this point in its development — where should authority live?
The answer is determined by three inputs.
Where does the best information for this decision reside? Decisions about individual executor behavior — whether a specific AI agent's outputs are drifting, whether a particular automation's logic remains aligned with current requirements — are best made by the team that operates the executor. They have the domain context and operational visibility the center does not. Decisions about the overall execution surface — whether the aggregate portfolio of automated decisions remains appropriate, whether governance fitness is being maintained across all teams, whether the platform infrastructure is keeping pace — require an aggregate view that no individual team holds. Those decisions belong at the center.
Does the receiving level have the governance infrastructure to make this decision well? Authority should not precede infrastructure. A team that has been given self-certification authority before it has internalized the governance standards, before it has an automation owner who understands the monitoring requirements for its executor types, and before it has participated in at least one ACG review is holding authority without the support structure to exercise it soundly.
What is the consequence of a poor decision, and how reversible is it? Deployment decisions for low-consequence, highly reversible automations can be distributed aggressively. Decisions that are structurally difficult to reverse — mode changes that are operationally expensive to undo, authority scope expansions that create compliance obligations — require more central involvement regardless of the receiving team's capability, because the cost of error exceeds what team-level accountability can absorb.
THE CTO'S ACTIVE ROLE
Distribution does not maintain itself. The CTO is the active owner of the organization's decision architecture — not as the decision-maker for each case, but as the designer and steward of how decisions are distributed.
Calibration at scale inflections. Each significant growth in organizational size, execution surface complexity, or governance model maturity changes the correct distribution. The CTO must actively redesign the distribution at each inflection rather than waiting for failure to force the change. At forty engineers, the CTO as the single governance gate is appropriate. At one hundred and twenty engineers with sixty-three non-human executors, the same approach is a governance liability — the volume has outpaced meaningful attention, and teams have begun treating central approval as a compliance step rather than a governance one.
Monitoring for drift symptoms. The signals that distribution has drifted are organizational, not technical. Teams routing around governance gates — submitting approvals they know will pass, designing deployments below the review threshold — signal that authority is too concentrated. Teams making decisions at a level of consequence that exceeds their formal authority — because the central process is too slow, because the boundary is unclear, because informal practice has diverged from formal design — signal that authority has drifted downward without validation.
Differentiated distribution by team governance maturity. As the organization matures, the CTO should move toward a distribution model that reflects actual governance capacity at the team level: more authority for teams with demonstrated governance practice, more central involvement for teams in high-consequence domains or with less established infrastructure. Uniform distribution is an approximation that becomes less accurate — and more costly — as the spread of governance maturity across teams widens.
KNOWING WHEN NOT TO PUSH DOWN
Three conditions under which authority should be held at the center regardless of organizational pressure to distribute.
When the governance infrastructure at the receiving level is not yet functioning. Authority and infrastructure must be sequenced. Distributing authority to a team that does not yet have a functioning ownership model, has not established behavioral monitoring for its executor types, and has not demonstrated the capacity to identify and respond to governance conditions is not delegation — it is exposure. The organization has transferred the accountability label without the accountability substance.
When the consequence of a poor decision requires executive accountability. Some decisions carry organizational consequences — regulatory, reputational, operational — whose magnitude requires that a named executive accept accountability for the decision quality. Delegating those decisions to teams does not transfer the accountability. It diffuses it. The decision is made at the team level. The consequence falls at the organizational level. No one is accountable for the gap.
When the decision is a recalibration that has become a delegation question. As established in Chapter 17, a recalibration that concludes the execution mode must change has crossed into delegation territory. When teams complete mode changes within the dual-ownership process without escalating to leadership, they are making a delegation decision at the wrong level. The distribution design must make this boundary explicit and testable — not rely on teams to self-identify when they have crossed it.
THE FAILURE MODE
The failure mode specific to this chapter is the organization that treats distribution as a solved problem — where the authority model was designed at a point in time and has not been revisited as the organization grew, the execution surface expanded, and governance capability developed unevenly across teams.
In this organization the formal authority model describes a distribution that was correct eighteen months ago. The actual distribution has drifted: some authority has concentrated upward in response to failures, some has diffused downward as teams developed capability, and the system layer has grown past the point where the human authority model meaningfully covers it. The gap between the formal model and the actual distribution is visible only in aggregate — and only to someone actively monitoring the organization's decision architecture.
The CTO who has not built that monitoring function is operating a distribution she did not design. The decisions are being made. Where they land, by whom, and whether the governance infrastructure at the receiving level is adequate — these questions cannot be answered because the distribution was stopped being actively designed when the initial model was established.