Transform!

Contents

• Part 01 · The Problem and the Setup
  01What's the Problem Here?
  02Who Needs a Survival Guide?
  03How Do We Solve It?
  04When It All Goes Wrong
  05The Common Pitfalls and How to Avoid Them
• Part 02 · The 14 Behaviours
  06The 14 Behaviours Behind Successful TLT
  07A Project Comparison
• Part 03 · Planning, Risk, and Delivery
  08What's the Plan, Stan?
  09Have You Assessed the Risks?
  10Cybersecurity and Data Integrity
  11Optimising for Different Parameters
  12Programme Governance and Project Management
• Part 04 · Structure, Measurement, and the Gen-AI Era
  13Organisational and Team Structures
  14Not So Minor Details
  15What to Measure and What Not to Measure
  16Gen-AI-Enabled Change and the Rise
  17Enter the Machines

What's the Problem Here?

Opens with the stark economics of technology-led transformation: only a small fraction of large programmes meet their objectives, and billions are wasted every year. The authors argue transformation is fundamentally a human and creative endeavour that has been misframed as a purely technical one — and that misframing is the root cause of failure.

The Transformation Failure Rate

Most enterprise tech programmes miss their original objectives. The gap between ambition and outcome is the problem the book exists to close — and the authors treat it as a pattern, not bad luck. Recurring failure across decades and sectors is evidence the cause is structural, not situational.

Technology-Led Transformation (TLT)

TLT is the authors' label for large, tech-driven organisational change — broader than "IT project," narrower than "strategy." Naming it matters because most failures come from leaders applying project-management instincts to something that is actually a portfolio-level change programme.

Wasted Spend

Failed transformation isn't a missed opportunity — it's a recurring multi-billion-dollar drain on enterprise budgets. The book uses the size of the waste as moral pressure: doing nothing about the failure pattern is itself a leadership choice with a measurable cost.

Legacy as Gravity

Existing systems, processes, and skills create inertia that pulls every new initiative back toward the status quo. Leaders who underestimate this gravity ship plans that look sound on paper but cannot escape the orbit of the current operating model.

Human-Intensive Work

Transformation succeeds or fails on people decisions — priorities, skills, attitudes — not on the technology choices themselves. The tech is the easier half; deciding who does what and stops doing what is the hard half.

The Gen-AI Accelerant

Generative AI raises both the upside (faster modernisation) and the downside (faster, larger failures) of the transformation problem. AI doesn't change the failure modes — it compresses the timeline on which they play out.

TLT

Technology-Led Transformation; large-scale change where technology modernisation is the primary lever.

Legacy system

An older platform still critical to operations but expensive and risky to change.

Transformation objective

The measurable business outcome a programme is funded to achieve, not the technology output it produces.

Programme

A coordinated portfolio of projects pursuing a shared transformation objective.

Modernisation

Replacing or re-platforming legacy capability so the business can move at current market speed.

Gen AI

Generative AI; the book treats it as a force multiplier for the 14 behaviours, not a standalone solution.

Sunk cost

Money already spent that should not influence whether to continue a failing programme.

Multiple choice

According to the authors, what is the root cause of the transformation failure pattern?

• AInsufficient technology investment relative to scope
• BMisframing transformation as a technical problem when it is fundamentally a human and creative one
• CVendor lock-in to incumbent platforms
• DLack of regulatory clarity around emerging tech

Multiple choice

What distinguishes a transformation objective from a transformation output?

• AAn objective is measured in quarters; an output is measured in sprints
• BAn objective belongs to the sponsor; an output belongs to the delivery team
• CAn objective is the measurable business result; an output is the thing produced
• DAn objective is qualitative; an output is quantitative

True / False

According to the book, Gen AI introduces fundamentally new transformation failure modes that didn't exist before.

• TrueTrue
• FalseFalse

Spot the issue

A CIO presents the board: "We've committed £40m so far. Cancelling now would waste that investment, so we should push through the final phase." What's the leadership flaw?

• AThe CIO should have escalated to the CEO instead of the board
• B£40m is below the threshold that requires board approval to cancel
• CSunk cost is being used as a reason to continue a programme that may already have failed on its merits
• DThe CIO is using "we" instead of taking personal accountability

Who Needs a Survival Guide?

Defines the audience: senior executives, sponsors, CIOs, CTOs, programme leads, and board members responsible for technology-led change. The argument is that everyone in the leadership chain — not just the technologists — needs a shared survival vocabulary, because transformation fails most often at the seams between roles.

Shared Executive Language

Sponsors, delivery leads, and operators must use the same words for the same things. Mis-coordination at the seams between roles is where most large-programme failures originate — the book treats vocabulary as a load-bearing tool, not decoration.

Sponsorship as a Job, Not a Title

A sponsor's role is active risk-bearing and decision-making, not ceremonial approval. Programmes with absentee sponsors fail in predictable ways because nobody is authorised to make the trade-offs the delivery team cannot make alone.

The Accountability Gap

Failures cluster where accountability is ambiguous between business and technology leadership. The chapter argues for explicit, documented split of accountability — RACI is a tool, not a ritual.

Generalist Literacy

Non-technical executives need enough technical literacy to challenge plans, not just receive status updates. Boards that ask sharp technical questions catch problems earlier than boards that only review RAG dashboards.

The Board's Role

Boards must ask sharper questions about transformation programmes than they typically do about steady-state operations. Transformation is high-variance work; steady-state oversight rituals don't surface the right risks.

Survival Framing

The book deliberately frames TLT as a hostile environment — most attempts die — so leaders read it with the right level of caution. The framing is a deliberate counter to glossy industry narratives.

Sponsor

The senior executive accountable for a programme's outcomes and empowered to make trade-offs.

Steering committee

The governance forum where sponsors, delivery leads, and business owners make joint decisions.

CIO / CTO

Chief Information Officer (runs IT) and Chief Technology Officer (sets technology direction); the split matters in transformation.

Programme lead

The day-to-day owner of delivery across multiple projects.

RACI

Responsible, Accountable, Consulted, Informed — a tool for closing the accountability gap.

Operating model

How the organisation is structured to run the business once transformation is "done."

Stakeholder

Anyone with a legitimate interest in or influence over the outcome.

Multiple choice

Where do transformation failures most often originate, according to Chapter 2?

• AInside the delivery team's day-to-day execution
• BIn the vendor's technical capability
• CAt the seams between leadership roles where accountability is ambiguous
• DIn the regulatory environment

Multiple choice

The book defines a programme sponsor primarily as someone who:

• ASigns off on the budget at kickoff
• BActively bears risk and makes trade-off decisions throughout the programme
• CRepresents the programme to the board on a monthly basis
• DApproves vendor contracts above a threshold

Spot the issue

A board member says: "I'm not technical, so I just take the CIO's word on the delivery plan. My job is to oversee finance and strategy." What's the leadership flaw?

• ABoards have no role in transformation programmes at all
• BThe board member should have hired an external auditor instead
• CGeneralist literacy means non-technical board members must be able to challenge transformation plans, not just defer
• DThe CIO should not be reporting to the board directly

True / False

According to the book, transformation programmes can be governed with the same oversight rhythms used for steady-state operations.

