Management · a book
How to build an AI capability that compounds, without building a bureaucracy.
A company that introduces, adopts and uses AI pays for the same lessons over and over: the same failure found by two teams, the same scarce expert asked by nine, the same mistake made again when the person who knew has left. This book is about paying once.
Contents
Chapter 1 · The five symptoms
Two teams pay for the same lesson. Five symptoms tell you whether you need anyone to own the connections.
Chapter 2 · The Three Keys; the setting board
ACM as a set of jobs, not a box of people. Who spends, who vouches, who accepts; who raises the fund and who allocates it; five settings from a conversation to a department.
Chapter 3 · Share, Tune, Buy, Leave; the capability tensor
Two questions place every capability: how often the need recurs and how different the local needs are.
Chapter 4 · The Question Ladder
Reuse, acquire, test, develop or decline. A fast lane for cheap work, and a budget in place of a priority label.
Chapter 5 · Who gains from telling?
Records, failures, promises and the ratchet: why a team hides a failure and what to change.
Chapter 6 · The Handover Ladder
Where a scarce expert should spend time, and how support steps back when a team is ready.
Chapter 7 · The Capability Portfolio
Continuity, insurance, quiet quarters, and when to close.
Chapter 8 · The ACM Canvas
Putting it together: the first 90 days, a kill checklist, and three company sizes.
Appendix · Personas and agent prompts
The people who hold the jobs and the keys and the agents that can help them, each with a goal, a fear, where they sit and a line never to cross; every agent with a ready prompt and two examples.
Preface
I have spent twenty-five years watching organizations adopt technology that was supposed to make them better, and watching the same few things go wrong. Teams solve a problem the company has already solved. The one person who understands the hard part becomes a queue. A lesson is learned at great cost and then forgotten. Nobody is at fault. The structure makes it likely.
AI sharpens all of this. The lessons cost more, the mistakes are harder to see, and the people who can judge are few. So I wrote down what I believe about how to manage it.
It is a book of convictions. You will read "I" a great deal. When I say I believe something, I mean that I have reasons I will give you, and that I will tell you what would change my mind. Those reasons come from experience and from the research on this site, and I keep the two apart.
The site has three layers, and they make one argument in three voices. Research is the foundation: small mathematical models, checked where possible by Lean, a program that checks every step of a proof. It says what follows from stated assumptions and nothing more. Business is a faithful translation of the research for executives, with no new assumptions. This book is the third layer. It goes beyond both. Where a chapter rests on a checked result, it links to the lesson. Where it rests on my experience, it says so once, plainly, and does not pad every sentence with a hedge.
One rule from the research shapes the whole book. In every model, a capable local team has the same information, people and rules as a shared route. So an organization called "AI capability management" earns no premium for its name. Any gain has to come from a specific mechanism: a record that moves, a scarce expert used once instead of five times, a rule that makes honesty pay. That is why this is a book about jobs and decisions, not about boxes on an organization chart. It is also why the first thing I recommend is often to do less.
Anyone who has to decide how a company should introduce, adopt and use AI. That includes companies that build models, with their GPUs and training runs, but it is wider. The scarce thing in your company might be specialist time, compute or a vendor budget. Everywhere I write "GPU hours", read whatever your teams queue for.
Each chapter starts with the story. It then states the problem and shows what the research says, without more than it says. It sets out my convictions in a fixed form: the belief, why I hold it, and what would change my mind. It gives one framework as a figure that should be readable on its own, with a title that says the takeaway. A real company or case appears in a sidebar, dated and sourced, labelled as a public analogy and never as evidence for my argument. And it ends with a short list of things to do on Monday.
Hartwell is a fictional company of six thousand people that makes and services industrial pumps and compressors in thirty countries. Maya Okafor is its chief of staff to the COO, who names her the first AI Capability Manager. The people are invented, the numbers are illustrative, and the frameworks are proposals that I am putting to you. The ending includes a failure, because every real arrangement I have seen has one.
Name an owner before you build a department; fund the question before the answer; share what recurs and looks alike, and keep the acceptance test local; make telling the truth pay; teach people and then step back; keep what you learned, and close what no longer earns its place.
The ACM Canvas · preview
By the last chapter you will have a canvas you can fill in on one page: eight blocks, always in the same order, from the need to the day it ends. Here it is empty so you can see its shape. Chapter 8 fills it in for Hartwell, for a startup and for a very large company.
Framework 11 · the ACM Canvas, blank
Eight blocks, filled in the same order every time: start from the need, end with when it ends.
Blank, so you can see the shape: the largest blocks matter most, and the numbers give the one order to fill them in. Select a number to read that block’s rule of the game, or print a blank to fill in by hand. Hartwell is fictional; every entry is illustrative.