Chapter 34: What the CEO Needs to Understand About Organization Design at This Layer

This chapter is not about what the CEO should do. It is about what the CTO must understand about CEO-level coherence for the hybrid execution model to function — and what the CTO must recognize, diagnose, and escalate when that coherence is absent. The reader is the CTO. The subject is the CEO's role. The purpose is to give the CTO a model of where they depend on the CEO, where they cannot compensate, and where they must engage.

The CTO is the executive most dependent on CEO-level coherence — and the least able to compensate for its absence. This is the anchor of the chapter. The CTO builds the governance infrastructure that the COO and CPO operate within. The ACG produces outputs — authority grants, observability, monitoring, recalibration capability — that only produce value when the COO and CPO engage with them. When they do not engage, the infrastructure becomes shelfware. No amount of better infrastructure fixes this. The CTO cannot force a COO to approve authority grants. The CTO cannot require a CPO to specify product observability requirements. Only the CEO can structure an executive team in which that engagement is not optional. The CTO's dependency on the CEO is not a preference. It is structural.

Scope. This chapter operates in a specific relationship to the rest of Part VII. Chapter 32 (COO) and Chapter 33 (CPO) are chapters a CTO can share with a peer executive as a translation of the hybrid model into that executive's language. Chapter 34 is different: it is a chapter the CTO reads to understand what CEO-level coherence governance looks like, where it is absent, and how to engage with the CEO about it. The CEO may read this chapter. The chapter is not written to the CEO. It is written to the CTO about the CEO, because the CTO's accountability for governance infrastructure becomes exercisable only when CEO-level coherence is in place.

WHAT THE CTO NEEDS TO UNDERSTAND ABOUT CEO-LEVEL RESPONSIBILITY

The CEO's accountability is organizational coherence across the three governance domains — not governance of any specific domain. The COO governs operational execution. The CPO governs product execution. The CTO builds the governance infrastructure. The CEO does not take any of these roles. What the CEO is accountable for is whether the three domains, together, are operating as a coherent whole. Whether the COO is resourced for Zone 2 governance. Whether the CPO is staffed for production behavior governance. Whether the interfaces between the domains — where the CTO's ACG engages with the COO and the CPO — are functioning. The CEO does not build governance infrastructure and does not operate within it. The CEO holds whether the executive team collectively can produce a governed execution surface.

The org chart is a representation. The execution surface is the reality. The reporting structure shows who reports to whom. The execution surface shows what actually produces outcomes in the organization's name. In a traditional organization the two were largely the same. In a hybrid organization they are not — a significant portion of the execution surface is composed of systems whose operation is not on any chart. This matters to the CTO because the CTO's governance infrastructure exists to govern that off-chart surface. A CEO whose mental model of the organization is the reporting structure may not recognize that the governance infrastructure the CTO has built is governing the part of the organization the CEO cannot see. The CTO's engagement with the CEO must sometimes begin with making the execution surface visible — because until it is visible, coherence across it will not be governed.

Coherence fails silently — and the CTO is often the first to detect the early signs. Each executive can report accurate performance in their own domain. The COO's operational metrics can be on target. The CPO's product metrics can be healthy. The CTO's infrastructure can be reliable. And yet outcomes can emerge that none of them is accountable for — outcomes that arise from interactions between the domains, at interfaces no single executive owns. The CTO, because of their position in the governance architecture, often sees the early signs: authority grants that the COO is slow to approve, ACG outputs that the CPO is not specifying requirements for, overlap systems where governance attributes are unowned. These are CTO-visible signals of CEO-level coherence failure. The CTO's responsibility is to escalate them accurately — not as CTO problems, not as COO or CPO problems, but as coherence failures that require CEO-level intervention.

DIAGNOSING COHERENCE FAILURE — WHAT THE CTO OBSERVES

When CEO-level coherence governance is absent, the CTO observes specific patterns. Recognizing these patterns — not as engineering issues, not as cross-functional friction, but as the diagnostic signals they are — is a necessary capability for a CTO operating in a hybrid organization.

Pattern 1 — Authority grants stall. The ACG produces technical authority grants that require COO approval to proceed. When the COO's engagement with the ACG interface is undisciplined — grants sit unreviewed for weeks, get approved without operational review, or get declined without specific operational feedback — the CTO observes this first. It appears as ACG throughput degradation. The CTO's diagnostic is not "the ACG is slow" — it is "the COO is not engaging with the ACG at the cadence the operation requires, and no one at the CEO level is observing this." Escalation is warranted when the pattern is repeated, not when it is isolated.