• TrueTrue
• FalseFalse

How Do We Solve It?

Previews the book's thesis: failure is not random and not inevitable, but is driven by repeatable patterns that can be countered by 14 specific leadership behaviours, refined over two decades of consulting work. This chapter sets up the rest of the book and explains how Gen AI amplifies both the behaviours and the underlying patterns.

Behaviour Over Framework

Methodologies (Agile, Waterfall, SAFe) are necessary but insufficient; how leaders behave inside any framework is what predicts success. Two teams running identical Agile ceremonies can produce wildly different outcomes — the difference is behavioural, not procedural.

Two-Decade Evidence Base

The 14 behaviours are claimed as empirically derived from the authors' consulting engagements, not invented top-down. The book leans on this provenance to argue the framework describes what successful teams actually do, not what management theory says they should.

Behaviour Clusters

The 14 behaviours group loosely into framing, executing, communicating, and risk-managing — preview of Chapter 6. Thinking in clusters helps leaders diagnose where their team is weakest without judging behaviours individually.

Gen AI as Amplifier

Used well, Gen AI compresses time on every behaviour; used badly, it scales bad behaviours faster. The amplifier framing is the book's recurring lens for the AI era — neither boosterish nor doom-mongering.

From Ambition to Outcome

The book's promise is a path from intent to measurable outcomes, not just activity. Many programmes are busy without producing outcomes; the 14 behaviours are designed to close that gap.

Why Behaviours Are Teachable

Behaviours are observable, modellable, and coachable, which is what makes them a viable lever for senior leaders. Values and attitudes resist direct intervention; behaviours can be demonstrated, practised, and reinforced.

Behaviour

An observable, repeatable leadership action — distinct from a value, attitude, or framework.

Framework

A structured method (e.g. Agile, Scrum, SAFe) for organising delivery work.

Inspect and adapt

Agile-derived discipline of regularly examining outcomes and changing approach in response.

Outcome vs. output

Outcome = business result; output = thing produced. The book obsesses over the difference.

Continuous improvement

Small, ongoing changes compounding over time rather than rare, large overhauls.

Amplification

Gen AI making each behaviour faster, broader, or sharper — for better or worse.

High-performance culture

An environment where the 14 behaviours are the default, not the exception.

Multiple choice

Why do the authors argue behaviour is a more useful lever than framework for fixing transformation?

• ABehaviours are cheaper to implement than frameworks
• BBehaviours predict outcomes across any framework, because two teams running the same framework can produce wildly different results
• CFrameworks are proprietary and behaviours are open
• DBehaviours don't require executive sponsorship

Multiple choice

The authors describe Gen AI as an amplifier of behaviour. What's the practical implication?

• ATeams with weak behaviours should adopt Gen AI urgently to compensate
• BGen AI is neutral — the same behaviour produces the same outcome with or without it
• CTeams should master the 14 behaviours before scaling Gen AI, because AI scales bad behaviours as fast as good ones
• DGen AI replaces three of the 14 behaviours entirely

True / False

The book argues that values and attitudes are easier to change in adults than behaviours are.

• TrueTrue
• FalseFalse

Spot the issue

A team runs every Scrum ceremony to the letter — daily stand-ups, sprint reviews, retrospectives. Velocity is flat and customer outcomes haven't moved in six months. What's the most likely diagnosis according to Chapter 3?

• AThe team needs to switch to SAFe
• BThe framework is being run mechanically without the underlying behaviours (honest inspection, willingness to adapt, outcome focus) that make it work
• CThe team isn't running enough ceremonies
• DThe product owner needs more training in Scrum

When It All Goes Wrong

A case-study chapter that examines high-profile transformation disasters to make the failure modes concrete. The authors use cases including the UK Post Office Horizon scandal, faulty air traffic control modernisations, and other public failures to show that the same patterns recur regardless of sector.

Pattern Recognition from Disaster

Catastrophic failures expose the underlying patterns more clearly than partial ones do. The book uses disasters not for shock value but because the cause-and-effect is finally visible — survivors of partial failures usually rationalise what happened.

The Horizon Case

The UK Post Office Horizon accounting system is used as an extended example of how unchallenged technology, weak governance, and cultural blindness combine to cause real human harm. The case is recurring because each behaviour in the book is visible in its absence.

Cultural Collusion

Failures are rarely a single bad decision; they're sustained by a culture that suppresses bad news. The book frames culture as something that decides at scale, not a soft afterthought.

Escalation Suppression

Bad news travels slowly upward in failing programmes. The book treats this as a leadership behaviour problem, not a process problem — escalation paths exist on paper but are punishing to use in practice.

Compounding Risk

Small unaddressed issues compound into existential ones — the opposite of continuous improvement. In healthy programmes, problems shrink over time; in failing ones, they grow.

Lessons Rarely Learned

The same patterns recur across decades, which the book treats as evidence that fixes must be behavioural, not procedural. New process layers on top of unchanged behaviour produce the same failures in fresh packaging.

Horizon

UK Post Office accounting-system scandal in which faulty software led to the wrongful prosecution of sub-postmasters.

Failure mode

A specific way a programme breaks down — distinct from "the project failed."

Root cause

The underlying reason for a failure, usually behavioural or cultural, not technical.

Escalation path

The defined route by which a delivery risk reaches a decision-maker.

Governance

The structures and rituals that make decisions visible, traceable, and reversible.

Risk register

A living document tracking identified risks, their likelihood, impact, and owner.

Post-mortem

A structured review after failure (or success) aimed at identifying transferable lessons.

Multiple choice

Why does the book lean heavily on the Post Office Horizon case study?

• ABecause it's the most expensive transformation failure ever recorded
• BBecause the absence of multiple behaviours from the 14 is visible in one well-documented case
• CBecause the technology itself was uniquely flawed
• DBecause UK readers are most familiar with it

True / False

According to the book, most transformation disasters trace back to a single catastrophic decision.

• TrueTrue
• FalseFalse

Multiple choice

The chapter argues that escalation suppression is primarily a:

• AProcess problem solvable by better tooling
• BCompliance problem solvable by audit
• CLeadership behaviour problem — escalation paths exist on paper but are punishing to use in practice
• DResourcing problem caused by understaffed risk teams

Spot the issue

A programme's risk register lists 30 items, all marked "green," month after month. Delivery is two quarters behind schedule. What's the likely failure mode?

• AThe risk register tool is misconfigured and isn't surfacing amber/red inputs
• BRisk owners are applying overly strict criteria, so real risks aren't crossing the threshold to amber
• CEscalation suppression — the culture is rewarding "everything's fine" reporting and punishing honest amber/red signals
• DSchedule slippage is unrelated to the risks on the register, so the all-green status is accurate

The Common Pitfalls and How to Avoid Them

Catalogues the recurring traps the authors have seen across two decades of consulting: scope creep, mistaking activity for outcome, sponsor disengagement, vendor over-reliance, and underinvestment in change. Each pitfall is paired with a concrete preventive practice that sets up the 14 behaviours in Chapter 6.

Scope Creep

