Contents

What's Inside

Chapter One

The Five Frictions & the 97% Problem

Let me start with a number that should ruin your morning coffee, gently. In the Playbook I tell the story of Margaret's billing complaint: 49 hours of elapsed time, five human handoffs, one system rejection — and roughly 45 minutes of actual productive work. That means about 97% of the workflow time was not work. It was waiting, formatting, re-entering, and approving.

Here's the factory test: if you ran a factory where 97% of the time nothing was being produced, you'd shut it down by Friday. In knowledge work, we call it "normal". A $2.3 million pricing decision that took 42 days, nine handoffs and three hours of actual work isn't an anomaly — it's how most organisations operate every day.

Why every handoff is a tax event

Every human-to-human handoff in your organisation is subject to five distinct types of friction. These aren't bugs; they're features of the architecture — inevitable consequences of information having to pass through human beings to get from one step to the next. I call them the Five Frictions, though you'll recognise their everyday names: waiting, politics, inconsistency, lost context, and coordination overhead.

1. Latency — the approval that took ninety seconds sat in a queue for four days, because the approver was human: sleeping, commuting, at an offsite in Byron Bay. At enterprise scale, latency alone accounts for 60–80% of elapsed time in approval-heavy processes. Your org chart is a latency engine.
2. Emotional friction — ego, turf wars, passive-aggression, the week-long debate about a shade of brown (true story). US companies spend an estimated $359 billion a year on workplace conflict, and none of it appears on a process map.
3. Inconsistency — same process, same policy manual, wildly different outcomes depending on who handles it.
4. Lost context — each handoff loses roughly 5% of context. The formula is 1 − (0.95)ⁿ: over five handoffs you've lost 23% of the information; over ten, 40% of it is simply gone.
5. Coordination overhead — Brooks's Law: adding people adds n(n−1)/2 communication channels. A team of ten has 45 channels; a team of fifty has 1,225.

The uncomfortable truth underneath all five: every organisational innovation of the last 150 years — the org chart, the meeting, the memo, email, Slack — optimised communication. None of them questioned whether the communication should exist at all. You've been optimising within a system that is structurally incapable of being fast.

Your Friction Fingerprint

No two organisations suffer equally across all five. Score your highest-volume workflow — the one that runs hundreds or thousands of times a year — against each friction on a 1–5 scale, and you get your Friction Fingerprint: the shape that tells you where to attack first. A latency-dominated fingerprint calls for a different intervention than an inconsistency-dominated one. (The interactive diagnostic draws the radar chart for you.)

Chapter Two

The Legacy Tax

Diagnosis is useful; a dollar figure gets you a board agenda item. The Legacy Tax is the annual cost of the friction hiding inside your workflows — and it's almost certainly larger than you think, because nobody has ever added it up.

The arithmetic of waiting

The calculation is deliberately simple. Take one workflow: how many times does it run per year? How many people touch each instance, for how long, at what loaded salary? How much elapsed time does each instance consume, and what does that delay cost in decisions deferred, customers irritated, and opportunities missed? Multiply through, and a single mid-volume workflow routinely reveals six or seven figures of annual friction cost. Project it forward with 3% salary inflation compounding and the five-year number gets properly uncomfortable.

The multiplier question

Here's the part that changes the conversation: that's one workflow. One. How many do you have? If your organisation runs fifty workflows with similar friction profiles, the total Legacy Tax isn't that number — it's fifty times that number. When executives tell me AI transformation looks expensive, my answer is always the same: compared to what? The status quo has a price tag too; it's just printed in invisible ink.

Chapter Three

The Patching Fallacy

So you've diagnosed the friction and priced it. The obvious response — the one your software vendors are queuing up to sell you — is to add AI to the existing process. Copilots for everyone. And here is the fallacy: adding AI to a broken process makes the fast parts faster — the slow parts don't change.

The $50 million lesson

One company in the Playbook spent $50 million deploying AI across every department. Marketing drafted in minutes. Legal reviewed 40% faster. But the approval chain — the latency engine — was untouched, so the cycle time barely moved. They had built the world's best engine and bolted it to a horse and cart.