Pattern 2 — Product observability requirements are not specified. The ACG has the capability to build segment-level product observability. Building it requires the CPO's specification of which segments matter, which conditions define the operating envelope, which outcomes indicate quality versus drift. When the CPO has not specified these — when product governance is still operating on feature-centric instincts — the CTO's engineering team either builds no segment-level observability or builds it against engineering-defined segments that do not map to product judgment. The CTO observes this as product-side tickets without clear product ownership, or as observability investments that the product team does not consume. The diagnostic is not "our product team is slow to adopt the tooling" — it is "product ownership has not extended into production behavior governance, and no one at the CEO level is requiring it to."

Pattern 3 — Overlap systems have no named owner per attribute. On systems that span operational and product execution — matching, pricing, moderation — the prelude's principle requires one governance owner per attribute. When that principle is not being observed — when the COO and CPO each assume the other is governing the system, or when both try to govern it partially — the CTO observes governance outputs that no one operates. Alerts that no one responds to. Recalibration recommendations that no one initiates. The CTO's diagnostic is not "our infrastructure is producing too many signals" — it is "governance attributes on overlap systems are unowned, and no one at the CEO level is enforcing the attribute-level split."

Pattern 4 — Within-domain metrics stay healthy while cross-domain outcomes degrade. The most distinctive pattern, and the one the CTO is best positioned to name. Each executive can report positive within-domain performance. The CTO, with visibility into the infrastructure that serves all three domains, can sometimes see what none of the within-domain views reveal: that operational and product systems are interacting in ways that produce outcomes neither domain's metrics capture. This is the coherence failure the chapter's grounding example will illustrate. When the CTO sees it, the responsibility is to name it precisely — not as a technology issue, not as a cross-functional issue, but as a cross-domain coherence failure that requires CEO-level attention.

WHY THE CTO CANNOT COMPENSATE

It is tempting for a CTO who observes coherence failures to try to fix them within the scope of the CTO role. Build better tooling to force engagement. Create technical governance processes that operate regardless of executive engagement. Institute automated escalation that bypasses the missing coherence. Every one of these approaches fails — and understanding why is necessary for the CTO to recognize when technical responses are inappropriate.

Better tooling does not produce engagement. If the COO is not approving authority grants at the cadence the operation requires, a better authority grant workflow will not change that. The tooling is not the barrier. The governance model that requires COO engagement is not being held by the executive team. Building better tooling produces better shelfware. The CTO's instinct to solve problems with infrastructure is useful within the CTO's scope; applied to a coherence problem, it produces infrastructure that cannot be operated because the operators are not engaged.

Technical governance cannot substitute for executive accountability. The ACG is a technical governance body. It produces outputs that require operational and product judgment to operate with. If the CTO tries to expand ACG scope to include operational and product judgment, the ACG is no longer a technical governance body — and it is also not structurally capable of making judgments that require operational or product accountability. The CTO who takes on this expansion is taking accountability for outcomes the CTO cannot own. This is the category error Chapter 32 and Chapter 33 repeatedly warn against: engineering defining operations is a failure mode; engineering defining product quality is the same failure mode. The CTO's scope is infrastructure. Expanding beyond it to compensate for coherence failure produces a different failure mode, not a resolution.

Automated escalation does not produce a recipient. Technical escalation delivers a signal to a named recipient. When coherence is inadequate, the recipient is ambiguous — the pattern belongs to no one, and automated signals go to a distribution list rather than a person. What automated escalation cannot produce is the named accountability that turns a signal into an action. That comes from executive design, which is the CEO's instrument, not the CTO's.

The CTO who tries to compensate ends up accountable for what they cannot control. This is the practical consequence. A CTO who builds around the absence of coherence ends up with infrastructure complexity that reflects organizational incoherence, operational outcomes that the CTO is partially blamed for, and an expanded scope that the CTO does not have the authority to execute. The resolution is not more CTO effort. The resolution is accurate escalation to the CEO — the only role structurally positioned to address the failure.