Uncontrolled expansion of programme scope erodes outcomes by stretching delivery thin. The book treats scope discipline as a leadership behaviour, not a project-management technique — scope creeps because someone senior keeps saying yes.

Activity Theatre

Programmes generate the appearance of progress (meetings, status decks, demos) while not moving outcome metrics. The pitfall is most dangerous when activity volume is *high* because it produces the strongest illusion of momentum.

Sponsor Disengagement

Sponsors lose attention after kickoff and reappear at go-live. The book identifies the middle 60% of a programme — when sponsor attention drops but trade-offs are heaviest — as the danger zone.

Vendor Over-Reliance

Outsourcing strategic decisions to systems integrators or consultancies hollows out internal capability. The book draws a sharp line between using vendors for capacity (acceptable) and using them for judgment (dangerous).

Change Underinvestment

Transformation programmes routinely fund the build but starve the change-management work. Adoption is then blamed on "user resistance" when the real cause is underinvested onboarding, training, and incentives.

Premature Industrialisation

Building enterprise-grade platforms before the use case is validated. The book warns this is the inverse of pilot purgatory — and equally wasteful.

Preventive Practice Pairing

Each pitfall is paired with a concrete preventive practice — explicit scope contracts, outcome dashboards, sponsor cadence, vendor-judgment audits, change budgets — setting up the 14 behaviours as practical countermeasures.

Scope creep

Uncontrolled expansion of programme scope after kickoff.

Outcome dashboard

A visible, regularly updated view of the business metrics the programme is supposed to move.

Sponsor cadence

The fixed rhythm of sponsor engagement built into governance, designed to keep attention high through the middle of the programme.

Systems integrator (SI)

A consultancy that delivers large-scale tech change on behalf of a client.

Change management

The discipline of preparing people and the organisation to adopt new ways of working.

Adoption

The degree to which users actually use a new capability as intended after launch.

Pilot

A small, time-boxed test of a new capability before commitment to scale.

Multiple choice

According to the chapter, activity theatre is most dangerous when:

• AThe team is understaffed and skipping ceremonies
• BActivity volume is high, because it produces the strongest illusion of momentum
• CSponsors are absent and can't see what's happening
• DThe outcome dashboard is showing flat metrics and is being ignored

Multiple choice

The book draws a sharp line between using vendors for capacity and using them for judgment. Which is dangerous?

• ACapacity — outsourcing build work
• BJudgment — outsourcing strategic decisions about what to build and why
• CCapacity, because each outsourced FTE displaces an internal hire who could have grown into the role
• DJudgment, but only when the vendor is a systems integrator rather than a niche consultancy

True / False

The book identifies the last 20% of a programme — the run-up to go-live — as the danger zone for sponsor disengagement.

• TrueTrue
• FalseFalse

Spot the issue

A bank goes live with a new core banking platform. Six months later, 70% of staff still use the old workarounds and customer NPS is down. The build came in on time and on budget; training was a one-hour video sent the week of launch. What's the most likely cause according to Chapter 5?

• AThe new platform is technically inferior to the old one and should be rolled back
• BFront-line staff are resistant to change and need stronger performance management
• CChange-management investment was starved during build, so onboarding, training, and incentives didn't land
• DThe pilot wasn't long enough to validate the use case before industrialisation

The 14 Behaviours Behind Successful TLT

The book's central chapter: a full enumeration of the 14 leadership behaviours that the authors argue separate successful technology-led transformations from failed ones. The chapter clusters the behaviours around **framing, inspecting and adapting, communicating, optimising, and mitigating risks**, and shows how Gen AI amplifies each one.

Frame with Intent

Define outcomes, value hypotheses, and decision rights before approving spend. Plans that list features drift; plans anchored to measurable outcomes survive contact with reality. Sized-to-uncertainty: detail the next 90 days, sketch the next 6 months, leave 18 months as direction.

Inspect and Adapt Continuously

Turn "agile" from a delivery ceremony into a leadership habit. Evidence is gathered, judged honestly, and used to change course. Steering committees that review the same red items meeting after meeting are a leading indicator of failure — inspection without adaptation is theatre.

Communicate at Every Level

Translate the same strategy into five registers — board, exec, middle management, team, customer — with a predictable cadence. Comms is rhythm, not launch — and a single source of truth (canvas, roadmap) beats five competing decks.

Optimise for the Right Parameters

Watch for local maxima. A team can be a top performer on its own metrics while damaging the system; leaders must optimise the global outcome, not the team scoreboard. Gen AI makes it cheap to optimise *anything*, including the wrong things.

Mitigate Risk Deliberately

Reframe risk from compliance artefact to active leadership practice. Identify, size, and retire risks — don't just monitor them. Gen-AI introduces new categories: hallucination, prompt injection, IP leakage, model drift.

Empower the People Doing the Work

Decision rights live as close to the work as possible. Senior leaders set direction and constraints; teams choose the path. Empowerment is structural, not motivational — it's about authority, not pep talks.

Lead with Courageous Clarity

Name the hard things — the failing initiative, the underperforming vendor, the politically awkward trade-off — out loud. The book treats courageous clarity as the rarest of the 14 behaviours and the one that unlocks the others.

Use Gen AI to Amplify, Not Substitute

Across all 14 behaviours, Gen AI is a multiplier on the behaviour already present. Substituting AI for the behaviour itself (e.g., letting AI write the strategy because no one will own framing) produces faster, more confident failure.

The 14 Behaviours

The book's complete leadership framework, grouped into framing, inspecting/adapting, communicating, optimising, mitigating risks.

Value hypothesis

A testable statement linking a planned change to a measurable business outcome.

Decision right

A formally assigned authority to make a specified class of choice without further escalation.

Inspect-and-adapt loop

A repeating cycle of measurement, interpretation, and visible course-correction.

Local optimum

A point better than its neighbours but worse than a globally better alternative.

Risk retirement

Actively closing risks by experiment, spike, or mitigation — not just monitoring them.

Courageous clarity

Naming hard truths out loud despite political cost; the book's term for the keystone behaviour.

Amplifier

Gen AI's role across the 14 — multiplying whatever behaviour is already in the room.

Multiple choice

The chapter clusters the 14 behaviours into five themes. Which is the correct set?

• AHiring, firing, training, paying, promoting
• BStrategy, finance, operations, technology, people
• CPlan, build, test, deploy, monitor
• DFraming, inspecting and adapting, communicating, optimising, mitigating risks

Multiple choice

The book calls inspection without genuine adaptation:

• ACompliance
• BTheatre
• CReporting
• DStewardship

True / False

According to the book, empowerment is primarily a motivational practice — making people feel trusted and valued.

• TrueTrue
• FalseFalse

Spot the issue

A CTO announces: "We're using ChatGPT to draft our 2026 transformation strategy because the leadership team is too busy to align on it." What's the behavioural flaw?

• AThe CTO is using a general-purpose model where a fine-tuned enterprise model would draft a stronger strategy
• BThe CTO is substituting Gen AI for the framing behaviour itself; framing requires human ownership of trade-offs and decision rights
• CThe CTO failed to inspect-and-adapt — the strategy should be reviewed quarterly rather than drafted once
• DThe CTO skipped the courageous-clarity step by not naming which existing programmes the strategy will cancel

