Inside the book
Cognitive Debt
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, and directors who still own outcomes. Leaders who will be asked whether anyone still understands the codebase, and who need a better answer than a dashboard.
It is not a prompt-engineering guide, a tool comparison, or a rewrite of Skin in the Runtime. Chapter 2 of that book named the debt. This book is the audit: which debt you are actually in, what the team must still hold, and how to pay one surface down before an incident or an acquirer prices the hole.
You do not need a new platform. You need five holdings a leader can name, a check that is not a theater review, and a ninety-day sequence for one expensive surface. Every numbered chapter ends with an artifact you can run the same week.
Chapter guide
The diagnosis already lives in an insight here. The audit and the paydown are in the book.
Three debts
Cognitive, intent, and comprehension are not the same hole. The book names which one a surface is actually in, so a leadership team stops treating every gap as “nobody understands the code.”
Five holdings
Intent, boundaries, invariants, failure modes, and a named owner. Holdings a leader can name without averaging colors across a dashboard. The team must still hold the contract when a model writes the middle.
The explain / operate / change check
How to check a surface without a theater review. Three questions, run on one surface, with honest reds and no punishment for the first pass.
Onboarding and the data room
What a new engineer can reconstruct in week one, and what an acquirer prices when the data room is full of generated commits and an empty contract layer.
Ninety-day paydown
Pay one expensive surface down in ninety days. Audit, capture intent, register boundaries, table invariants, drill a failure mode, and re-score. No new tooling. No trophy dashboard.
A sample artifact: the explain / operate / change check
Every numbered chapter closes with something you can use in a meeting. These three questions are the check. Run them on one surface. If the room cannot answer them without opening an IDE, the debt is already there.
- Explain. Can the people accountable for this surface state its intent, boundaries, and top invariants without opening an IDE or a wiki?
- Operate. Can they detect a violation before production, and respond to one without a specific person?
- Change. Can they alter a constraint, update the contract, and get consistent behavior against the new terms without hand-correction?
The book pairs each question with how to run it without a theater review, and with the ninety-day sequence for the surface that fails.
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?
Start with copies for the readers and a facilitator guide. If the team wants to work through the explain / operate / change audit after reading, that conversation comes next.