The comparison case makes it sting: a patch programme costing $15M delivered roughly 15% cycle-time improvement, declining employee satisfaction and no payback at month twelve. A rebuild costing $3M delivered ~99% cycle-time improvement, happier people, and payback in seven months. Less money, radically better outcome — because it attacked the architecture instead of decorating it.

Why patching feels right and fails anyway

Patching is seductive because it's safe: no restructuring, no difficult conversations, visible activity everywhere. But Amdahl's logic is merciless — if 97% of elapsed time is waiting and politics, accelerating the 3% that is actual work cannot move the total. The gap between patchers and rebuilders compounds quarter after quarter, which is the maths behind everything in Section II.

Patch it or fork it?

Not every workflow deserves a rebuild. Four questions decide it: Is the friction structural (handoffs and approvals) rather than skill-based? Is the volume high enough to matter? Is the process rule-expressible? Would removing the human execution layer be acceptable with proper boundaries? If all four are yes — fork it. Which is precisely where we're heading next.

Chapter Four

The Organisational Fork

Kodak invented the digital camera. Nokia had smartphone prototypes years before the iPhone. Blockbuster turned down buying Netflix for $50 million. None of them lacked the technology — they tried to transform the core from within, and the core won. It always does. The immune system of a successful organisation is magnificent at killing anything that threatens this quarter's numbers.

Build the new beside the old

The alternative is the Organisational Fork: stop trying to transform the legacy business from the inside, and build the AI-native version of one workflow alongside it. Let me be precise about what that means, because the words matter:

• The Fork is not a skunkworks, an innovation lab, a "Centre of Excellence", a spin-off, or a pilot programme reporting to the old structure. Every one of those is a way of keeping the new thing safely unable to threaten the old thing.
• The Fork is real work on actual business processes, measured by the same KPIs as legacy, with its own agent-speed governance, a ring-fenced budget, and a defined absorption trajectory — it's designed to grow and take over, not to demo.

And the funding reframe that unlocks the boardroom conversation: the Fork isn't asking for new money. It's asking you to spend the same money differently.

Choosing the beachhead

You don't fork the company; you fork one workflow — the beachhead. The ideal candidate scores well on five criteria: high friction (your fingerprint from Chapter One), high volume, rule-expressible decisions, measurable outcomes, and a leader willing to own it. Resist the temptation to start with the hardest, most political workflow in the building. The beachhead's job is to exist, work, and make the second fork easier.

Chapter Five

Loop Compression & the New Roles

The Fork's engine room is the Autonomous Execution Layer — agents executing the workflow without human handoffs. But the more useful leadership lens is where the humans sit relative to the loop, because that position is what actually changes. There are three stages:

• In the loop — humans approve every action. AI drafts, summarises, recommends; a human reviews, edits, approves. This is where almost everyone is today.
• On the loop — the system executes autonomously within defined parameters. Humans watch a dashboard, not every output, and intervene on exceptions.
• Above the loop — the system runs. Humans set boundaries, define objectives, audit trajectory, and govern the governance.

Loop compression is the deliberate movement of workflows through those stages — and it's deliberate, not drift. Each step up requires evidence the system has earned it, which is exactly what Chapter Six's tests measure.

What happens to the people

This is the chapter where leaders lean forward, because the honest answer to "what about my team?" lives here. As workflows compress, new role archetypes emerge: Agent Supervisors who manage fleets of agents rather than queues of tasks; System Architects who design the workflows agents execute; Exception Handlers who deal with everything the system escalates; and Alignment Specialists who make sure the system keeps thinking the way the organisation would want it to.

In the Playbook I tell Sarah's story: 22 years in financial services, a team of twelve onboarding analysts — she literally was the training data. After the restructure to three exception handlers, her verdict on the new job: "I used to spend my days making sure the process worked. Now I spend my days making sure the system is thinking the way I would think. The first job was bigger. The second one matters more."

Chapter Six

The Five Native Tests

The singularity, as I argue in the Playbook, is granular. It doesn't arrive as a single event with a press conference — it arrives one workflow at a time. Customer onboarding might cross while strategic planning remains firmly human-directed. So the question isn't "has AI taken over?" It's "which of your workflows are already improving faster than your team can review?"

