Executive Summary

Software-dependent corporates govern through representations that were never designed to be tested against the system. This summary condenses the book’s thesis, the six demands a board should make before any AI investment, and why the choice between the writer path and the reader path cannot wait.

Thesis. Software-dependent corporates govern through representations that were never designed to be tested against the system: narratives that replace reality, portfolio labels with no executable boundary, architecture that advises but does not bind, processes that were never written down. These are not failures of intelligence but the structural consequence of separating “the business” from engineering, coping mechanisms whose cost structure has changed. AI makes reconciliation cheap and continuous. The gap between what the organisation says and what the system does becomes measurable, and the cost of leaving it unmeasured compounds.

Diagnosis. Products exist in portfolios but have no coherent boundary in the code. Architecture describes aspirations rather than systems. Capital attaches to labels while value is created at process boundaries that the financial model cannot observe. Coordination consumes 30–40% of technology delivery headcount. The figure varies with sector and coupling severity; financial services and telecommunications tend towards the upper end. Experienced engineers leave, taking irreplaceable process context. Regulatory exposure compounds silently until the moment it is tested. AI-assisted development decouples output rate from team size without decoupling drift risk. Boards that reduce engineering headcount on the basis of delivery velocity metrics are measuring the wrong variable.

Six demands. Before any AI investment, the board should require six items for a single critical process: a ranked process inventory, a structured process definition, a single named owner, a versioned contract inventory, a reconciliation report against the code, and a cost-to-outcome trace. The diagnostic that follows sets out each in full. If management cannot produce them for one critical process within 30 days, every AI investment builds on a foundation the organisation has never inspected.

Scope. The structural model is most applicable to software-dependent corporates above approximately two hundred people, with more than thirty services, and without a single founder who carries process ownership personally. Safety-critical industries and deeply unionised structures have contextual constraints the transition must work within rather than around. Chapter 17 addresses these boundaries directly. Partial adoption (contracts without full restructuring, process definitions without the transitional fund) produces partial benefit rather than failure.

The choice. AI can write faster narrative or read existing systems. The two paths diverge and the divergence compounds. Each quarter that an organisation operates AI as a narrative tool builds institutional dependence on the output. Switching to the reader path then requires withdrawing confidence from the narrative infrastructure the organisation has spent years constructing. The structural preconditions take years to build and cannot be purchased when the need becomes urgent. The capacity for structural honesty now exists. What remains is whether the people who govern these organisations are willing to act on it.

What a board should do in the next 30 days. Pick one critical process. Ask the CTO to name the process and its owner, then produce a structured definition: states, transitions, decision points, failure modes. Run the definition against the code and report where they diverge. Ask the CFO to trace the top three incident categories for that process to rejected or deferred structural investments. If management can produce these within 30 days, you have a starting point. If it cannot, the finding is the starting point.

...

See also: Full contents · Preview chapters · Illusions of Work