Multiple choice

Which behaviour does the book identify as the keystone — the rarest and most-unlocking of the 14?

• AOptimise for the right parameters
• BMitigate risk deliberately
• CLead with courageous clarity
• DInspect and adapt continuously

A Project Comparison

Walks through a comparative case study: two similar transformations, one successful and one not. The chapter is structured to show the 14 behaviours present in the winner and absent (or counterfeit) in the loser — making the abstract framework concrete.

Twin Cases

Two structurally similar transformations are presented side by side: similar scope, similar budget, similar industry. The only meaningful difference is the leadership behaviours, which lets the reader see the framework in action without confounders.

Behaviours Are Visible in Hindsight

The book argues that in retrospect, the 14 behaviours are obvious in successful programmes and conspicuously missing in failed ones — but they are hardest to see while you are inside the programme.

Counterfeit Behaviours

Failing programmes often perform a counterfeit version of each behaviour: status meetings that look like inspection but don't adapt, broadcasts that look like communication but don't land, risk registers that look like risk management but retire nothing. Counterfeit behaviours are more dangerous than absent ones because they create false confidence.

Compounding of Wins

In the successful case, each behaviour reinforces the others — good framing makes inspection easier, honest inspection makes communication credible, credible communication enables courageous decisions. The book calls this the transformation flywheel.

Compounding of Losses

In the failed case, weak framing produces unclear outcomes, which makes inspection ambiguous, which makes communication evasive, which prevents risk retirement. Bad behaviour compounds as fast as good behaviour.

The Diagnostic Lens

The chapter teaches a diagnostic technique: walk through the 14 behaviours for any programme you're leading or observing, and ask "is this present, absent, or counterfeit?" The honest answers reveal where to focus.

Twin cases

Two structurally matched programmes used to isolate the effect of behaviour.

Counterfeit behaviour

A surface-level imitation of a behaviour that produces no real effect — and often false confidence.

Transformation flywheel

The compounding effect of mutually reinforcing behaviours over time.

Behavioural drift

The gradual erosion of behaviours under pressure, deadlines, or staff change.

Diagnostic walk-through

Systematically assessing each of the 14 behaviours in a programme as present, absent, or counterfeit.

Confounder

A variable that complicates direct comparison; the twin-case design removes most confounders.

Retrospective clarity

The phenomenon where behaviours are obvious in hindsight but invisible in the moment.

Multiple choice

Why does the book use twin cases rather than a single deep case study?

• ATo cover more industries and broaden the book's appeal across sectors
• BPairing similar programmes with different outcomes isolates the behavioural difference from confounders
• CTo show how the same behaviours play out across different organisational sizes
• DTo let readers pick whichever case more closely matches their own situation

Multiple choice

According to Chapter 7, counterfeit behaviours are more dangerous than missing ones because:

• AThey are harder to remove once entrenched in the operating model
• BThey create false confidence — the org thinks the behaviour is happening when it isn't
• CThey cost more in time and ceremony than doing nothing at all
• DThey concentrate failure in a single workstream rather than spreading it

True / False

The book argues that the 14 behaviours are equally easy to see while inside a programme and after it ends.

• TrueTrue
• FalseFalse

Spot the issue

A programme runs weekly status meetings with full attendance. The same three RAG items have been "amber" for four months. Leadership reports the meetings as evidence of strong governance. What's the issue?

• AThe meetings are too frequent
• BThe wrong leaders are attending
• CThis is counterfeit inspection — the ritual exists but adaptation doesn't follow from it
• DAmber items should be escalated to the board immediately

What's the Plan, Stan?

Treats the transformation plan as a living artefact, not a fixed contract. The chapter prescribes outcome-anchored planning, sized to uncertainty, with explicit decision rights — and argues that Gen AI changes planning by making it cheap to generate and stress-test alternatives.

Plans Are Living Artefacts

A transformation plan is a working model of the future, not a contract to deliver against. Plans that are treated as contracts ossify; plans that are treated as models get updated as evidence arrives.

Outcome Anchoring

Every workstream in the plan ladders to a measurable business outcome. Workstreams that can't be traced to an outcome are candidates for the stop-doing list.

Horizon Sizing

Detail the near term; sketch the medium term; leave the long term as direction. False precision in the long term produces plans that look rigorous but age badly — and create unfounded sponsor confidence.

Explicit Decision Rights

The plan names, by role, who can pivot scope, who can release contingency, who can stop a workstream. Implicit decision rights mean trade-offs hit at the worst moment.

Counter-Plans

Gen AI makes it cheap to generate counter-plans — alternative sequences, alternative scopes, alternative architectures — and stress-test the chosen plan against them. The discipline is to *actually generate* counter-plans, not to anchor on the first plan.

Planning Cadence

Plans are revisited on a fixed rhythm — typically quarterly at programme level, monthly at workstream level — so updates are routine, not crisis-driven.

The Stop-Doing List

A deliberate inventory of work the programme will not pursue. Naming what's *out* is as load-bearing as naming what's *in*, because scope creep dies on a published stop-doing list.

Living plan

A plan treated as a working model that updates as evidence arrives.

Outcome anchor

A measurable business result that a workstream ladders to.

Horizon sizing

Calibrating plan detail to time-horizon uncertainty.

Decision right

Formal authority to make a class of choice without escalation.

Counter-plan

An alternative plan generated to stress-test the chosen one.

Planning cadence

The fixed rhythm at which the plan is revisited.

Stop-doing list

Deliberate inventory of work the programme will not pursue.

Multiple choice

The book argues a transformation plan should be treated as:

• AA signed contract that the delivery team must hit
• BA working model that updates as evidence arrives
• CA confidential document held by the sponsor only
• DA slide deck for the board, not for the delivery team

Multiple choice

What's the purpose of horizon sizing in the planning approach?

• ATo make plans easier for the board to read
• BTo compress all detail into the first month
• CTo avoid false precision in the long term that creates unfounded sponsor confidence
• DTo shorten overall programme duration

True / False

The book recommends generating counter-plans only when the chosen plan starts to fail.

• TrueTrue
• FalseFalse

Spot the issue

A programme plan lists 47 workstreams in detail across 18 months, with weekly milestones for each. Six months in, 30 of them have slipped and the team is firefighting. What's the planning flaw?

• AWeekly milestones are too frequent — the cadence should be monthly to give teams more room
• BThe workstreams should have been split across more delivery teams to parallelise the work
• CFalse precision in the long horizon — detail at 18 months produces unfounded confidence and brittle plans
• DThe plan lacked a signed delivery contract holding each workstream owner accountable

Have You Assessed the Risks?

Treats risk as a continuous practice woven into delivery, not a one-time gate. Risk is **generated** by transformation choices — vendor selection, architecture, sequencing — so leaders should know which risks they are creating with each decision. Gen AI introduces new categories the traditional risk register doesn't capture.

Risk as Choice

Every transformation decision creates and destroys specific risks. Naming the risks each choice generates makes trade-offs visible — and prevents the false sense that "doing nothing" is risk-free.

Risk Retirement