FIGURE 1 — The Executive Coherence Map: What the CTO Must Expect the CEO to Hold
↔︎ CEO ACCOUNTABILITY — COHERENCE ACROSS ALL THREE DOMAINS ↔︎ The CEO is the only role that can see all three domains at once — and therefore the only role the CTO can escalate to when coherence fails.
OPERATIONAL EXECUTION Governed by: COO	PRODUCT EXECUTION Governed by: CPO	GOVERNANCE INFRASTRUCTURE Built by: CTO (through ACG)
What the CTO must expect the CEO to hold: • Is the COO resourced for Zone 2 governance? • Is operational governance structurally adequate? • Are SLAs being met as the operational surface extends?	What the CTO must expect the CEO to hold: • Is the CPO resourced for production behavior governance? • Is product governance staffed beyond feature delivery? • Are segment-level product signals being acted on?	What the CTO owns directly: • Governance infrastructure adequacy (the CTO's accountability) • ACG outputs that serve both operational and product governance • Translation of CTO scope into CEO-legible language
THE INTERFACES — WHERE THE CTO DEPENDS ON CEO-LEVEL COHERENCE The CTO cannot compensate for a CEO who does not govern these — escalation must occur when their health is visibly degrading
CTO ↔︎ COO Operational executors When the COO is not engaging with the ACG interface — not approving authority grants, not holding recalibration cadences — the CTO cannot compensate. Escalate.	CTO ↔︎ CPO Product executors When the CPO is not specifying product requirements into the ACG — when product ownership still ends at deploy — the CTO cannot build governance for decisions the CPO has not made. Escalate.	COO ↔︎ CPO Overlap systems When overlap systems have no named owner per attribute — when each assumes the other is governing — the CTO's ACG is producing outputs no one operates. Escalate.
The CTO is the executive most dependent on CEO-level coherence — and the least able to compensate for its absence. The ACG produces outputs that require the COO and CPO to engage. Without CEO-level coherence governance, their engagement is not guaranteed — and the CTO cannot force it.

Figure 1: The Executive Coherence Map, read as the CTO's model of CEO-level responsibility. The amber band across the top names the CEO's accountability and its implication for the CTO: coherence is the CEO's domain, and therefore the domain to which the CTO escalates when it fails. The three domain columns show, for operational and product execution, what the CTO must expect the CEO to hold — and for governance infrastructure, what the CTO owns directly. The interface row shows where the CTO's dependency on CEO-level coherence is most acute: at each interface, the CTO cannot compensate for executive misalignment, and the signals of misalignment are CTO-visible. The closing principle names the core reason this chapter exists: the CTO is the most dependent executive, and the least able to compensate.

WHAT THE CTO CAN EXPECT FROM A CEO WHO IS GOVERNING COHERENCE

The CTO is dependent on CEO-level coherence, but coherence is not monolithic — it is produced by specific CEO instruments. When those instruments are in place, the CTO can recognize their presence. When they are absent, the CTO can name precisely what is missing. The three instruments the CTO can expect are composition, cadence, and visibility.

Composition — who is in the roles. The CTO can expect the CEO to be accountable for whether the COO and CPO are capable of doing what their domains require in a hybrid organization. A COO whose operational governance experience is entirely on human-executed work. A CPO whose product model ends at deploy. Each of these is a composition failure that the CTO, alone, cannot fix. The CTO's infrastructure is adequate only when the executives operating within it are capable of doing so. When the CTO observes a peer executive who is structurally unequipped for their role in the hybrid model, the CTO's responsibility is to name this accurately to the CEO — not as a personal assessment of a peer, but as a structural observation about the executive team's collective capability.

Cadence — how the executives interact. The CTO can expect the CEO to design cadences that surface cross-domain issues, not only within-domain performance. Weekly leadership meetings reviewing each executive's domain. Quarterly reviews of strategic progress. These are necessary but insufficient. Coherence governance requires interface-specific cadences: scheduled reviews of the health of CTO↔COO, CTO↔CPO, and COO↔CPO interfaces. When these cadences are absent, the CTO will observe cross-domain issues surfacing only as domain-level symptoms — which is late. The CTO's escalation is not "we need more meetings" — it is "the cadence structure does not include a forum in which cross-domain issues surface in time to address them, and the CTO is the executive most affected by this gap."

Visibility — what the CEO sees. The CTO can expect the CEO to require visibility into governance adequacy across the three domains, not only into operational and product performance. Is the CTO's governance infrastructure adequate for what it is governing? Are the COO and CPO engaging with it? Are the interfaces functioning? When this visibility is not required by the CEO, the CTO will observe that CEO-level decisions about the governance model are being made without the information that should inform them. The CTO's engagement with the CEO must include specifying what visibility the CEO needs — not because the CTO is responsible for the CEO's dashboard, but because the CTO's infrastructure adequacy is a function of CEO-level decisions, and those decisions require visibility the CEO may not have explicitly required.

WHAT THE CTO MUST ESCALATE, AND AT WHAT LEVEL

The CTO's escalation to the CEO is disciplined, not reflexive. Not every cross-functional friction is a coherence failure. Not every delayed authority grant is a CEO-level issue. The CTO must escalate at the right level of abstraction — specifically enough to be actionable, structurally enough to avoid miscategorizing coherence issues as within-domain issues.

Escalate when the pattern is structural, not episodic. A single authority grant stalled in review is not a coherence issue. A pattern of authority grants stalled in review, across multiple executors, over multiple months, with no change in response to prior escalations to the COO, is a composition or cadence failure that the CTO cannot fix within the CTO role. The distinction is whether the CTO's escalation to the peer executive has produced correction. If it has, the issue was within-domain. If it has not, the issue is structural and the CEO is the next level of escalation.

Escalate in the language of coherence, not the language of infrastructure. The CTO's instinct is to describe issues in infrastructure terms. This is inappropriate for coherence escalation. The CEO does not care that ACG throughput is below target. The CEO cares whether the governance model is adequate for what the organization is executing. The CTO's escalation must translate infrastructure signals into coherence consequences: "the governance infrastructure is producing outputs that are not being operated, which means the organization is producing outcomes we cannot govern, which is a coherence failure." This is the kind of escalation Chapter 35 addresses in depth.

Escalate with named instruments, not with general concern. General concern — "something is wrong with the executive team" — is not actionable at the CEO level. Named instruments are: "the cadence structure does not include an interfaces review, and the coherence failures we are observing are the kind that only an interfaces review would surface in time." The CEO can act on a named instrument. The CEO cannot act on a general concern.

The model defines what must be true. The following defines how the CTO engages when it is not.

HOW THE CTO ENGAGES WHEN CEO-LEVEL COHERENCE GOVERNANCE IS ABSENT

The chapter so far has established what CEO-level coherence governance looks like and what the CTO observes when it is present or absent. The CTO now needs a practical pattern for engaging with a CEO who has not yet established coherence governance — a pattern that derives from the structural realities the chapter has described, not from general advice about executive influence. Every pattern below traces to a specific structural element: a named CEO instrument that is underweight, a named coherence-failure pattern that is being misread as a within-domain issue, or a named escalation boundary that is not being held. No pattern relies on persuasion, personality, or trust-building. Unlike the peer engagements in Chapters 32 and 33, this engagement has no further escalation point above the CEO within the organization; when the engagement limit is reached, the question becomes whether the CTO's infrastructure can produce value in the conditions that prevail, which is a different kind of decision.

How the CTO opens the engagement

Structural condition. The CEO's current mental model of organization design is calibrated for reporting structure — who reports to whom, how functions divide, where accountability sits on the org chart. The CEO has not yet encountered the execution-surface-beyond-the-org-chart distinction as a structural feature of their own role. Opening the engagement with a framing that assumes this distinction is already understood will produce a reporting-structure response — which misses the ground the CTO is trying to establish.

Observable gap. The CEO describes organizational performance in terms of executive domains and reporting accountability — "the COO is running operations well," "the CPO has product under control," "the team is performing." The CEO does not yet distinguish between within-domain performance and coherence across domains. The CEO's response to cross-domain issues is either "whose domain is this" or "let's get the executives in a room," both of which treat coherence as a by-product of individual executive work rather than a specific CEO responsibility.

Engagement response. Open the engagement by making the execution surface visible using the organization's own recent failure or near-failure. Not a presentation of the coherence model. A specific observation: "For the NPS decline last quarter — each executive's domain reported healthy metrics. The CPO's product metrics held. The COO's operations metrics held. My infrastructure held. And yet the organization produced an outcome none of our within-domain views showed. The question is not whose domain failed. The question is what structure, above our domains, was supposed to have caught this — and did not." The CEO's response is typically a pause, followed by some version of "so what structure are you proposing." The conversation is now inside the coherence model without having named it abstractly. The entry point is always a specific cross-domain failure the CEO has already seen, not the general principle of coherence governance. The general principle enters only after the CEO has acknowledged that the organization produced an outcome the existing structure was not designed to govern.

How the CTO recognizes what kind of CEO they are engaging

Structural condition. Unlike a peer executive who is either developing the hybrid model or not, a CEO's disposition toward coherence governance falls into three recognizable patterns — each of which implies a different engagement approach and a different ceiling for what the CTO can produce through engagement.

Observable gap. Three patterns recur. (1) Coherence-aware but unpracticed: the CEO recognizes coherence as a real dimension but has not installed the instruments (composition, cadence, visibility) because the pre-hybrid operating model has been working well enough to avoid the question. (2) Coherence-blind: the CEO does not distinguish coherence governance from executive management. The model of organization is the org chart, and cross-domain failures are assigned to the domain where the symptom appeared. (3) Coherence-resistant: the CEO recognizes the distinction but treats coherence governance as a CTO concern or an emerging problem that can be delegated. The ceiling on CTO influence is highest with (1), intermediate with (2), and lowest with (3).

Engagement response. For (1), the CEO is ready; the engagement moves directly to the specific instruments — role definitions, interfaces review cadence, governance-health visibility. The CEO's acceptance of the model means the tools close the gap without further persuasion. For (2), the CEO needs the coherence/management distinction made visible through repeated demonstration — the CTO walks the CEO through one cross-domain failure at a time, each time showing how the diagnosis the CEO initially proposed (a within-domain cause) would not have produced the necessary correction. This is patient structural work, measured in quarters, not weeks. For (3), the CTO's engagement has a hard ceiling. Coherence governance cannot be delegated to the CTO by a CEO who does not hold it; the structural role is CEO-only. When engagement is not producing movement with a coherence-resistant CEO, the CTO's responsibility shifts — not to escalate to a level above the CEO, but to recognize that the CTO's governance infrastructure is being deployed in conditions that limit its value, and to make decisions about the CTO's own role in that context.

How the CTO handles the hardest pushbacks

Structural condition. The CEO's pushbacks to the coherence governance model are predictable because they derive from the specific pre-hybrid instincts the chapter has named — the reporting-structure reflex, the individual-executive-accountability reflex, the execution-as-delegation assumption. Each pushback has a structural response that returns to ground the chapter has already established.

Observable gap. Three pushbacks occur most frequently. First: "Isn't this just a reporting-structure issue? If the problem is at the interface between the COO and CPO, maybe we need to reorganize." Second: "The COO and CPO are experienced executives. If there's a coordination problem, I'll tell them to work it out. That's what they get paid for." Third: "I appreciate this analysis, but I need the executives to own their domains. I can't micromanage every interface."

Engagement response. Pushback one proposes a structural response at the wrong level. The response: "Reorganization can resolve some coordination problems. It cannot resolve this one, because the interface is not between two functions that should be merged — the COO and CPO govern different kinds of accountability and cannot be combined without losing the specialization each requires. What needs to change is not the reporting structure, which is correct. What needs to change is the coherence-governance structure, which does not currently exist as a named instrument." Pushback two conflates peer coordination with structural coherence. The response: "Peer coordination produces within-domain correction. It does not produce cross-domain coherence, because no peer is accountable for what happens between them. If the CEO is not holding the interfaces, the interfaces are not held — and the failures we're seeing are the predictable consequence." Pushback three conflates coherence governance with operational micromanagement. The response: "Coherence governance is not micromanagement. It is the CEO's instrument for ensuring the organization is capable of governing what it executes — which is a structural responsibility, not an operational one. Three specific instruments (composition, cadence, visibility) let the CEO exercise this responsibility without touching within-domain work. I am proposing the instruments, not expanded CEO involvement in any domain." In each case, the response returns to a structural distinction the chapter has already established. The CTO is not arguing. The CTO is naming the ground the pushback depends on.

How the CTO calibrates the engagement over time

The CEO's development follows structural milestones, not executive relationship quality.

Structural condition. The CEO's development from pre-hybrid organization design to coherence governance is not a single conversation. It is a progression through specific structural milestones, each of which installs one of the CEO's three instruments. The CTO's engagement must be calibrated to where the CEO is in that progression — accelerating it is possible, skipping it is not.

Observable gap. The progression moves through four stages. Early stage: the CEO recognizes coherence as a distinct dimension of organization design, separate from reporting structure (conceptual acceptance). Intermediate stage: the CEO installs one or two of the three instruments — typically visibility first (adding governance-health signals to their dashboard) or cadence (introducing an interfaces review). Advanced stage: the CEO exercises all three instruments actively, with role definitions updated for interface responsibilities, cadence designed around coherence questions, and visibility that includes structural health. Mature stage: the CEO holds coherence as a standing dimension of organization design — every executive hiring decision includes coherence criteria, every operating-model change considers interface effects, every strategic shift is accompanied by a coherence-adequacy review.

Engagement response. At the early stage, the CTO's engagement is to make coherence visible as a distinct dimension through repeated demonstration — one specific cross-domain failure at a time, each showing why within-domain responses are insufficient. Signal of completion: the CEO begins asking coherence questions unprompted — "what interface does this failure sit on?" rather than "whose domain is this?" At the intermediate stage, the engagement is to propose specific instrument installation, sequenced by what the CEO is ready to act on. Signal of completion: the CEO has installed at least one instrument and is using it in standing executive practice. At the advanced stage, the engagement is to connect the instruments to each other — the interfaces cadence informs what visibility is needed, the role definitions reflect the visibility gaps the cadence has surfaced. Signal of completion: the CEO exercises the three instruments as a coordinated system rather than as isolated practices. At the mature stage, the engagement is largely complete; the CTO maintains the interface with the CEO but no longer drives the governance. Signal of completion: the CEO holds coherence governance standing — without the CTO prompting or structural crisis. The stages cannot be skipped because each depends on the prior one being internalized. Progress is measured by the signal of completion being observed, not by time elapsed.

How the CTO recognizes when the limit of structural engagement has been reached

Structural condition. Unlike peer engagement, which can escalate to the CEO when the structural barrier is not at the peer level, CEO engagement has no further escalation point within the organization. When the CTO's engagement with the CEO has not produced coherence governance and the signals indicate it will not, the CTO's responsibility shifts from engagement to decision. The decision is not about the CEO. It is about the CTO's own role in conditions where coherence governance will not be established.

Observable gap. Three signals indicate that engagement is no longer operating at the CEO level productively. First: the CEO has encountered multiple clearly-framed coherence demonstrations and has consistently re-diagnosed them as within-domain issues, with pushbacks that do not change in character even when the structural responses have been provided. Second: the CEO has installed no instruments over an extended period, despite repeated specific proposals with specific cases. Third: the CTO's infrastructure is producing governance outputs that are systematically not operated, and the CEO does not recognize the under-operation as a structural issue requiring attention.

Engagement response. When these signals are present, the CTO's options narrow and become more consequential. There is no internal escalation path; the board is not an operational coherence forum and should not be treated as one except in circumstances of organizational failure that exceed coherence questions. The CTO's options are: to continue building infrastructure with the understanding that some portion of it will remain unoperated, and to size the infrastructure investment accordingly; to scope the CTO role narrower, focusing on the domains where the CTO can produce value without requiring coherence governance; or to recognize that the CTO's continued tenure may not be the right outcome for the organization or for the CTO. These are decisions the CTO makes, not escalations. The chapter's purpose is not to prescribe which decision is correct, but to name clearly that the limit exists and that recognizing it is a CTO responsibility. Continuing to push coherence engagement on a CEO who will not hold it is how CTOs produce infrastructure that operates far below its potential value while taking on scope expansion they cannot execute within the role.

How the CTO recognizes success in this executive

Structural condition. Success in the engagement is not a relationship state. It is specific, observable behaviors that indicate the CEO is now exercising coherence governance in their own practice — not because the CTO is prompting them, but because the instruments have been installed and the model has been internalized.

Observable gap. When the engagement has not yet succeeded, the CEO responds to coherence failures when the CTO surfaces them, acknowledges cross-domain issues when they are explicitly framed, supports instrument proposals when the CTO makes them. All correct. All reactive. All dependent on the CTO to initiate the coherence activity.

Engagement response. Success is observable in five specific behaviors, any three of which indicate the engagement has produced the intended outcome. (1) The CEO asks coherence-framed questions about organizational issues unprompted — "what interface is this sitting on" rather than "whose domain is this." (2) The CEO has installed at least two of the three instruments (composition criteria, interfaces cadence, governance-health visibility) as standing practice, and uses them without CTO initiation. (3) The CEO includes coherence criteria explicitly in executive hiring and role-definition decisions — not only within-domain qualifications but interface capability. (4) The CEO distinguishes coherence failures from within-domain failures accurately in post-incident discussions — the individual-executive-accountability reflex no longer defaults to naming a single executive for a cross-domain outcome. (5) The CEO initiates coherence reviews during strategic shifts or organizational changes, without the CTO having to flag the need. When three or more of these behaviors are present, the engagement has produced the structural outcome. The CTO's role shifts from active engagement to interface maintenance at the CEO level — the same shift Chapters 32 and 33 described at the peer level, now completed at the apex.