The tests

Five measurements, each targeting a different signature of autonomous self-improvement. A workflow has "crossed" — gone native — when these flip:

1. Improvement Velocity — the speed test. Autonomous optimisations per week ÷ the maximum a human review team could meaningfully assess. Ratio above 1:1? Crossed.
2. Autonomy Ratio — the simplest test. Total instances ÷ instances requiring human intervention. A 97% autonomy ratio means humans touch 3 cases in 100.
3. Exception Decay — the learning test. Exception rate per 1,000 transactions, tracked over time. A falling curve means the system is learning the edge cases faster than new ones appear.
4. Human Override Impact — the judgement test. When humans do override, does it improve outcomes? If override impact trends negative, the humans have become the error source.
5. Economic Multiplier — the CFO test. The workflow's key performance metrics, quarter on quarter, against its fully-loaded cost.

Why this matters competitively

The race isn't company against company — it's workflow against workflow. Your competitor doesn't need to beat you across the board; they need one workflow to cross before yours does. From that moment, their improvement rate on that workflow is machine-speed and yours is committee-speed, and the gap stops being closable by effort.

Chapter Seven

The EDGE Method

Everything before this chapter is conviction; this chapter is calendar. The EDGE Method is the operational core of the Playbook: four phases, sixteen weeks, one workflow at a time.

The four phases

• E — Expose (weeks 1–4): map the real workflow, not the process diagram fiction. Score the friction. Find out what actually happens, who actually decides, and where the time actually goes.
• D — Design (weeks 5–8): decompose the workflow into agent tasks, assign the human roles from Chapter Five, set the metrics and targets the Five Native Tests will measure.
• G — Go Live (weeks 9–14): run the agents in parallel with the legacy process. Track everything. Know in advance what would make you pull the plug.
• E — Evaluate (weeks 15–16): three honest outcomes. Cut over — the native version wins, legacy retires. Iterate — promising but not proven; hard limit of two iteration cycles, or you're polishing a corpse. Retreat — it didn't work, and you write down exactly why. A retreat that produces clear lessons is worth more than a cutover that succeeds by luck.

The scaling trajectory

The first workflow takes sixteen weeks. The second takes ten to twelve. The fifth takes four to six, and by the tenth you're down to two to four weeks — because the scarce asset isn't technology, it's institutional capability: people who have run the method, governance that has learned to move at agent speed, and data plumbing that's already been fixed once. This is why starting matters more than starting perfectly.

If you do nothing else from this book, run the EDGE Method once. One workflow. Sixteen weeks. Measure everything. The first cycle will be harder than this chapter makes it sound — but the second one won't. — The AI-Native Playbook, Chapter 6

Chapter Eight

Data Readiness & Governance at Speed

Two things kill EDGE cycles, and neither of them is the AI. The first is data you can't build on; the second is governance that can't keep up. Both are fixable — if you treat them as part of the build, not an afterthought.

The Data Tax

Agents are only as good as the data they process. If the data is garbage, agents produce confident, consistent, auditable garbage at machine speed. The Playbook's customer ID problem says it all: Sales used the CRM record number, Finance the billing account number, Customer Service the email address — so the agents dutifully created three customer profiles for the same human being.

Five honest questions reveal whether your beachhead workflow's data can carry the load — and "no" is the most common answer to all five. Most organisations fail their first Data Readiness Assessment, not because they're behind their peers, but because nearly everyone is behind. The fix is not a company-wide data transformation: it's a Data Sprint — a targeted four-to-eight-week intervention on one workflow's data dependencies. The insurance company in the Playbook spent roughly $180K on theirs; it prevented an estimated $2 million in agent-failure debugging. $180K feels expensive until you price the alternative.

Governance at the speed of agents

Now the harder half. A European bank's loan-approval agent network optimised approval rates by postcode — mathematically sound, ethically indefensible. It took eleven weeks to reconstruct the decision chain; the executive sponsor resigned. The chilling part: no one in the room had made the decision, and yet the organisation had. The fatal gap was Level 4 execution with Level 3 governance — a system operating faster than anyone could oversee it.