Risks are items to be actively closed — by experiment, spike, design change, or mitigation — not just monitored on a register. Monitoring without retirement is the risk-management equivalent of inspection theatre.

Pre-Mortem

Before committing to a plan, imagine the programme has failed and reverse-engineer the causes. The technique surfaces concerns people would self-censor in a normal review.

Blast Radius

Design systems and rollouts so that any single failure is contained to a small, recoverable scope. Blast-radius thinking turns architecture choices into risk choices.

Defence in Depth

Layered, independent controls so no single failure causes catastrophic loss. The book treats this as a behavioural pattern of "assume failure, plan recovery," not a security checklist.

Gen-AI Risk Surface

New categories the traditional register doesn't capture: model hallucination, prompt injection, training-data leakage, shadow AI use, regulatory exposure under emerging AI law.

Living Risk Register

A continuously updated list with owner, likelihood, impact, mitigation, and trigger — not a one-off launch document. The trigger condition (the specific signal that escalates the risk to active mitigation) is the load-bearing field.

Risk register

A structured log of identified risks with ownership, scoring, and mitigation plans.

Pre-mortem

A forward-looking risk technique that assumes failure and asks why.

Blast radius

The scope of damage a single fault can cause before being contained.

Defence in depth

Layered, independent controls against the same threat.

Shadow AI

Employee use of Gen-AI tools outside sanctioned governance.

Hallucination

A Gen-AI output that is fluent but factually wrong.

Prompt injection

An attack in which adversarial input manipulates an LLM into ignoring instructions or leaking data.

Trigger condition

The specific observable signal that escalates a risk from monitoring to active mitigation.

Multiple choice

What does risk retirement mean in the book's framing?

• ARemoving an old risk from the register because it's no longer relevant
• BActively closing risks by experiment, spike, design change, or mitigation
• CTransferring risk to an insurance provider
• DMarking a risk as accepted by the sponsor

Multiple choice

A pre-mortem is most useful when:

• AWrapping up a programme after success
• BBefore committing to a plan — to surface concerns people would self-censor in a normal review
• CAfter a near-miss to apportion blame
• DDuring the steering committee, as a standing agenda item

True / False

According to the book, traditional risk registers fully capture Gen-AI-specific risks.

• TrueTrue
• FalseFalse

Spot the issue

A team picks a single, large monolithic deployment for a new platform's go-live because "it's simpler than phased rollout." What's the risk flaw?

• AThe deployment plan skips a formal pre-mortem and so misses self-censored failure modes
• BSimplicity isn't a valid engineering value when a programme is under regulatory scrutiny
• CBlast radius is maximised — any single failure on go-live damages the entire user base at once
• DThe team conflated rollback complexity with rollout complexity when justifying the choice

Cybersecurity and Data Integrity

Treats security and data integrity as part of the transformation critical path, not late-stage add-ons. Migrations, AI training pipelines, and analytics all collapse if the underlying data is wrong or the perimeter is compromised — and the Gen-AI era introduces new attack surfaces every team must understand.

Security by Design

Security is built into the change from day one, not bolted on at go-live. Retro-fitting security after architecture is set is expensive, slower, and produces weaker controls.

Data Integrity as Critical Path

Migration, AI training, and analytics all collapse if the underlying data is wrong. Data-integrity work is therefore on the critical path — not a parallel data-team concern that delivery can route around.

Zero-Trust Posture

Assume no implicit trust based on network location. Every request is authenticated, authorised, and encrypted. In transformation programmes the legacy "trusted internal network" assumption is the single biggest source of avoidable breaches.

Supply-Chain Risk

A modern stack is mostly other people's code. Vendor due diligence, SBOMs, and exit plans are leadership obligations, not procurement detail.

Identity as the New Perimeter

With cloud and SaaS, identity (who is logging in, from where, with what privileges) is the new defensive boundary. Identity hygiene — least privilege, MFA, just-in-time access — is the highest-leverage security investment.

Gen-AI Data Hygiene

Training data, prompts, and outputs all carry sensitive content. Leaks happen at every boundary. The chapter argues that Gen-AI adoption without a data-handling policy is the modern equivalent of leaving customer records on a shared drive.

Cybersecurity Posture

The overall state of an organisation's defences and readiness — not a single tool or score. Posture improves through the same behaviours the rest of the book describes: framing, inspection, adaptation, communication.

Security by design

Building security into architecture choices from day one.

Data integrity

The accuracy, completeness, and trustworthiness of data over its lifecycle.

Zero trust

A security model that assumes no implicit trust based on network location.

SBOM

Software Bill of Materials; a formal inventory of components and dependencies in a piece of software.

MFA

Multi-factor authentication; requiring more than one credential to log in.

Least privilege

Granting only the minimum access needed for a role.

Just-in-time access

Granting privileged access only when needed, for a bounded duration.

Cybersecurity posture

The overall state of defences and readiness.

Multiple choice

The chapter argues data integrity is on the critical path of transformation because:

• AAuditors require it
• BMigration, AI training, and analytics all collapse if the underlying data is wrong
• CData quality is a regulatory checkbox
• DCustomers explicitly ask for it

Multiple choice

Zero trust means:

• ADon't trust your employees
• BAssume no implicit trust based on network location — every request is authenticated, authorised, and encrypted
• CRefuse all third-party integrations
• DTrust only the security team

True / False

According to the book, retro-fitting security after architecture is set is roughly as effective as building it in from day one, just more work.

• TrueTrue
• FalseFalse

Spot the issue

A team enables ChatGPT for all employees via a personal browser plugin, with no policy on what data can be pasted in. What's the data-integrity / security flaw?

• AThe model vendor hasn't signed a data-processing agreement
• BBrowser plugins lack the audit logging required for compliance
• CSensitive content (customer data, source code, strategy) is being leaked through prompts without any data-handling policy — the modern equivalent of leaving records on a shared drive
• DPersonal-account access means the company can't enforce retention

Optimising for Different Parameters

Different transformations need to optimise for different things — speed, cost, quality, risk, learning, resilience — and the trade-offs are non-trivial. The chapter argues that **naming the parameter you are optimising for** is the most under-practised discipline in transformation, because it surfaces trade-offs people would rather leave implicit.

The Optimisation Question

Before any decision, name the parameter you are optimising for. Most programme decisions are made without naming the parameter, which means the team is collectively optimising for whatever each individual silently cares about most.

Trade-off Curves

Speed, cost, quality, risk, and learning trade against each other. Push one to the wall and another usually breaks. The book recommends visualising the trade-off curve before each major decision so the loss is explicit.

Local vs. Global Optimisation

A team can be a top performer on its own metrics while damaging the system. Leaders watch the global outcome, not the team scoreboard — and willingly let local metrics degrade if global outcomes improve.

The Right Unit of Optimisation

Sometimes the right unit is a single team's throughput; more often it is end-to-end flow across teams. Choosing the wrong unit is a quiet, common error.

Vanity Metrics

Measures that look good but don't move outcomes. The book treats vanity metrics as actively dangerous, not harmless, because they consume management attention and create false confidence.

Bottleneck Theory

A system only goes as fast as its slowest constrained resource (Theory of Constraints). Optimisation effort spent anywhere else is waste — but most teams default to optimising the easiest target, not the binding one.

