Two of the most influential operations books of the last forty years are novels. Not case studies, not frameworks with a fold-out poster in the back. Novels, with characters and a plot and a villain who turns out to be human. Eliyahu Goldratt taught a generation of factory managers the Theory of Constraints in 1984 by writing a story about a plant manager with ninety days to save his factory. Gene Kim did the same for IT in 2013, and The Phoenix Project became the book every DevOps team quietly hands to the new hire.
The manuals on the same subjects sold a fraction as many copies. That is the part worth sitting with. The rigorous, complete, correct treatment of an idea loses, again and again, to the version with a protagonist and a deadline.
Download for free, or get it at conveniently for Kindle for the price of a coffee.
The story we tell about how ideas spread
The comfortable explanation is that people are lazy, or busy, and a story goes down easier than a diagram. Fiction as the sugar coating on the medicine. That framing is wrong, and it is wrong in a way that matters if you are trying to change how an organization works.
A method does not spread because it is correct. It spreads because it gets passed from one person to the next, and the thing that gets passed has to survive the trip. A framework document does not survive. It sits on a shared drive, accurate and unread. A story survives, because a person can carry it in their head and retell it at lunch. The unit of transmission is not the idea. It is the retelling.
This is a flow problem, not a content problem. You can write the most precise description of a bottleneck ever committed to paper, and it will change nothing if it never moves through the organization. The novel moves.
“We’re keeping ten thousand people from being shredded by gravel moving at four kilometers a second.”
Kessler Seven, Chapter 16: Business and Intent
Why a character does what a definition cannot
Here is the mechanism. A definition tells you what a bottleneck is. A character makes you recognize the one down the hall.
In Kessler Seven, a novel I released this summer, the bottleneck has a name and a face. He is Marcus, the man who runs build and release on Meridian Station, and every pod the station needs passes through him. He knows he is the constraint. And he is also exhausted, because the whole system routes through one overloaded person, and no amount of working late fixes a structural problem. You do not read that and file it under “constraint theory.” You read it and think of the Marcus on your own team.
Marcus didn’t show up for the morning sync. He was in the medical bay. Exhaustion. The medic had ordered him to rest for twenty-four hours. No work. No slate. No “just one quick check.”
Kessler Seven, Chapter 10: The Bottleneck
That is what a story does that a manual cannot. It converts a concept into a person you already know. The gatekeeper who slows everything down to protect the milestones, convinced he is defending the system while he is defending it to death. The rogue contractor who ships around the process because the process cannot keep up with reality. The mentor who answers every question with another question. These are not illustrations of Product Velocity concepts. They are the concepts, walking around, arguing with each other.
The plot is a debris cloud. A mining accident shatters an asteroid into thousands of fragments on a collision course with a station of ten thousand people. The only defense is interceptor pods, built and deployed by the thousands. The program has produced four hundred. It is not failing on physics. It is failing on handoffs, on stage gates, on good intentions. Yuki Tanaka, a propulsion engineer who never wanted to lead anything, has to fix the way the work flows before the sky finishes falling.
Strip away the vacuum and the countdown, and Yuki’s enemy is the one every engineering organization fights. Work that will not move. A car program, a medical device launch, a new machine on a factory floor. The threat is quieter than a falling sky and exactly the same shape.
What is actually inside the fiction
The concepts are not decoration. The Velocity Loop appears as a diagram the mentor, Amara, draws on a wall in chapter six. Business, System Stewardship, Engineering, Delivery. Four practices that only work when the loop closes and the field’s lessons travel back to the front. Most organizations have all four and no loop, just a relay race with the baton dropped at every handoff. The book shows you the dropped baton before it ever gives it a name.
Yuki blinked. Reyes didn’t let her finish. “Also: Earth replied.”
Kessler Seven, Chapter 13: Audit
“To the evacuation request?”
“To the standby protocol. It’s not a ‘no.’ It’s worse than that.”
The turns are the method’s turns. The gatekeeper stops being a gate and becomes part of the loop. The bottleneck stops guarding a door and starts making sure nothing falls through the cracks between specialists. The team learns to verify a design in a model before cutting metal, because the most expensive way to find out a design is wrong is to build it and watch it fail. By the end the loop does not depend on the hero at all. It depends on the structure, which is why someone else can take the chair and the rhythm holds. Anyone who has read the Product Velocity method recognizes every beat. Anyone who has not gets the method anyway, smuggled in as plot.
There is one more experiment folded into the book, and it is one this audience will have opinions about. I wrote Kessler Seven primarily with Claude, working from the full manuscript of my forthcoming Product Velocity book so the concepts stayed exact. The model wrote, I curated and edited and checked that the terminology held. My role moved from author to editor. The provenance is stated plainly in the front matter, because a book about how work should flow should be honest about how it was made.
A test you can run on your own method
Pick the most important idea about how your team should work. The one you wish everyone understood. Now ask whether a colleague could carry it to another colleague without the document in front of them. Could they retell it at lunch and have it land?
If the answer is no, the idea is not spreading, whatever the wiki says. It is stored, not transmitted. That is the gap a story closes.
Pass it on
Kessler Seven is free as an EPUB, and it is in the Kindle store for the price of a coffee. Same text either way, same afterword explaining the method behind the plot. The Kindle price buys convenience, not different content.
A teaching novel earns its keep by being handed around. That is how The Phoenix Project moved through a decade of engineering teams, one desk to the next. If you have colleagues fighting slow approvals and lost handoffs, they will recognize Meridian, and they will recognize themselves. The method behind the story is open and free, the loop and the four practices and a growing set of resources for putting it to work on your own product.
The fastest way to move an idea through an organization is to make it worth retelling. Then hand it to the first person and get out of the way.
English
German