The discipline that closes the gap: stop reviewing actions; start setting boundaries. "Don't discriminate" is a value, not a boundary. "No optimisation that changes approval rates by more than 2% for any demographic segment" is a boundary — measurable, monitorable, and attached to a named owner. Add graduated kill-switches with thresholds you configure before go-live, and you have governance that protects without paralysing. If your governance can't operate at the speed of your agents, you don't have governance — you have a backlog.

Chapter Nine

The Inaction Tax & the Singularity Curve

We priced the friction in Chapter Two. Now let's price the delay. The Inaction Tax is what doing nothing costs — a compounding charge across four dimensions: the Legacy Tax you keep paying, the efficiency gap against movers, the talent you lose to organisations doing more interesting work, and the strategic options that expire while you deliberate. It doesn't send you an invoice. It compounds in silence until the board meeting where the numbers no longer work.

The two lines

Picture two lines on a chart. One is exponential: the AI-native organisation, improving at machine speed. One is flat-ish: the legacy organisation, improving at committee speed. The space between them is the competitive chasm, and the Singularity Curve question for your industry is simply: when does that gap become unbridgeable? Tipping points vary — financial services in roughly 2–3 years, insurance and legal 3–4, professional services and healthcare administration 4–6, manufacturing 4–6, government 8–12.

The three timelines

Nobody knows the pace for certain, so the Playbook reasons across three scenarios. Fast (3–5 years, 25–35% probability): you have 18–24 months before the tipping point; the window for being early has closed, but the window for being competitive is open. Medium (5–10 years, 45–55%): you have time to run EDGE three or four times and build genuine institutional capability — but not enough to spend a year on strategy without execution. Slow (10–15 years, 15–25%): even here, starters win, because compounding works in both directions — early movers compound knowledge, capability and cost advantage; late movers compound debt.

In all three scenarios the destination is the same. The only variable is how long you have to get there — and whether you arrive as a leader or a follower. The first company in a sector to go AI-native gets a compounding head start. The last one gets acquired, or disappears.

Chapter Ten

Monday Morning: Your 90 Days & the Communication Playbook

The Playbook's epilogue is the shortest section of the book, and deliberately so. No new concepts. No new arguments. One question: what are you going to do on Monday morning? This chapter assembles everything you've built into exactly that.

The 90-day plan

You already have the components: a Friction Fingerprint (Chapter One), a Legacy Tax figure (Two), a fork decision (Three and Four), a beachhead with named roles (Five), a baseline against the Five Native Tests (Six), an EDGE calendar with retreat criteria (Seven), a Data Sprint budget and governance boundaries (Eight), and an Inaction Tax that prices delay (Nine). The 90-day plan sequences them: weeks one to four to socialise the diagnosis and secure the ring-fenced budget; weeks five to eight to stand up the team and run the Data Sprint; weeks nine to twelve to begin the EDGE Expose phase in earnest. The 90-Day Action Plan Builder assembles the executive summary for you.

A warning from the epilogue, offered with affection: it will be messier than this book makes it sound. The data will be worse. The integration will be harder. Someone will want to quit in week seven. The organisations that succeed are the ones with the most institutional patience.

The communication playbook

The human transition deserves the same rigour as the technical one — handled with care, it's not just ethical, it's a competitive advantage. Four principles from the Playbook govern every message:

1. Name the change honestly. Your workforce has a finely tuned BS detector. Tell them what's actually happening, not the sanitised version.
2. Lead with the future, not the spreadsheet. New roles, retraining, timeline, support — then the arithmetic. People need to see a future before they can hear a number.
3. Admit uncertainty. It earns credibility. Pretending certainty destroys it.
4. Fund the transition properly. Three to six months of structured transition, not a two-day workshop. If it's not in the budget, it's not real.

You'll need three versions of the message — board, direct reports, and front-line teams — and the timing matters: communicate before the Design phase, not at Go Live. By the time agents are visibly running, the story has already been written for you, usually wrongly. The new roles — Agent Supervisor, System Architect, Exception Handler, Alignment Specialist — each draw on existing team expertise, and saying so early, with names attached, is the single most stabilising thing a leader can do.