Gen-AI Parameter Exploration

AI is used to run "what-if" simulations over staffing, sequencing, and architecture choices, surfacing non-obvious trade-offs. The risk is that AI makes it cheap to optimise *anything*, including the wrong things — naming the parameter first is more important than ever.

Trade-off curve

A visualisation of how improvement on one parameter costs improvement on another.

Local optimum

A point better than its neighbours but worse than a globally better alternative.

Global optimum

The best outcome for the system as a whole.

Vanity metric

A measure that looks good but doesn't move outcomes.

Theory of Constraints

Goldratt's paradigm — identify the bottleneck, exploit it, subordinate everything else, elevate it, repeat.

Value stream

The end-to-end flow of work from idea to realised customer value.

Stop-doing list

A deliberate inventory of work to discontinue to free capacity for higher-leverage work.

Unit economics

The revenue and cost associated with a single unit of activity.

Multiple choice

According to the chapter, what's the most under-practised optimisation discipline?

• ABuying better tooling
• BNaming the parameter you are optimising for, so trade-offs become explicit
• CHiring more senior engineers
• DRunning more A/B tests

Multiple choice

Bottleneck theory says optimisation effort is wasted unless it targets:

• AThe most expensive team
• BThe largest team
• CThe system's binding constraint — the slowest constrained resource
• DThe most recently hired team

True / False

The book treats vanity metrics as harmless, since they at least give teams something to track.

• TrueTrue
• FalseFalse

Spot the issue

A delivery team hits 95% sprint completion and the highest velocity in the org for six consecutive quarters. Customer NPS is flat. End-to-end lead time has gone up. What's the optimisation flaw?

• AThe team should be pushed to raise velocity further
• BVelocity and sprint completion are the wrong metrics, full stop
• CThe team is at a local optimum — its scoreboard is excellent while the global outcome (customer value, end-to-end flow) is flat or worsening
• DSix quarters isn't long enough to evaluate impact

Programme Governance and Project Management

Governance and project management are leadership instruments, not bureaucratic overhead. The chapter argues that most transformation governance is **designed for the wrong question** — proving the programme is on track — when the right question is "what evidence would tell us to stop or change?"

Governance as a Leadership Tool

Governance is the structures and rituals that make decisions visible, traceable, and reversible. Done well, it is a leadership tool. Done badly, it's a defensive paper trail.

The Wrong Question

Most governance is designed to prove the programme is on track. The right question is "what evidence would tell us to stop or change?" Governance designed around the wrong question produces optimistic theatre.

Steering Committee Discipline

Steering committees that don't make decisions are status meetings in disguise. Effective committees end every session with named decisions and named owners — and revisit decisions at the next session.

Stage Gates as Decision Points

Stage gates are real decision points, not formalities. The book argues teams should genuinely stop at a gate if the evidence doesn't support continuing — and that most gate failures are sponsor-attention failures, not delivery failures.

Decision Logs

Every significant decision is logged with date, owner, evidence considered, and intended outcome. Decision logs make reversal cheaper because the original reasoning is recoverable.

Lightweight vs. Heavyweight Governance

The book argues for the lightest governance that still answers the wrong-question / right-question distinction. Heavy governance is often a symptom of low trust between sponsor and delivery, not a fix for it.

Project vs. Programme vs. Product

Projects deliver outputs; programmes coordinate projects to deliver outcomes; products evolve outcomes indefinitely. Confusing the three is a common governance failure — applying project rituals to product work is especially destructive.

Governance

Structures and rituals that make decisions visible, traceable, and reversible.

Steering committee

Senior cross-functional group that owns programme-level decisions, escalations, and trade-offs.

Stage gate

A formal decision point in a programme lifecycle.

Decision log

A timestamped record of significant decisions with owner, evidence, and intended outcome.

Project

A time-bounded effort delivering specific outputs.

Programme

A coordinated portfolio of projects pursuing shared outcomes.

Product

A persistent capability that evolves outcomes indefinitely.

Stop-the-line authority

Explicit authorisation for any team member to halt work on observing a serious issue.

Multiple choice

The book argues most transformation governance is designed for the wrong question. What's the *right* question?

• AAre we on schedule and on budget?
• BWhat evidence would tell us to stop or change?
• CIs the vendor performing?
• DIs the team happy?

Multiple choice

According to the chapter, heavy governance is often a symptom of:

• AMature engineering practices
• BStrong regulatory environments
• CLow trust between sponsor and delivery — not a fix for it
• DSuccessful prior programmes

True / False

According to the book, project, programme, and product work can all be governed with the same rituals.

• TrueTrue
• FalseFalse

Spot the issue

A stage gate review is scheduled. The sponsor is travelling and asks the programme lead to "just confirm we're on track and move forward — we can review next quarter." What's the governance flaw?

• AStage gates should be reviewed by the board, not the sponsor
• BThe sponsor is treating a real decision point as a formality, exactly the sponsor-attention failure the chapter warns about
• CStage gates are an outdated practice
• DThe sponsor should have delegated to the CIO

Organisational and Team Structures

Structure is a leadership choice, not an HR side-effect. The chapter argues that team and org-design decisions determine which behaviours are easy and which are forced — and that most transformation programmes inherit structures that actively obstruct the 14 behaviours.

Conway's Law in Reverse

Systems mirror the communication structure of the teams that build them. Inverting this — designing teams to produce the system structure you want — is a load-bearing transformation choice the book calls Inverse Conway.

Team Topologies

The book draws on the Team Topologies model: stream-aligned, enabling, complicated-subsystem, and platform teams, each with a defined interaction mode. Mismatched topologies produce coordination tax.

Cognitive Load

Every team has a finite cognitive capacity. Overloading a team — too many domains, too many integrations, too many stakeholders — degrades every behaviour, especially inspection and adaptation. Cognitive load is a design constraint, not a complaint.

Platform Teams as Leverage

Permanent internal teams whose customers are other internal teams. Reusable platforms (data, identity, ML/LLM gateway, observability) mean each new use case starts at 60% done rather than zero — a multiplier on the rest of the org.

Empowered Product Teams

Cross-functional teams with full authority over their domain — product, engineering, data, design — close decision rights to the work. Empowerment is structural: it lives in the org chart and budget, not in slogans.

Spans and Layers

Too many layers slow decisions; spans too wide overload managers. The book treats org structure as something to tune deliberately, not inherit, with the goal of minimising decision latency.

Reorgs Are Expensive

The book is sceptical of frequent reorgs — each one costs trust, momentum, and institutional knowledge. The prescription is to design well, then leave it alone until evidence demands change.

Conway's Law

Systems mirror the communication structure of the teams that build them.

Inverse Conway manoeuvre

Deliberately designing team structure to produce a desired system structure.

Team Topologies

A model of four team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes.

Cognitive load

The mental capacity a team can hold across its domains and responsibilities.

Platform team

A permanent team whose customers are other internal teams.

Empowered product team

A cross-functional team with full authority over its product domain.

Span of control

Number of direct reports per manager.

Decision latency

Elapsed time between a decision being needed and being made.

Multiple choice

