What follows is reprinted exactly as it appears on page xiii of Assembled. Aligned. Adaptive.
A note on how this book was made with AI, and the obligation to say so
When I tell people I used AI to help write this book, some will assume AI did most of the writing, but it didn't. I've spent my career asking leaders to be honest about what they know and how they came to know it, so I owe you the same honesty about how this book came to be.
Obviously, the stories are mine. But the synthesis is mine too — more than fifty voices across strategy, product thinking, flow, organizational design, and leadership, connected into one coherent system I call the Adaptive Organization Operating Model. I've built it over decades of coaching organizations of every size, and I've been testing it most recently by leading the transformation of more than 250 teams at Huntington Bank.
A coaching friend, Jeff Kosciejew, once put words to something I'd always felt. A coach, he said, is only as good as the sum of the stories they can tell. Steve Jobs said something similar about a career: you collect experiences without knowing which will matter, and only looking back can you connect the dots. My work has been a long exercise in collecting dots across these five disciplines. This book is what happens when you finally connect them. The ideas are well-known and proven; the synthesis is what's new.
Here is what working with Claude as my writing partner looked like. I described what each chapter needed to argue, the experiences I wanted to draw on, and the voices that belonged there. Claude organized the structure, drafted initial prose, and kept the book's overall architecture in mind throughout months of work. I edited, challenged, and rewrote a lot in each iteration. I taught Claude multiple skills, including how to write drafts in my voice. But the real work was mine: for each of the fifty voices, I brought the ideas I actually use, explained how I apply them when I'm coaching, where they create value for leaders and teams, and how they connect within the operating model I've spent years developing. I also taught Claude to ask me questions about the work and my experience and to suggest where a story would help. Working with Claude was valuable not just because it could remember everything we wrote, but because I was surprised by how often writing multiple drafts and discussing the content revealed connections between ideas I hadn't seen before.
I think this is how a great deal of serious intellectual work will be done from here on. Not AI generating content that its author doesn't understand, but practitioners using AI to express what they truly know, in a form that reaches the people who need it. Any author who uses AI this way should say so. I'm saying so.
You'll recognize many of the voices in the chapters ahead. What I hope catches you off guard is how well they fit together. It surprised me, too, when I first saw the whole. I'd been teaching these ideas separately for years; when assembled and aligned, they turned out to be something much more.
Assembled. Aligned. Adaptive.
Brian Link
Enterprise Agile Coach · Practical Agilist · Columbus, Ohio
July 2026
What that actually looked like
The preface says the work was mine. Every author says that. So here is the specific version, including the parts that don't flatter me.
It started as a talk, not a book. Before any of this involved AI, I was building a session about the system leaders have to understand — the environment they're responsible for creating if they want teams to succeed. That became a white paper and a deck. Those two documents were the first things I loaded into the Claude Project that eventually housed the whole book, alongside a growing pile of reference material I'd been collecting for years. The argument existed before the tool did, and that order matters more than anything else on this page.
The drafting took about four months. The thinking took twenty years. I started in the spring of 2026 and published in July, which is fast for a 380-page book, and I know how that sounds. But nothing in it was invented in four months. The five layers came out of a career coaching organizations of every size, and most recently out of leading a transformation across more than 250 teams. What AI compressed was the distance between knowing something and getting it onto a page in an order that holds together.
I taught it my voice, and then told it my voice was wrong. If you only read one item on this page, make it this one. To build the writing-style skill, I gave Claude everything I'd published — years of blog posts, and all of my previous book, The Practical Agilist Guidebook — and asked it to describe back to me what my writing actually sounded like. It did a good job of it. It said I was casual, warm, and clearly writing to connect with team members, which was exactly right for the Guidebook and exactly what that audience needed. And it was the wrong voice for this book. This one is written for executives and senior leaders, so the casualness had to come down, the register had to get more polished and more confident, and none of that could cost me the warmth that makes the writing mine in the first place. So we built the new target together. A tool can model the voice you already have. It has no way of knowing the voice you need.
I wrote the rules it had to work inside. Before there was much prose there was a style guide, and it exists because AI writing has a texture I didn't want anywhere near my name. It bans specific words on sight — ultimately, fundamentally, navigate, landscape, straightforward, seamless. It bans specific constructions: the "it's not X, it's Y" reversal, three sentences opening the same way, clusters of em-dashes doing work a comma should do, the short punchy sentence dropped in to sound profound. Every draft got measured against that list.
One example of how petty that got. Partway through I noticed one particular word had crept into the manuscript about fifty times. I cut it to eighteen, and the survivors had to earn their place by pushing against something the reader would otherwise assume. Nobody asked me to do that. It's the kind of thing you only bother with if the voice is actually yours to protect.
I have a punctuation philosophy and I enforced it, and I banned my own acronym. A period means two independent thoughts. A semicolon means they're independent but one draws its insight from the other. Where there's a causal relationship I want the logic visible, so it gets a because or a so rather than a mark. An em-dash is for an aside. Separately: the Adaptive Organization Operating Model shortens neatly to four letters, and that acronym appears nowhere in the book, because acronyms make a model feel like a methodology you buy, and this one is meant to describe how your organization already works.
We passed Word documents back and forth with tracked changes turned on. That's the unglamorous mechanism behind the dialogue the preface describes. Claude read each chapter cold and produced a diagnostic — everything questionable, ranked, with the full paragraph in context so I could judge it in place. Then we worked the list one item at a time, in the document, with every change tracked so I could see exactly what had moved and reject it if I didn't like it. Nothing changed in a chapter because a tool suggested it. Things changed because I agreed.
The paragraph you read above about our collaboration is itself an example. In the preface, the paragraph beginning "Here is what working with Claude as my writing partner looked like" went through several passes. Claude produced a tightened version. I rewrote it differently and shorter, and Claude's own response was that mine was better than both the original and its pass — that making the questioning something I engineered, rather than something the tool happened to do, fit the argument better. That happened constantly. My wording usually won, because I was the one who knew what the sentence was for.
I brought in an outside reviewer, and then argued with it. Late in the process I took one of the near-final drafts and ran it past ChatGPT for a cold read. It surfaced real problems, and both Claude and I came away with action items worth doing. It was also confidently wrong about several other things, and we agreed to throw those out. Using one model to check another only helps if somebody in the room is willing to overrule both of them.
And Claude was wrong sometimes, in ways that mattered. Near the end it flagged an inconsistency in how one of the five layer questions was worded across the manuscript and recommended a fix. I searched for the phrase it had quoted and found nothing. It had misattributed something from the website to the book and constructed a problem that didn't exist. Two things there are worth saying out loud: it was confident, and I was the only safeguard. If I'd accepted the recommendation without checking, I would have introduced an error into a book that didn't have one.
A word I refused. Early on, a chapter used ceremony the way Scrum vocabulary does. I didn't want it. The word carries a tribal, almost religious weight that leads people to treat agile practices as fixed and handed down, which is the exact misunderstanding I spend my working life arguing against. That isn't a style preference. It's twenty years of watching one word do damage in real rooms.
The unglamorous majority. I read the whole book start to finish more than once as an editor, hunting formatting inconsistencies that no amount of chapter-level attention catches. A final pass through Grammarly found plenty we had both missed and tightened the prose in places I'd stopped seeing. The task backlog lived in ClickUp, connected to the project so Claude could read and update it directly, but I chose what to work on in each session based on rough priority and my own sense of what was left unwritten versus what needed editing. The tool never set the agenda.
What Claude actually did. It drafted first passes. It chased citations and kept the bibliography honest. It held the shape of all twenty chapters in view while I was buried inside one of them. It ran consistency sweeps no human would volunteer for. And it asked me questions, because I taught it to, and some of those questions surfaced connections between ideas I hadn't seen in twenty years of teaching them separately. That last one is the part I didn't expect.
The receipts. Every structural decision has a written record — what changed, why, and what I rejected. The manuscript went through more than forty numbered versions before print, and individual chapters through a dozen or more each. The interior design, the tangram graphics, and the print production are entirely mine.
The working documents include a running log of the calls we made — what changed, why, and what got rejected. A sample:
Then why isn't the book about AI?
It's a reasonable question to ask a page like this one.
AI is barely in the book, and that's deliberate. The five layers exist to describe what lets an organization absorb disruption, not one particular disruption. Strategy, product thinking, flow, org design, leadership and culture will hold regardless of what technology arrives next to upend somebody's plan. Write the book about AI and it's stale in eighteen months. Write it about the system that has to metabolize AI, and it's still useful when the next thing lands.
I'm not an AI skeptic. This book is evidence of that; it wouldn't exist in this form without the tools. But when I'm honest about my own work as a coach, what I bring is decades of pattern recognition and judgment. AI is something I think and communicate with. It isn't the source of the work, and that distinction is the entire argument.
Which is why the question to ask before any AI initiative is the same one it always was: what problem are we actually trying to solve? Without an answer, you'll get exactly what you asked for and nothing in return. A good operating model doesn't make AI irrelevant. It's what makes AI investable.