Inside the book
Skin in the Runtime
The chapter guide, with the insight each chapter grew out of, and one artifact from the book.
As an Amazon Associate I earn from qualifying purchases.
Who this book is for
CTOs, VPs of engineering, directors, and the senior engineers about to become them. Leaders who are accountable for outcomes their teams now produce with AI in the loop, and who have noticed that shipping faster has not made the results feel better.
It is not a prompt-engineering guide, a tool comparison, or a manifesto about replacing engineers. Tools change quarterly. The book is about the judgment that has to sit above them: who owns the contract for a change, what a team must still understand when a model writes the middle, how to tell real productivity from license counts, and how to keep enough skin in the runtime to make those calls honestly.
It is written from twenty-five years of building teams, shipping products, and leading platform, cloud, and AI transformations from startups to Fortune 500 scale. Every chapter ends with a concrete artifact, a checklist, scorecard, or protocol, you can put to work the same week you read it.
Chapter guide
The chapters grew out of insights first published here. Each one links to the long-form version, so you can read the argument before you buy the book, or go deeper after you have.
Where AI-era delivery actually stalls
AI did not remove the human constraint. It moved it from typing to review, and it thinned product ownership of the ask and the outcome. The book separates contract review from style review, shows why adding senior reviewers does not fix a capacity problem, and gives leaders a way to add gates without building a committee.
Cognitive debt
Teams do not need to know every line when AI writes the middle. They do need the durable high-level model: intent, boundaries, invariants, and failure modes. Losing that model is the debt. The chapter names the risk, shows where the partnership fails, and sets a division of cognitive labor that survives turnover.
The metrics that prove AI is working, and the ones that lie
License counts and anecdotal speedups are not evidence. The book builds an executive dashboard from baselines, outcome metrics, review burden, and platform-fit signals, so a leader can tell whether AI is changing the economics or just accelerating the wrong architecture.
The leadership-grade homelab
A production-shaped lab is not a hobby rack. It is deliberate practice that keeps technical judgment calibrated when the enterprise stakes are high. This is the chapter the title comes from: leaders who keep skin in the runtime make honest platform, cloud, and AI decisions.
Agent sprawl is the new shadow IT
Agents are moving from pilots into production workflows faster than governance can follow. The book treats AI adoption as a platform engineering problem: context standards, validation, observability, and cost control, applied before sprawl becomes an incident.
Build versus rent when AI has repriced the ledger
Rented SaaS and contracted code used to be the safe default. AI and open platforms changed the build side of that equation. The chapter lays out the rental traps, when renting is still right, and the ownership discipline that makes building a strategy instead of a hobby.
Proof under pressure: the $14M migration
Judgment has to survive contact with a real budget. A multi-cloud to AWS migration that returned $14M a year with zero business impact is the worked example: landing-zone standards, phased cutover, explicit kill lists, and the discipline that keeps savings from evaporating once the project team disbands.
Read: Leading Platform Migrations at Scale → How cloud savings disappear after migration →
Crisis leadership
Sixteen years as an auxiliary police officer taught decision-making under pressure, de-escalation, and command presence without formal authority. The book brings those lessons to incident rooms, board calls, and the moment a migration goes sideways.
Teams that own the runtime
Small end-to-end teams that own the whole experience, from interface through infrastructure, remove the hand-off seams that dilute accountability. The closing chapters show how to structure, staff, and measure those teams, and what leaders must do to let them keep ownership.
The argument has kept moving since the manuscript closed. The most recent companion insight, The Token Bill Is the New Cloud Bill , applies the same ownership test to agent spend.
A sample artifact: the runtime judgment test
Every chapter closes with something you can use in a meeting. This is the executive test the whole book keeps returning to. If a leadership team cannot answer these in one sitting, the constraint has already moved and nobody has caught up to it yet.
- Who owns the contract for this change, and would they notice if the intent drifted?
- If the model wrote the middle, which invariants does the team still hold in their heads?
- What is the baseline we measured before we claimed AI made us faster?
- Which agent, workflow, or vendor can stop the spend on the next call, not on the next invoice?
- When did a leader in this room last operate the kind of system they are deciding about?
- What would we rent today that we could own in a quarter, and what would ownership cost us?
The book pairs each question with the operating model that answers it, and with what not to do when the honest answer is uncomfortable.
Now on Amazon
Contract Over Code
Owning the Ask, the Review, and the Outcome When Generation Is Cheap
William Shane Burrell
Generation is cheap. The contract is not. Your queue is reporting an unowned contract, not a generation problem. This book tells you whether that is a staffing problem, a gating problem, or an ownership problem, and what to install in ninety days.
Kindle $12.99 · Paperback $18.99 · Hardcover $27.99
As an Amazon Associate I earn from qualifying purchases.
Reading it with a team?
Bulk copies are easy to arrange, and a working session walks your leadership team through the first artifact with the person who wrote it.