Inverse Conway is the practice of:

• ALetting the existing system architecture dictate team boundaries
• BDesigning team structure deliberately to produce the system structure you want
• CCentralising all engineering into a single team to remove silos
• DOutsourcing team design to an external consultancy

Multiple choice

The book treats cognitive load as:

• AAn HR concern about burnout
• BA team-feelings issue
• CA hard design constraint — overloaded teams degrade every behaviour, especially inspection and adaptation
• DAn excuse for missing deadlines

True / False

According to the book, frequent reorgs are a low-cost way to keep an organisation fresh and aligned.

• TrueTrue
• FalseFalse

Spot the issue

A leadership team adds a new "AI Capability" group as a cross-cutting matrix that sits inside every product team but reports to the CTO. Six months later, decision latency has doubled. What's the structural flaw?

• AThe team is too small
• BThe CTO is the wrong reporting line
• CThe matrix has added layers and split decision rights, increasing coordination tax and decision latency rather than reducing it
• DAI should be outsourced

Not So Minor Details

A pragmatic catch-all chapter on the operational details that quietly determine whether a transformation lives or dies: onboarding, tooling, environments, data migration, communications channels, naming conventions. The argument is that minor details, neglected at scale, become major failures.

Onboarding as a Leverage Point

The first week shapes the next year. Programmes that invest in onboarding — for both new hires and partner staff — see faster ramp, better behaviour adoption, and lower attrition.

Environment Parity

Development, test, staging, and production environments should be as similar as feasible. Environment drift produces "works on my machine" failures that surface only in production, when the cost of fixing them is highest.

Data Migration as a Programme

Data migration is rarely a one-time event — it's an ongoing programme with its own risks, owners, and rollback plans. Underestimating it is one of the most common causes of go-live failure.

Tooling Discipline

The right tooling chain (CI/CD, observability, secrets management, documentation) compounds productivity; the wrong chain extracts a tax on every change. The book treats tool selection as a strategic decision, not a developer preference.

Communications Hygiene

Internal channels (Slack, email, intranet) accumulate signal-to-noise problems as programmes grow. Active curation — fewer channels, clearer naming, archived defunct threads — is a leadership chore that pays back.

Naming Conventions

Consistent naming — for services, environments, branches, repositories — sounds trivial until inconsistency causes a six-hour outage. The book treats naming as part of operational risk management.

Run Books and Playbooks

Pre-written response procedures for known scenarios (incidents, releases, audits) turn high-stress moments into routine ones. The behavioural payoff is that teams spend cognitive load on novel problems, not re-discovered ones.

Onboarding

The structured process of bringing new people up to productive speed.

Environment parity

The degree to which dev, test, staging, and production environments match.

Data migration

The transfer of data from one system or schema to another, usually as part of transformation.

CI/CD

Continuous Integration / Continuous Delivery; the automated pipeline from code commit to production.

Observability

The ability to understand a running system from its outputs (logs, metrics, traces).

Secrets management

The discipline of storing and rotating credentials securely.

Run book

A pre-written procedure for handling a known operational scenario.

Playbook

A broader pre-written response plan, often for incidents or change events.

Multiple choice

The chapter's central claim about minor details is that:

• AThey are usually safe to ignore in favour of the big picture
• BNeglected at scale, they become major failures
• CThey can be delegated to junior staff once strategy is set
• DThey only matter in regulated industries

Multiple choice

Environment parity matters because:

• AAuditors require identical environments by default
• BIt lowers cloud spend by eliminating redundant infrastructure
• CWithout it, "works on my machine" failures surface only in production, when the cost of fixing them is highest
• DIt removes the need for staging environments entirely

True / False

According to the book, data migration is typically a one-time event you can plan and complete in a single project phase.

• TrueTrue
• FalseFalse

Spot the issue

An ops team handles every production incident from scratch — no run books, no documented procedures. The on-call engineer says "it's faster to just figure it out each time." What's the operational flaw?

• AThe team needs more headcount
• BThe incidents are too varied to document
• CWithout run books, cognitive load is wasted on re-discovering known responses, slowing recovery and increasing operator error
• DThe on-call rotation is too short

What to Measure and What Not to Measure

Measurement is a leadership instrument: what you measure shapes what teams do. The chapter argues that most transformation programmes measure too many things, mostly the wrong ones — and that disciplined choice of metric (and disciplined refusal of others) is a behaviour in itself.

Outcome Metrics Over Output Metrics

Outcome metrics measure business effect (revenue moved, cost-to-serve, cycle time); output metrics measure things produced (features shipped, stories closed). The book obsesses over the distinction because confusing them is the easiest way to be busy without producing value.

Leading vs. Lagging Indicators

Lagging measures (quarterly revenue) confirm past results; leading measures (activation rate, time-to-value) predict future results. Programmes that only watch lagging indicators steer with a long delay.

Stop-Measuring List

A deliberate inventory of metrics the programme will *no longer* track. The book treats stopping measurement as as important as starting it, because every metric consumes attention and creates incentives.

Goodhart's Law

"When a measure becomes a target, it ceases to be a good measure." The chapter uses Goodhart as the rationale for rotating metrics, sampling rather than tracking everything, and refusing to bonus on single numbers.

Vanity vs. Actionable Metrics

Vanity metrics look good but don't move outcomes (total users, pageviews); actionable metrics drive specific decisions (weekly active users by segment, conversion at each funnel step). The test: would a different value of this metric change a decision?

Error Budgets

A pre-allocated tolerance for failure (e.g., 99.9% uptime allows ~43 minutes of downtime per month). When the budget is consumed, feature work pauses in favour of reliability. The mechanism makes reliability a *budgeted* concern, not a slogan.

Gen-AI Eval Metrics

LLM-based features need evaluation harnesses — continuously-run test suites of prompts, expected behaviours, and failure modes. Without evals, regressions ship invisibly and trust erodes.

Outcome metric

A measure of business effect.

Output metric

A measure of things produced.

Leading indicator

A measure that predicts future results.

Lagging indicator

A measure that confirms past results.

Goodhart's Law

When a measure becomes a target, it ceases to be a good measure.

Vanity metric

A metric that looks good but doesn't change decisions.

Error budget

A pre-allocated tolerance for failure that gates new feature work.

Eval harness

A continuously-run test suite for evaluating LLM behaviour against expected outputs.

Multiple choice

The test for whether a metric is actionable is:

• AWhether it has been tracked for at least 12 months
• BWhether a different value of the metric would change a decision
• CWhether it appears on the board dashboard
• DWhether the CFO endorses it

Multiple choice

Goodhart's Law says:

• AMeasurements get more accurate over time as instruments improve
• BWhen a measure becomes a target, it ceases to be a good measure
• CThe best metrics are financial
• DYou should always measure what your competitors measure

True / False

According to the book, the more metrics a programme tracks, the better its visibility into progress.

• TrueTrue
• FalseFalse

Spot the issue

A programme has hit 100% of its "stories closed" target every quarter for two years. Revenue is flat, customer churn is up. What's the measurement flaw?

• AThe team needs a larger backlog of stories per quarter
• BThe reporting period should be monthly, not quarterly
• C"Stories closed" is being treated as an outcome metric when it is an output metric; busy teams are producing no business value
• DThe team is not closing stories quickly enough relative to plan

Gen-AI-Enabled Change and the Rise

Generative AI changes the speed, surface area, and cost structure of transformation, but not the behavioural physics. The chapter examines what Gen AI **actually** changes in transformation work — and what it conspicuously doesn't — to help leaders make adoption decisions without falling for either hype or doom.

AI as Amplifier, Not Author

Across all 14 behaviours, Gen AI multiplies whatever behaviour is in the room — including the bad ones. Substituting AI for the behaviour itself (e.g., letting AI write the strategy because no one will own framing) produces faster failure.

Cost Asymmetry

Inference cost scales with usage in ways traditional software does not. A free demo can become a six-figure monthly bill at scale. FinOps discipline — model choice, prompt size, caching, routing — is now an operational behaviour, not a finance concern.

The Demo-to-Production Gap

What worked in a controlled demo rarely works in production. Production exposes long-tail inputs, latency budgets, safety requirements, and evaluation needs that demos hide. Leaders who confuse the two ship faster, more confident failures.

Evaluation as a First-Class Practice

LLM features need continuous eval harnesses — test suites of prompts, expected behaviours, and failure modes — run on every model or prompt change. Without evals, regressions ship invisibly.

Human-in-the-Loop Design

For consequential decisions, AI assists but humans decide. The design pattern names where the human enters the workflow, what they see, and what authority they have. Fully autonomous AI in consequential paths is treated as premature.

Compounding AI Advantage

Organisations that adopt AI to amplify mature behaviours compound their lead quarter by quarter. Organisations that adopt AI to substitute for missing behaviours fall behind faster than before. The gap between the two will widen.

Regulatory Horizon

Emerging AI regulation (EU AI Act, sectoral rules) is tracked early enough to shape design, not retrofitted after release. The book treats regulatory scanning as a transformation behaviour, not a legal-team concern.

Inference cost

The compute cost of running a trained AI model in production.

FinOps

A cultural and operational practice that brings financial accountability to variable cloud and AI spend.

Demo-to-production gap

The difference between a controlled demo and the failure surface of real production.

Eval harness

A continuously-run test suite for evaluating LLM behaviour.

Human-in-the-loop

A design pattern where AI assists but a human makes the consequential decision.

Model drift

Degradation in a deployed model's performance as the world changes around it.

EU AI Act

European regulation governing AI systems, with risk-tier obligations.

Routing

Sending requests to different models based on cost, capability, or risk.

Multiple choice

The book's most repeated framing of Gen AI is that it is:

• AA replacement for the strategy and framing work senior leaders should own
• BAn amplifier of whatever behaviour is already in the room — including bad ones
• CA productivity tool best confined to engineering teams
• DA regulatory hazard to be paused until laws stabilise

Multiple choice

The demo-to-production gap exists primarily because:

• ADemos run on a different underlying model from the production version
• BProduction exposes long-tail inputs, latency budgets, safety requirements, and evaluation needs that demos hide
• CProduction environments have weaker compute than the demo environment
• DDemo prompts are tuned to a narrower set of customers than production sees

True / False

According to the book, inference cost behaves like traditional software cost — high one-off investment, near-zero marginal cost per use.

• TrueTrue
• FalseFalse

Spot the issue

A team ships an LLM-powered customer-support feature. They wrote 20 test prompts during development but don't run them after release. A new model version goes live and quality drops; no one notices for three weeks. What's the practice flaw?

• AThe team should have used a different LLM
• BTest prompts should be longer
• CNo continuous evaluation harness — without evals running on every model change, regressions ship invisibly
• DCustomer support shouldn't use LLMs

Enter the Machines

The closing chapter synthesises the 14 behaviours into an operating system for transformation in the Gen-AI era. The argument: the behaviours are interdependent, AI amplifies them, and the leaders who diagnose their weakest behaviours and start there compound their advantage quarter by quarter.

The Behavioural Operating System

The 14 behaviours together form an operating system for transformation — interdependent, mutually reinforcing, and load-bearing. Framing sets direction; inspection keeps it honest; communication aligns the org; optimisation and risk management make it durable; scaling and sustainment make it permanent.

Behaviours Compound

Each behaviour reinforces the others. Good framing makes inspection easier; honest inspection makes communication credible; credible communication enables courageous decisions. The compounding is the transformation flywheel.

Diagnostic Maturity

The book's closing call: assess honestly which behaviours are weakest in your context. Diagnostic maturity — willingness to see and act on the weak spots — is the prerequisite for everything else.

Sequencing by Leverage

Pick the two or three weakest behaviours and start there this quarter. Sequencing by leverage — which behaviour, when fixed, unlocks others — beats trying to improve all 14 in parallel.

Leadership as the Rate-Limiter

Across the 14 behaviours, the binding constraint is almost always senior-leader behaviour — not tooling, budget, or talent. Leaders who recognise this commit to changing their own behaviour first.

The Compounding AI Gap

Organisations that combine mature behaviours with Gen-AI adoption widen their lead over those that don't, quarter by quarter. The book argues the gap is now too large to close by tooling alone.

Lasting Competitive Advantage

Advantage that survives the next tech cycle because it lives in behaviour, not in any single technology bet. The book's final claim is that the 14 behaviours are the durable layer — models change, behaviours persist.

Start This Quarter

The closing instruction: pick your two or three weakest behaviours and act this quarter. Diagnosis without action is theatre; the book ends with a behavioural ask, not a strategic frame.

Behavioural operating system

The interlocking, mutually-reinforcing system of the 14 behaviours.

Transformation flywheel

The compounding effect of good behaviours over time.

Diagnostic maturity

Honest assessment of which behaviours an organisation is weakest at.

Sequencing by leverage

Picking the behaviours that, when fixed, unlock others.

Rate-limiter

The binding constraint that caps overall performance.

Amplification effect

Gen AI multiplying underlying behaviour — good or bad.

Behavioural debt

The accumulated gap between behaviours an organisation claims and behaviours it rewards.

Lasting competitive advantage

Advantage rooted in behaviour, not technology choice.

Multiple choice

According to the closing chapter, the binding constraint across the 14 behaviours is almost always:

• ATooling budget
• BTalent availability
• CSenior-leader behaviour
• DRegulatory clarity

Multiple choice

The book argues that *lasting* competitive advantage in the Gen-AI era lives in:

• AThe specific foundation model an organisation contracts with
• BBehaviour, because models change but behaviours persist
• CHeadcount in the AI engineering team
• DThe size of the enterprise data lake

True / False

According to the closing chapter, the right way to close a Gen-AI capability gap is primarily by buying better tooling.

• TrueTrue
• FalseFalse

Spot the issue

A CEO reads the book and announces: "We're going to improve all 14 behaviours simultaneously starting next quarter, with a dedicated workstream for each." What's the strategic flaw?

• A14 workstreams is too few
• BThe CEO should have delegated to the CIO
• CThe book argues for sequencing by leverage — picking the two or three weakest behaviours — not parallel improvement across all 14, which dilutes attention and prevents compounding
• DThe CEO should have started with framing