Designed to be Understood

What This Book Cannot Know [Chapter 10]

[Chapter 10 from Deliberate Alignment by Walter Reid, written in spring 2026]

The honest end is not a conclusion. It is a constraint that decides what the middle is allowed to say.

This chapter was written before the others.

That is not a rhetorical device. It is the actual sequence. The argument in the preceding nine chapters was built forward from an observation about where the bottleneck has moved. This chapter was built backward from a different question: what would it mean to have been wrong?

A chapter of structured humility written after the case has been made is almost always defensive — the author protecting the thesis against objections they have already dismissed internally. The concessions are real but not load-bearing.

This chapter is meant to be load-bearing.

What I Am Confident About

The structural argument — that when the cost of execution drops toward zero, the bottleneck moves upstream to decision quality — I believe this is true and I believe it follows from first principles that do not depend on any particular technology. Goldratt’s insight about constraints is a property of systems. When one constraint is relieved, the system reorganizes around the next one. This has happened before, it is happening now, and the direction of the reorganization is not difficult to read.

Confidence: high. Not because I am certain about the pace or the shape, but because the logic does not have an obvious hole. If someone finds the hole, I want to know.

The observation that agile’s sprint structure was scaffolding for a build-time constraint rather than a timeless organizational truth — I also believe this. The sprint is not sacred. It was practical. When the practice it was built around changes, the scaffold should come down. Organizations that treat the sprint as doctrine rather than tool will feel this as disruption. Organizations that treat it as a useful heuristic that may need replacing will feel it as evolution.

The claim that communication quality is the variable that determines whether a team experiences this moment as relief or panic — I believe this too, and it is the claim I think is most immediately actionable. You do not need to wait for methodology to catch up. You can ask today whether your team has a shared understanding of what they are building and why, and the answer will tell you something real about your exposure.

And the scene that opened this book — the conversation that became the product before the meeting ended — is closer to something I have done than the speculative framing of Chapter One suggests. The conversation-to-execution pipeline this book describes is not theoretical for me. I have transcribed meetings, built the context documents, and started execution before the handshake.

The introduction to this book named something I had felt but not yet proved: that the people with the best ideas keep losing to the people with the fastest execution. Nine chapters later, I can say why. The speed gap has widened past the point where the best ideas can catch up through iteration alone.

I am also confident about this: the product I designed at Mastercard — called Nucleus, meant to give small businesses invoicing, marketing, and a client portal — is essentially what RouteForge does now, built in six weeks instead of years. The constraint was never capability. It was organizational structure. Small businesses wanted connected tools. I knew that in 2021. The technology only supported bespoke options then. Now it has changed. Most companies just haven’t fully realized it.

What I Am Inferring

Deliberate Alignment as a named methodology is inference. It is the shape I see when I look at the structural argument and ask what a practice organized around it would look like. The logic feels sound. The name feels right. But a framework earns its name from practitioners, not from the person who proposes it. Kent Beck’s ideas existed before Extreme Programming had a name. The name arrived because people lived the practice and needed to refer to it. We are not there yet.

Confidence that some version of this becomes a recognized practice in three to five years: around 0.65. Confidence that it arrives under the name Deliberate Alignment specifically: much lower. Maybe 0.20. Names are contingent on who writes the book that lands, which conference talk gets shared, which team’s success story becomes the case study everyone cites.

The PSaaS framing is the most speculative chapter in the book. It is the place where I am reasoning furthest beyond the evidence and closest to what I find philosophically interesting. That is a warning sign I want to name explicitly. The interesting and the true are not the same thing, and I am more drawn to this idea than the current evidence strictly warrants.

What Would Falsify This

A book that will not name its falsification conditions is not making a claim. It is performing one.

If execution costs drop toward zero but decision quality does not become the new constraint — if instead some other variable emerges as the bottleneck, say compute cost, or regulatory approval latency, or the rate at which humans can absorb new software into their lives — then the specific reorganization I am describing does not follow. The structural argument about constraints would still be correct, but the direction would be different.

If the quality of AI-generated alignment itself improves fast enough — if the models become good enough at synthesizing ambiguous human intent that the pre-execution alignment session becomes a task for AI rather than humans — then the human-centered practice I am describing has a shorter shelf life than the book implies. I have been assuming that understanding what a client actually needs, beneath what they say, remains human territory for the duration of this book’s relevance. That assumption could be wrong within five years. It is probably not wrong within two.

If the RouteForge example — three people, one real problem, a solution built from genuine understanding — turns out not to generalize beyond unusually well-aligned small teams, then the foundation of the practical argument is weaker than presented. I believe it generalizes. I cannot yet prove it.

And the falsification condition the book must be most honest about: what if the methodology only works for small teams? Every concrete example in this book is small-scale — three people in a room, five people at a Thursday meeting, a franchise operation with five vans. The structural argument applies regardless of scale. The practice as described may not. The room with three functions present and aligned is one thing at five people. It is a different thing at fifty, and a different thing again at five hundred. If Deliberate Alignment cannot scale past the small team without becoming the kind of process overhead it was designed to replace, the book has described something real but narrower than it claims.

The Failure Mode of This Book Itself

The conversation that generated this book was generative precisely because neither party was certain. Questions were asked that did not have predetermined answers. A confidence score was offered and then interrogated: what would raise it? An outline was proposed and then given permission to be burned if it stopped serving the end.

The Zansei project — the case study that runs through four chapters of this book — has its own resolution, and honesty requires including it. Zansei is now Ad101, still live. It stalled in January and February of 2026 after the first soft launch, and the stall was the framework’s diagnosis made visible: the taste function was vacant, authority operated without consistent depth, and the meaning failures between UX and development described in Chapter Three were never resolved through the ceremonies. The fix required me to occupy the taste vacancy myself, eventually absorbing the execution function when the developer stepped away. The team member closest to the client held depth through direct contact with customers. Other team members stepped away. The project is moving again under consolidated direction, with a new design and backend I built. The framework was tested on the thing closest to me, and it bent but held. It diagnosed the dysfunction correctly. It could not fix it without someone willing to occupy the vacancy — which is itself a finding the framework should carry.

That last sentence requires a disclosure. This book emerged from a specific conversation between a human and an AI. The human brought context that the AI could not have had: years at a major payments network, a memory of paired programming from an earlier career, an instinct about personal software that arrived before it had a name, the image of a business developer with a signed SOW that crystallized the opening scene of Chapter One. The AI brought synthesis, pattern recognition, and the willingness to say the bottleneck has moved with enough specificity that it could be interrogated.

There is a tension here that the book should not resolve too quickly. This is a book about the irreplaceable value of human judgment — the depth function, the quality of listening that hears Ireland underneath a routing problem. And the book itself was structurally shaped by a collaboration in which AI did meaningful work. The AI did not contribute to the depth function. It operated in synthesis and execution — pattern recognition, structural organization, the precise articulation of things I could observe but not always say clearly on the first pass. I am a better observer than a writer. The depth function writing about a world where depth is the last thing standing, with AI holding execution in the writing process itself — that is the collaboration the book practices, not just the collaboration it describes.

The value was not in the synthesis or the questions alone. It was in the space between them — the moment when one party said something the other made more precise, which prompted a refinement, which unlocked the next level of the argument. That space is what Deliberate Alignment is trying to institutionalize. Not the AI. Not the human. The quality of what happens between them.

If you are reading this and you have lived some version of this methodology — if you have been in the room, if you have watched the work finish before the meeting did, if you have felt the specific relief or the specific panic — your experience is more load-bearing than my argument. The framework should bend toward what you know, not the other way around.

This is an invitation, not a disclaimer.

What the Work Is Actually For

RouteForge is not finished. The room that produced it — three people, aligned before anyone opened a laptop, each holding a function the others couldn’t — is the room this book has been trying to describe.

Joe and Keli don’t know the methodology has a name. They don’t need to. What they needed was for the right people to be in the right room with the right quality of listening, and for what was heard to become what was built without losing anything in the translation.

That is the discipline. Not the sprint. Not the standup. Not the retrospective. The quality of understanding that happens before execution begins, specific enough that what follows it is the right thing rather than a thing.

Keli wants to go to Ireland. That is what John heard underneath the routing problem and the spreadsheet and the four hours every week. Whether RouteForge gets her there is a question the book cannot answer. Whether the room that heard her correctly was the right room — that question, the book can answer.

It was.

Whether this book has described that room precisely enough that someone else can build one — that is the question only practice will answer.

I think the room works. I think the framework is true and temporary. I think both of those sentences need to be here. And I think “temporary” may mean something more specific than the word usually carries — that the room this book describes may be getting smaller, that the functions it names may consolidate into fewer people and eventually perhaps into one, and that what that means for the people who used to fill the room is a question this book has opened but cannot close.

The practitioners who live this will know before I do.

The outline survives until it stops serving the end. The end was always this.

← Previous: Chapter 9: The Three People in the Room · Contents

The Three People in the Room [Chapter 9]

[Chapter 9 from Deliberate Alignment by Walter Reid, written in spring 2026]

Mark knew a problem. John heard a problem. Walter built the solution. For now, it takes all three.

Mark is well-connected in private equity. He knows CEOs the way people in that world know CEOs — through deals, through boards, through the specific texture of trust that gets built when money changes hands and things either go well or they don’t. One of the people he knows runs a franchise operation that has been managing its business the way franchise operations managed their businesses twenty years ago: spreadsheets, manual processes, institutional knowledge stored in the heads of the people who have been there longest.

He introduced John to Joe and Keli.

Joe and Keli are ex-bankers. They left the bank to open a Filta Environmental franchise in Deer Park, New York — which is a trade most people understand instinctively — the security and the constraint of the institution, exchanged for the risk and the autonomy of ownership. They knew the pain of their current operation. They could feel the inefficiency every day. What they did not know was what to do about it, or whether what they needed even existed, or whether building it was something that happened to companies their size.

John is a Meineke franchise operator. He is building from the operator’s seat, not a boardroom. He sat with Joe and Keli, asked the right questions, watched how they worked, understood the pain not as a description but as a felt thing — the spreadsheet that had to be downloaded, edited by hand, and uploaded again every single week. The vans they couldn’t see and the routes they couldn’t trust. He came away with something rare: a real understanding of a real problem, specific enough to be solved.

Then he built a prototype.

The prototype was real, in the way that a blueprint is real. You could see the shape of the building. You could imagine living in it. What it could not do was support weight.

He brought it to me.

What the Prototypes Said

What followed was not a document handoff. It was two competing prototypes.

John’s had twenty-plus features — scheduling, routing, invoicing, fleet views. It had sixty-plus migration files, two of which had never been run. It had the ambition of someone who understood the problem deeply and had built at AI speed without an architectural plan underneath. My prototype had none of that. What it had was multi-tenant infrastructure — the foundation that would let the system serve not just Joe and Keli but any franchise operator with a similar problem, cleanly separated, without one customer’s data bleeding into another’s.

The alignment between us was not a conversation that produced a document. It was a structured comparison, with Claude Opus as participant. Opus saw both codebases and determined that it was actually easier to fix my foundation than to rebuild John’s features on top of it. The elegant infrastructure could absorb the features. The features could not retroactively produce the infrastructure. That assessment — an AI holding something like the taste function, able to see which architecture would bear weight — became the decision. We built forward from my foundation and migrated John’s feature logic into it.

That is Deliberate Alignment mediated by AI. The AI did not make the decision. It held a structural judgment that neither of us could have held as clearly on our own, because neither of us could read both codebases simultaneously and evaluate which path forward would cost less in the long run. The authority was still ours. The depth was still John’s. The taste function — the assessment of which architecture was good enough to build on — was shared between me and a model that could see what I had designed and what John had built and compare them without the politics of whose work was better.

What the Data Said

What I found when I looked at what John had heard was a problem worth solving and a set of constraints that would only become visible through the data.

Joe and Keli’s operation ran on a franchise CRM with 189 columns in its export. Longitude values with apostrophes embedded. Schedule records where status had to be inferred from combinations of date fields because a human always knew — a status column had never been necessary before, so one had never been built.

The schema the prototype had imagined was not the schema the actual data required. The first real work was not building. It was listening to what the data was saying about how the business actually ran, as distinct from how the problem had been described.

This is what Chapter Eight called the sensible-for-one, made concrete. No product manager at a software company was ever going to build for the specific intersection of this franchise’s proprietary CRM, this fleet’s GPS system, Google’s route optimization API, and the particular way this operation had grown. The market was too small. The integration too specific. The combination of constraints too particular to justify the overhead of a commercial product.

From that point, it moved. Each phase had a clear definition of done. The decisions that mattered most were not technical — they were product decisions with technical implications. What system is read-only. Who owns the optimization. How to build for a vendor whose partnership agreement doesn’t exist yet without letting that block the whole architecture. These were conversations, not specifications. Each one required understanding the business well enough to know what the constraint was actually protecting.

What Keli Actually Needed

Here is what Keli actually needed, described precisely.

Every week, she downloaded a spreadsheet from her franchise organization’s CRM. She edited it by hand — adjusting routes, accounting for new clients, fitting new vans into sequences the software didn’t understand because the software wasn’t built for an operation her size. Then she uploaded it back. Four hours, every week, because the franchise CRM claimed to handle routing and didn’t, not really, not for a business growing the way hers was growing.

When she added a van, she didn’t add a van. She added four more hours.

What she wanted — what she hadn’t said in those words but what John heard underneath everything else — was to go to Ireland in the summer. She and Joe had been talking about it for two years. Every time they got close to planning it, the business got more complex and the margin of time they needed to feel safe leaving contracted again. The franchise kept adding features to its CRM that addressed other franchisees’ problems. None of them addressed hers.

The software is called RouteForge. It started on February 26, 2026. By early March, there was a working demo. By April 6, a full production system was live — dispatch, invoicing, compliance reporting, analytics, fleet tracking, a customer portal, communication tools, equipment tracking, and job management, across twelve-plus industry verticals. Three people built it.

The comparable commercial tools — ServiceTitan, FieldRoutes, BuildOps, Route4Me — charge between two hundred and four thousand dollars a month and took years of development by teams of dozens. What would have been an eighteen-month product roadmap with a fifteen-person team was built in six weeks by three people who had never worked together before February.

RouteForge downloads the export, runs it through Google’s route optimization with their vans and their clients and their times, and uploads it back. It gives Joe and Keli a live view of their trucks through their GPS system, because the franchise CRM claims to offer this and doesn’t. It generates compliance reports for health department inspections without touching a spreadsheet. It does the job to be done in a way that no template software could — because no template software would embed with a proprietary franchise CRM, integrate a separate GPS vendor, and re-upload the result via Excel in a loop that the franchise system will accept.

RouteForge is live. Five or six companies across verticals have expressed interest. Joe is pushing for adoption among operators he knows. Keli wants to go to Ireland at the end of the year, and for the first time, the plan has a system underneath it instead of a spreadsheet.

But the adoption barrier is not technology or product. It is the thing this book has not yet named directly: operational lock-in at the customer level. The franchisee who wants to adopt RouteForge has to run it alongside their legacy CRM during the transition — doubling their operational complexity during the period when they are most cost-sensitive and least willing to risk disruption. The real challenge is not having customer testimonials or social proof, and the customers’ legacy systems not giving them easy access to their own data. The economic logic is right. The product is right. The transition cost is carried entirely by the customer, and that cost is not monetary. It is attention and risk, which are the scarcest resources a small business owner has.

The Three Functions, Revisited

Mark was the lead — not in the sales sense, but in the trust sense. He knew the landscape. He knew who had real problems and who had the authority to decide to solve them. He connected the right people. Without him, John never meets Joe and Keli. Without him, the problem remains a spreadsheet.

John was the depth function. He heard what was needed beneath what was said. He understood that Joe and Keli weren’t asking for software — they were asking to stop carrying the weight of their own operation’s complexity on their personal time every week. He could see the shape of the solution because he understood the shape of the pain. What he could not do was build from that understanding.

I was the execution function — but execution, in this context, included what Chapter Four called taste. The 189 columns, the apostrophes in longitude values, the status fields that had to be inferred from date combinations — those were not just data problems. They were decisions about what the business actually needed versus what the CRM had imagined it would need. Each product decision had technical implications, and each technical constraint had product implications. Knowing which to respect and which to work around required understanding what good looked like before it was built.

The deliberate alignment of those functions is what produced RouteForge. Remove any one and the thing doesn’t exist. Mark without John and me is a warm introduction to a problem that stays unsolved. John without Mark and me is a prototype that cannot hold weight. Me without Mark and John is a solution to a problem I don’t fully understand, built in a direction that may be technically correct and operationally wrong.

And here is the part that mirrors the book’s thesis back at its own author: RouteForge has more execution capacity than depth capacity. We could use more clients in the room and fewer developers. If I sat down with those clients instead of them doing the job, we could design any system that would help them. The bottleneck is understanding, not building. The framework I have spent nine chapters describing is the framework my own venture is constrained by.

The Dependency That Is Dissolving

Now the uncomfortable part.

John needed me to build what he heard. He needed me specifically — someone with the product instinct and the technical depth to turn his understanding into something real. That dependency is real today. It is also dissolving.

Not because John will become a developer. Because the execution layer between understanding and artifact is compressing faster than any of us have fully reckoned with. The prototype John built — the blueprint that couldn’t hold weight — is already closer to the finished building than it would have been a year ago. The distance between what John can produce and what Joe and Keli need is shorter than it was when he first walked into their office.

The book you are holding was written on the assumption that the three functions would remain distinct for long enough to build a methodology around them. That assumption is probably right for the next few years. It may not be right for the decade. The person closest to the client — the person with the depth function, who hears what is actually needed — will need the execution function for less and less time as the execution layer continues to compress.

What that means for the room is what this book has been trying to describe. For now, it takes all three. The room that produced RouteForge required Mark’s connection, John’s depth, and my execution, working from the same understanding at the same moment — where the handoff was not a handoff because the understanding never had to be summarized and degraded into a document that someone else would misread.

The question is not whether John will be in that room.

The question is what he will need when he gets there.

Mark knew who had the problem. John heard what the problem was. Walter built the solution. For now, that is three people. The question the next decade will answer is which of those functions the room can hold alone.

← Previous: Chapter 8: Personal Software as a Service · Contents · Next: Chapter 10: What This Book Cannot Know →

Personal Software as a Service [Chapter 8]

[Chapter 8 from Deliberate Alignment by Walter Reid, written in spring 2026]

The template existed because custom was expensive. That is the only reason it existed.

Think about the last time you built a website.

If you are old enough, you remember when building a website meant hiring someone. A developer, probably a designer, possibly an agency. The cost was real — not because websites were technically difficult in some absolute sense, but because the people who knew how to make them were scarce relative to the demand. Custom was a luxury not because it was inherently expensive but because the skilled labor required to produce it was.

Then templates arrived. Squarespace. Wix. WordPress themes. A competent person with no technical background could produce something that looked professional in an afternoon. The bespoke website did not disappear — there were still agencies, still developers, still budgets for organizations that needed something the templates could not provide. But for most people, most of the time, the template was good enough. And good enough at low cost reliably defeats excellent at high cost for the majority of use cases.

This was not a technology story. It was an economics story. The barrier was cost. When cost fell, access widened. The template won not because it was better than custom but because it was close enough, and close enough for free beats excellent for thousands of dollars almost every time.

Now think about what happens when AI makes custom the same price as template — when the bespoke website costs the same as the Squarespace website and takes the same afternoon.

The template’s value proposition does not erode. It evaporates. Not because the template is worse than it was. Because the reason you ever accepted it is gone.

That is Personal Software as a Service.

What Nobody Will Build for You

There is a category of software that has never existed, and its non-existence has always made perfect sense.

Call it the sensible-for-one. The dashboard that would transform how a particular team tracks their particular work, configured precisely to the decisions they actually make rather than the decisions a product manager imagined they might make. The workflow tool that reflects the real sequence of how a specific organization does a specific thing, rather than the idealized sequence that looks clean in a demo.

Adobe will not build Mastercard’s image editing tool. Not because it is beyond Adobe’s capability, but because the economics of building for one customer never worked. The development cost, the maintenance overhead, the support burden — these are fixed costs that only amortize sensibly across a large enough user base. Adobe builds for millions and accepts that the tool will fit none of them perfectly. Mastercard uses Photoshop and accepts the gap between what the tool does and what they specifically need, because the alternative was always a custom development budget that could not be justified.

That logic is dissolving. When execution is cheap enough, the sensible-for-one becomes buildable. Not by Adobe, who has no incentive to narrow their market. By Mastercard itself, or by whoever they ask, in a fraction of the time and cost that made the calculation impossible before. The software is not a product in the traditional sense — it will never be sold, never be marketed, never be maintained by a team of engineers whose salaries depend on its continued existence. It is simply the tool that fits, built because building it is no longer prohibitively expensive. And the sensible-for-one includes the sensible-for-career: when execution is cheap, the artifact that proves what you can do and the product you are trying to sell are the same thing. The demo is the portfolio. The portfolio is the product.

An entire industry — the software-as-a-service industry — was built on the gap between custom and template. The business model was: we will build a tool that is 80 percent of what you need, charge you a monthly subscription, and you will accept the 20 percent gap because building the 100 percent version costs more than the gap is worth. When that gap closes, the subscription model does not automatically fail. But the companies that built for that gap will have to find a different answer to the question of what they provide that you cannot now provide for yourself.

Where PSaaS Does Not Arrive

Not everywhere. And the places where it does not arrive are instructive about why.

Financial services has a layer of infrastructure — EMVCo, SWIFT, ACH, clearing and settlement systems — that has genuine structural protection. Not regulatory protection, which can be removed by a change in administration. Structural protection: a coordination solution that required decades and the participation of thousands of institutions to build. No single actor can unilaterally replace it. The alternative to the current clearing infrastructure is not a better clearing infrastructure. It is coordination failure across the entire global financial system.

The same logic operates at smaller scales. A franchise network’s legacy CRM — the system through which the franchisor tracks every franchisee’s operations, clients, and compliance — is a miniature version of the same coordination lock-in. No single franchisee can unilaterally replace it. The data is held in the franchisor’s system, often without easy export. The franchisee who wants to adopt a better tool has to run both systems during the transition, doubling operational complexity at the moment they are most vulnerable. PSaaS has to work around this kind of lock-in, not replace it — which in practice means building scrapers and integrations that extract the data the franchisee already owns but cannot easily access.

PSaaS arrives at the product layer above this infrastructure — the interfaces through which consumers and businesses interact with their money, the advisory services, the credit models. None of those are protected by the structural logic that protects the protocol layer. They are protected by incumbent advantage and switching cost, which are real but not permanent.

This distinction matters because it is the clearest boundary condition in the book. The structural protection at the protocol layer is not about execution cost. It is about the coordination cost of replacing something that thousands of institutions agreed on over decades. AI does not reduce that cost. It does not even address it. When someone claims that everything is disrupted, the protocol layer is the honest counterexample.

But the product layer above it — the layer most people in financial services actually work in — is a different story. The bank whose value was in the relationship and the judgment has an easier path than the bank whose value was in the analysis and the report. The analysis is being commoditized. The judgment is not. If you work in financial services and you are not certain whether your value is in the protocol layer or the product layer, that uncertainty is the answer.

What Changes When the Tool Is Shaped by You

When the software is shaped entirely by your context — your workflow, your specific needs, your taste in how information should be organized — something about the relationship between you and the tool changes.

Software has always been a cognitive prosthetic. You do not just use a spreadsheet; you think through it. The structure the tool provides becomes the structure of your thinking, at least for the duration of the work. Your notebook is not separate from your thinking. Your calendar is not separate from your sense of time. The tool that organizes your work is not separate from the work.

What PSaaS introduces is the possibility that the tool was shaped by the thinking before the thinking happened. Not a preference saved in settings. The software reflects a genuine model of how you work, what you value, what decisions you actually face. The gap between the tool and the thing it represents — a gap that has always been present, always required cognitive overhead to bridge — closes.

What this does to identity is genuinely unclear, and I want to say that plainly rather than resolve it prematurely.

Chapter Seven described the end of borrowed identity — professional roles carrying more self-definition than people realized, and what happens when that carrier dissolves. PSaaS introduces a related but different question. If the software is shaped by you, and the software becomes a significant portion of how you do your work, and that work is a significant portion of how you understand yourself — where does the software end and you begin? The identity that detaches from the title does not disappear. It may reattach to the tools that now carry the work — tools shaped by the person, reflecting the person, becoming difficult to distinguish from the person’s professional self.

That question is open in a way I think is important to preserve rather than resolve. The economic argument for PSaaS is solid. The question of what it means for a person’s relationship to their tools, their work, and their sense of themselves when the tools become genuinely biographical — that question I hold loosely. Chapter Ten will say so explicitly, with a confidence score attached.

What PSaaS Is Not

PSaaS is not personalization. Netflix has been doing something called personalization for years. It is a template that adjusts to your behavior. PSaaS is the absence of the template. The distinction is fundamental.

PSaaS is not a product category. There is no company that will sell you PSaaS. It is an emergent property of what happens when execution costs approach zero. You will not subscribe to it. You will arrive at it the way organizations arrive at any capability that used to require specialists: first with surprise, then with wonder at why you waited.

And PSaaS is not automatically good. A tool shaped entirely by one person’s model of their own work reflects that person’s blind spots as faithfully as their strengths. The template, for all its limitations, embodied the accumulated decisions of a product team that had thought carefully about common use cases. The bespoke tool embodies the thinking of whoever specified it, which may be sophisticated or may be a calcification of how someone has always done something in a way that prevents them from discovering a better way.

There is a harder version of this. I built a synthetic media platform in four days — fifteen AI columnists with maintained voice consistency and ideological positioning across the political spectrum. The economics work. The quality is high enough that a casual reader would not know the writers are not human. I proved the concept and refused to deploy it commercially. Not because it was bad. Because the taste function — the same function this book has been describing in rooms and teams — fired on the decision to build, not on the thing being built. The depth function heard what was possible. The taste function said it wasn’t good enough — not in quality, but in ethics. The authority function, which in this case was me and only me, said no.

That is PSaaS meeting its own boundary condition. The sensible-for-one that is dangerous-for-everyone. The framework applied not to a product decision but to a moral one, with all three functions present and held by a single person. The decision was don’t ship. The economic argument was strong. The judgment overruled it.

The assumption that personalized is always better — that assumption requires scrutiny the field has not yet given it.

The website analogy is useful precisely because it is not exotic. Everyone has either built a website, paid for one, or accepted a free template and quietly resented the parts that did not fit. The journey from bespoke to template to AI-enabled bespoke is not a journey that requires technical sophistication to understand. It requires only the willingness to notice that the reason you accepted the template was always economic, and to ask what follows when the economics change.

Custom was never the luxury. The economic barrier was the luxury. We just got used to thinking they were the same thing.

← Previous: Chapter 7: Relief or Panic — How to Know Which You Are · Contents · Next: Chapter 9: The Three People in the Room →

Relief or Panic — How to Know Which You Are [Chapter 7]

[Chapter 7 from Deliberate Alignment by Walter Reid, written in spring 2026]

This chapter is addressed to you. Not your organization. You.

Every other chapter in this book talks about organizations, systems, teams, and industries. It talks about bottlenecks and constraints and the structural logic of why methodology changes when economics change.

This chapter is different.

This chapter asks you to stop reading about the shift and start locating yourself inside it. Because the shift is not something that happens to your company and then, separately, to you. It is something that will happen to you in a way that your job title, your industry, and your methodology will not adequately prepare you for.

The question this chapter is built around is simple. When execution becomes cheap and the bottleneck moves to decision quality, do you experience that as relief or as panic?

The honest answer to that question tells you more about your situation than any organizational diagnostic. And most people, if they are being truthful, will not know their answer until the moment arrives.

This chapter is an attempt to help you know before that.

The Cover You Did Not Know You Had

There is a thing that slow systems do that nobody talks about, because it only becomes visible when the slowness goes away.

They carry you.

Not in the way a safety net carries you. More quietly than that. The process absorbs a portion of the judgment that should have been yours. The sprint planning meeting distributes the decision-making across enough voices that no single person has to be certain. The handoff from designer to developer to QA creates enough distance that by the time something ships, the original intention has been interpreted and reinterpreted enough times that nobody is entirely accountable for the final result. The timeline gives everyone cover. We ran out of time. The requirements changed. We need another sprint.

This is not cynicism. These dynamics are real and they exist in good teams, not just dysfunctional ones. Friction was never just inefficiency. It was also a buffer — a shared processing period, a political equalizer that gave everyone in the room roughly the same amount of time to figure out what they thought before they had to say it out loud.

When the friction disappears, the cover goes with it.

What is left is the judgment. Yours. Unmediated. Immediate. Visible.

For some people, this is the moment they have been waiting for without knowing they were waiting for it. The process was always getting in the way. They had the judgment. They just kept having to route it through twelve other people and wait two weeks for it to emerge on the other side, diluted.

For others, this is the moment they realize, with a specific quality of stomach-drop, that the process was doing more work for them than they knew.

Both of these people are sitting in the same meeting. Both of them are watching the same demo of what the agent built overnight. One of them is relieved. One of them is afraid. And neither of them can fully explain why they feel what they feel, because the thing that changed is invisible.

The End of Borrowed Identity

Your job title has been doing something for you that you probably have not examined.

It has been telling you and everyone around you what you are good at, what you are for, and where you fit. Not because titles are accurate — they rarely are — but because in a world of specialized roles, the title was the closest available proxy for capability. You were a developer. That meant something. It placed you in a system with legible inputs and outputs, with a defined relationship to the designer upstream and the QA person downstream, with a body of craft that took years to develop and that other people could not simply decide to do tomorrow.

That proxy is breaking.

When a designer can build the product, and a business developer can build the product, and a product manager can build the product, and each of them can do it in a morning using the same tools — the title stops functioning as a reliable signal of what a person brings that someone else cannot. The specialization that the title represented either deepens into something genuinely irreplaceable, or it becomes a credential for a capability that is no longer scarce.

There is a version of this that is already happening and that no one has named adequately. A team member on a project I was part of built a video generation tool — marketing briefs that turned into thirty-second videos, production quality that would have required a studio and a team five years ago. He built it with AI tools and his own experience on real production sets. It was genuinely impressive. And nobody needed it. Building something you couldn’t have dreamed of five years ago and having no one care is crushing. Five years ago the idea would have been pressure-tested by twenty-five people and refined, but now there isn’t connection because development is so fast there isn’t time to connect before it’s done. The new capability outpaced any framework for valuing it. The title — producer, creative director, whatever it was — no longer described what he could do, and what he could do had no place to land.

The first-order question is whether these people are more or less than they were before. That question has an answer, but it is not the interesting one.

The more interesting question is: who are they now?

Because here is what role collapse actually produces, underneath the surface disruption of jobs and org charts. It produces an identity crisis that most people will not recognize as one until it has already happened. The title was carrying more of the self-definition than most people realized. When the title stops functioning as a reliable proxy for value, the question that was always there but never urgent becomes suddenly, uncomfortably immediate.

What am I, specifically, that cannot be replicated by someone else with the right tools?

That is not a job question. It is an existential one. And the process, in its slowness, had been deferring it for years.

Five Questions

What follows is the diagnostic. Five questions an organization can ask to locate itself on the relief-to-panic spectrum. I have written them at the organizational level because that is the level at which most readers will initially receive them. But underneath each organizational question is a personal one. I will name both, because the gap between them is where the real information lives.

One: When your team reaches a decision, can you describe what changed?

The organizational version: Does your team have a legible decision-making process? Can someone joining the team six months from now reconstruct why you built what you built and not something else?

The personal version: When you were in the last important meeting, did you know what you thought before the meeting ended? Or did you discover what you thought by watching which way the room went?

There is no shame in the second answer. Most meeting culture is designed around it. But if the honest answer is that you routinely leave meetings clearer on the group conclusion than on your own position, that is information. The process was doing some of the thinking.

Two: What do you do when there is no process to follow?

The organizational version: How does your team behave in genuinely novel situations — problems that fall outside the established workflow? Do people exercise judgment or do they escalate until they find a process that fits?

The personal version: Think of the last time you were handed something with no template, no precedent, and no one to ask. What happened in your body before you started?

Relief means something was activated. Panic means something was exposed. The activation and the exposure were always there. The process was just regulating when and how often you had to feel either one.

Three: Can you describe your taste?

The organizational version: Does your organization have a point of view that is legible enough that someone outside could describe it? Not your brand guidelines. Not your values statement. Your taste — the thing you consistently choose when both options are defensible.

The personal version: If I asked you to build something without any constraints, any brief, any client requirements — just build the thing you think is most worth building — what would it be? And how quickly did an answer arrive?

Speed of answer is not the point. The point is whether an answer arrived at all, or whether the question felt somehow unanswerable without more information. Taste requires a self. When the process has been providing the constraints, discovering whether you have taste without the process requires the process to be absent.

Four: Who in your organization slows things down, and why?

The organizational version: Name the people who consistently extend timelines. Now ask honestly: are they slowing things down because they lack capability, or because they are processing something the faster people are not?

The personal version: Are you someone who slows things down? And if so, do you know why?

This is the most uncomfortable question in the five, because the people who are most at risk in the transition to fast execution are often not the ones who know they are at risk. The ones who know they are slow often know why. The ones who do not know — the ones whose process contribution was invisible even to themselves — are the ones most likely to be caught off guard.

Five: What would you build if you could build anything by tomorrow?

The organizational version: Does your company have a backlog of ideas that have been waiting for execution capacity? When that capacity becomes effectively unlimited, what gets built? Is the answer exciting or terrifying?

The personal version: Do you have something you have been waiting to make?

This is the question that separates the two populations most cleanly. The people who feel relief at cheap execution have an answer ready. They have been carrying it. They have been held back not by lack of ideas but by lack of cycles. When the cycles arrive, something in them accelerates.

The people who feel panic often find that the question itself is the problem. Not the execution. The having-something-to-make. The process was providing the brief. The client was providing the direction. The sprint was providing the container. Without those, the question of what to build next is not liberating. It is vertiginous.

Neither response is a verdict. They are a location. And knowing your location is the beginning of a useful response to it.

What the Answers Mean

If your honest answers produced mostly relief — if a brief, sharp clarity arrived at each one — you are probably someone whose judgment has been waiting for the process to get out of the way. The risk for you is different: it is the risk of moving so fast, and building so fluidly across traditional role boundaries, that you lose the collaborative texture that made your judgment accurate in the first place. Speed without friction can become speed without correction.

If your answers produced mostly unease — if the questions felt harder than they should, if you found yourself reaching for context that was not in the question — you are probably someone who has been in a productive relationship with process that you have not fully examined. That is not a failure. It is a description. The useful response is not to panic faster, and it is not to dismiss the unease as imposter syndrome. It is to figure out which parts of your current contribution are load-bearing and which parts are borrowed from the structure around you.

Most people will find both in themselves. Relief in some domains. Unease in others. The interesting work is not deciding which camp you are in. It is learning to tell the difference, in real time, between the moment when your judgment is clear and the moment when you are reaching for a process that is no longer there.

The People Who Will Not See It Coming

There is a specific population this chapter is most worried about.

They are not the people who are clearly going to be displaced — the ones whose entire role was execution of a task that AI now performs faster. Those people know who they are or they will know shortly. The visibility of their situation, while painful, makes it actionable.

The population I am worried about is the ones in the middle. The experienced practitioners whose value has always been described in terms of process knowledge. The person who knows how this organization works, who the stakeholders are, what has been tried before. The person whose contribution is real but difficult to articulate separately from the context they inhabit.

These people are not being replaced. They are being repositioned into a world where their context knowledge is more valuable than ever, but where the way that value shows up has completely changed. They used to show up in the pace and accuracy of execution. They now have to show up in the quality of a decision before execution begins.

That is not a small shift. It is a complete reorientation of where in the process their contribution lands. And most of them do not know it is coming, because nothing in the external description of their role will change until the day it already has.

If you run a small business — a ten-person agency, a regional practice, a firm of two to thirty people — you are this population. The data on small business AI adoption is genuinely conflicting, and the conflict is instructive. Some surveys show adoption jumping sharply year over year. Others show it declining as owners who tried the tools and found them unreliable pulled back. Both experiences are accurate. The tools are genuinely useful and genuinely unreliable in ways that are hard to predict without technical sophistication that most small business owners do not have and should not need.

The honest assessment: the businesses of two to ten employees that are not using AI at all are roughly where they were with cloud software in 2012 — behind, but not yet at the point where the lag is competitively disqualifying. That window is closing. The competitor who figured out which tools actually work for your specific business and integrated them into their operations has a cost advantage and a speed advantage that will compound. But here is the part that matters for this chapter: the small business owner whose competitive advantage was always judgment, relationship, and specialized knowledge — rather than execution capacity — is the one who looks at this moment and sees opportunity rather than threat. The ten-person agency that can now produce what a fifty-person agency used to produce is experiencing relief. The fifty-person agency is the one that should be reading these five questions carefully.

What You Do With the Answer

If you are reading this and you recognize yourself in the middle — if you are the person who knows more about the organization than you can easily articulate, who has been carrying context for years in a way that has always been valued but never quite made explicit — this is your chapter. Not because it is a warning. Because you are exactly the person whose judgment becomes most important when the process stops doing the distributing.

The question is whether you know that. Whether you can locate it. Whether you can make it legible — to yourself first, and then to the room.

The shift is asking you to externalize something you have always carried internally. That is uncomfortable. It is also the work.

I can write that with some authority because I have done it. Both sides. I was let go from Mastercard in August 2023, after seven years on a product I had worked on passionately. For eighteen months I did not have an identity. I could not find a job — because the box I had been working in had either changed in the seven years I was inside it or I had never fit it to begin with. I experienced relief and panic simultaneously, which I did not know was possible until it happened. What I found, eventually, was the function underneath the title. I am an optimizer and a reframer — the person you bring in to look at a problem and help you work through it. I just didn’t know it until the title was gone, and discovering it was not a clean process. Watching what I thought I was disappear was very, very hard. And likely not easier with time.

Most people, if they answer those five questions honestly, will not land cleanly in one column or the other. The relief and the panic will coexist, pointing in different directions at different parts of the same self. The relief pointing at where the judgment was always yours. The panic pointing at where the process was doing more work than you knew.

The audit — what do I know, what have I been carrying, what in my contribution is genuinely mine — that work is yours to do.

The process was never the point. It was the container. What it was containing is the question.

← Previous: Chapter 6: The Thousand Conversations Problem · Contents · Next: Chapter 8: Personal Software as a Service →

The Thousand Conversations Problem [Chapter 6]

[Chapter 6 from Deliberate Alignment by Walter Reid, written in spring 2026]

AI does not fix unclear thinking. It amplifies it.

Somewhere in your organization, right now, thirty conversations are happening in parallel.

Each person, with their AI tool open in a separate tab, is asking a version of the same question the organization is supposedly aligned on. Each is receiving an answer shaped by the specific way they framed the question, the context they brought to it, the assumptions they did not know they were making. Each answer is locally coherent. Each one makes sense given the conversation that produced it.

Collectively, they are pointing in slightly different directions.

This has always been true. Organizations have always been collections of parallel, partially overlapping mental models of what the organization is doing and why. The watercooler conversation that produced a different understanding than the all-hands. The email thread that resolved something the official process had not gotten around to resolving. The tribal knowledge that lived in the heads of the people who had been there longest and evaporated when they left.

What is new is the speed at which each conversation now produces artifacts.

Before, unclear thinking moved slowly. A misaligned understanding of what the product was for would take weeks to materialize as a feature nobody wanted. There were checkpoints — reviews, handoffs, the moment where someone would say, wait, that is not what we meant. The friction was expensive in time and morale, but it was also a correction mechanism. Slowness caught errors that speed would have shipped.

Now the artifact follows the conversation almost immediately. The unclear thinking is instantiated — made real, built, sometimes shipped — before anyone has had a chance to ask whether it was right.

In the Zansei project, this dynamic became visible on a specific Thursday. One person had spent the week building a research report — seventeen pages analyzing the site’s copy, with the second half promised for the following week. Another person had been running ads at a thousand dollars a week. Zero people had completed the funnel in the previous seven days. A third person had been exploring a new feature direction that the founder had mentioned in passing on Monday. Each of these efforts was internally coherent. Each person could explain what they were doing and why. Together, they were spending money to drive traffic to copy that was being researched rather than fixed, while the product’s scope expanded in a direction nobody had agreed on. The backlog was no longer a prioritization tool. It was an anxiety archive accumulating in three different directions simultaneously.

That is the thousand conversations problem. And it is not a coordination problem.

It is a meaning problem wearing coordination’s clothes.

Why the Distinction Matters

Coordination problems have known solutions. You establish a process, a single source of truth, a set of handoffs with clear ownership. You standardize the input and the output converges. Organizational design has been solving coordination problems for a century.

Meaning problems are different. They are not about who does what or when. They are about whether the people doing the work share a sufficient understanding of why — of what the work is actually for, what success would feel like from the outside, what they would sacrifice and what they would not.

Meaning cannot be standardized. You can issue a directive that creates the appearance of resolution while the actual divergence continues underneath, now invisible because everyone has learned the right vocabulary.

The reason AI amplifies this specific problem is that the tools are exceptionally good at producing outputs that feel coherent. A person with an unclear understanding of the product vision, working with an AI assistant, will produce work that is internally consistent, well-structured, and legible — and pointed in the wrong direction. The professional surface has never been easier to achieve. The gap between professional surface and genuine alignment has never been harder to detect.

The Zansei researcher’s seventeen-page report was well-structured. It had sections and findings and recommendations. It was also answering a question nobody had agreed on, produced by someone who had no way to know the question was wrong because the question was never made explicit. The report was a coordination success — the researcher coordinated with the tools beautifully — and a meaning failure. The meaning of what the research was supposed to accomplish had never been established clearly enough to guide it.

Another team member was building something genuinely impressive in parallel — a video generation tool using Runway, Veo3, and a custom renderer. Marketing briefs that turned into thirty-second videos. High production quality. The kind of output that would have required a studio and a team five years ago. But he was working in a silo, disconnected from clients and product direction, solving a problem no one had validated. He had heard people mention wanting video content and started building. His lived experience on real production sets made him feel powerful with the AI tools, and the power was real — but it was not connected to the room.

The last ten percent is ninety percent of the effort, and while the work felt productive at first, the problem was that his solution was looking for a problem. He was not a developer or a product person or close to the client. He was building things he had heard people needed but with no validation, because there was no structure connecting his capability to the team’s direction. The thousand conversations problem embodied in one person: locally brilliant, collectively disconnected.

The Temptation of Standardization

The instinctive organizational response is standardization. One prompt template. One AI tool. One system of record that everyone queries. One voice that speaks for the organization’s intent so that everyone’s parallel conversations start from the same place.

This is not wrong. It is incomplete. And the part it misses is the part that matters.

The parallel conversations are not a problem to be eliminated. They are a resource to be synthesized. Each person who approaches a question from a different angle — the one who treats nuance as a feature, the analytical mind, the contrarian who sees what consensus is missing — each of these people is producing signal. Signal that a standard template would suppress before it could be captured.

Standardize the input and you get consistent output. You also get sterile output. An organization that has optimized its parallel conversations for convergence has also optimized them for the elimination of the unexpected. And in a world where judgment is the scarce resource, the unexpected is where the value lives.

The solution to the thousand conversations is not to make them all the same conversation. It is to build the infrastructure that lets them remain different while still being synthesizable.

What That Infrastructure Looks Like

The OpenAI harness engineering team — introduced in Chapter One — encoded their direction in a repository document that any agent — human or AI — could read before beginning work. Not documentation for its own sake. A living encoding of direction, specific enough that every agent working from it would produce consistent results without continuous re-alignment. Their early approach — one large instruction file containing everything the agent needed to know — failed. When everything is marked important, nothing is. They replaced it with a structured directory: a short entry point that served as a map, with pointers to deeper sources of truth. Design decisions documented not just as outcomes but as reasoning. Architecture described not just as what exists but as the principle behind what exists, so that the next decision made by a different person in a different context would be consistent without being identical. That is progressive disclosure applied to organizational intent — the same principle that applies to human teams.

The insight underneath that example applies to human teams with at least as much force as it applies to AI agents: anything that is not encoded explicitly enough to be read by someone who was not in the room effectively does not exist.

This is not metaphorical. During the RouteForge development described in Chapter Nine, I built a new client portal — designed it, coded it, integrated it. When I was finished, Claude Opus informed me that a client portal already existed in the codebase. It was just not documented and not connected to anything. Something that literally existed in the codebase did not functionally exist because no one had encoded it legibly enough for anyone — including the AI — to know it was there. The organizational legibility argument applies to code as much as it applies to teams. What is not encoded does not exist, even when it does.

The Slack thread that aligned the team on a decision but was never written down — it does not exist for the person who joined three months later. The whiteboard session that resolved the ambiguity in the product brief — it does not exist for the team member who was traveling that week. The institutional knowledge that lives in the head of the person who has been there longest — it does not exist for anyone the moment that person walks out the door.

Organizations have always known this. The practice of knowledge management is decades old. But the urgency was manageable when execution was slow, because the gap between losing the knowledge and feeling the consequence was wide enough to catch and correct.

When execution is fast, that gap closes. The undocumented decision becomes a shipped feature before anyone realized the decision had been made implicitly. The divergent understanding becomes a launched campaign before the synthesis that would have caught it has had a chance to happen.

What this requires in practice starts with presence. I have been in Click to Pay meetings with twenty people in person, and sometimes there is a legitimate dialog. But I don’t often hear from people on the conference line — not because they don’t have ideas, but because they aren’t present. Both literally and figuratively. They would need to shout on the phone just to make their presence felt, and if they had that type of will to be heard on the phone, they would have been in the room anyway. Presence is self-selecting. Remote participation in alignment work is observation with the appearance of inclusion. The infrastructure that makes the thousand conversations synthesizable starts with the people who are doing the synthesizing actually being in the room where the synthesis happens.

Beyond presence, the infrastructure requires legibility — not comprehensiveness. The instinct when asked to make something explicit is to make everything explicit — the complete knowledge base, the exhaustive style guide, the documentation that covers every edge case. That instinct fails for the same reason the OpenAI team’s single instruction file failed. When everything is marked important, nothing is. The file became a graveyard of rules that may or may not still reflect reality, and nobody could tell which was which.

The solution is structural: a short entry point that serves as a map, with pointers to deeper sources of truth. That is organizational legibility. Not transparency — everyone can see everything. Not documentation — there is a record of what was decided. Legibility: the organization’s intent encoded in a form that survives the people who hold it.

The Person Who Reads the Conversations

There is a person this chapter has been describing without naming.

In the previous era, they existed in the translation layers between roles. The senior developer who understood what the business actually needed. The product manager who held the tension between what users said they wanted and what the data showed they did. The account director who maintained a relationship sophisticated enough to know what the client had not yet said.

These people were synthesizing — reading the parallel conversations, finding the signal in the divergence, surfacing the question that everyone was dancing around without asking, and converting the resulting clarity into a direction the rest of the organization could move in.

As the translation layers dissolve — as the designer and the developer and the account executive converge toward a shared capability — this work does not disappear. It becomes more important, more visible, and more load-bearing. Because the parallel conversations are happening faster, the artifacts are materializing sooner, and the cost of letting the divergence compound is higher.

The skill is not technical. It is closer to curatorial, or editorial — something that has not quite found its vocabulary because it has only recently become urgent enough to require one. It requires the ability to hold contradictory inputs without prematurely resolving them. To distinguish between productive tension — divergence that is generating signal — and destructive divergence that is consuming energy without producing meaning. To know when the conversations have generated enough to act on and when they are still processing something important that premature synthesis would foreclose.

This is not a new kind of person. They have always been in your organization. What is new is that their work, which was previously invisible because it happened in the gaps between the legible processes, is now the work that everything else depends on.

In film production, the person who holds this function has a title: second assistant director. Not the creative lead. Not the one whose name goes on the poster. The one who holds the entire production’s logistics in her head — who knows that tomorrow’s call sheet conflicts with a location change the director mentioned in passing, who reads across every department’s needs simultaneously and surfaces the collision before it becomes a cost. The function is synthesis. The title undersells it. It always has.

The version of this person in your organization may be the one who is most skeptical of the AI tools — not because they don’t understand them, but because they understand what gets flattened. The people best suited for this work are not always the ones who embrace the tools that accelerate it.

Find them. Give them the room.

Or, if you are that person: you already know. The question is whether the organization around you knows yet.

Before Anyone Opens a Laptop

This is where the chapter connects to Deliberate Alignment as a practice rather than a philosophy.

The thousand conversations problem cannot be solved in the meeting where the work gets reviewed. It cannot be solved in the retrospective where the misalignment becomes visible. It cannot be solved in the integration moment where the separately-built artifacts collide and the distance between them becomes apparent.

It can only be solved before it starts. Before the conversations diverge past the point of easy synthesis. Before the artifacts begin to accumulate in directions that will cost weeks to unwind.

And here is the part that is uncomfortable to say plainly: most organizations do not currently do that work. They approximate it. They hold the meeting that is supposed to produce alignment and leave with the feeling of having achieved it without checking whether what everyone took out of the room was actually the same thing. They produce the strategy document and assume that reading it produces the understanding it was meant to convey. They rely on the accumulated shared context of people who have worked together long enough to develop a kind of shorthand — and discover the limits of that shorthand the moment the team changes, or the pace accelerates, or the AI agents begin executing on the shorthand as if it were explicit when it never was.

Coordination problems have known solutions. Meaning problems might not. That is not a comfortable thing to write in a methodology book. But the honest version of what this chapter is saying is that the thousand conversations are already happening, the artifacts are already accumulating, and the infrastructure that would make them synthesizable rather than incoherent is, in most organizations, not built yet and not being built.

The conversations are not waiting for the organization to be ready.

And the synthesis problem does not stop at the organizational level. The person running multiple AI conversations in parallel — each producing coherent artifacts, each pointed in a slightly different direction — is the thousand conversations problem at the scale of a single mind.

The question is whether what they produce, when they converge, will be the thing the organization meant.

Coordination problems have known solutions. Meaning problems require something the field has not yet fully described. The conversations are not waiting for the description to arrive.

← Previous: Chapter 5: The Client in the Room · Contents · Next: Chapter 7: Relief or Panic — How to Know Which You Are →

The Client in the Room [Chapter 5]

[Chapter 5 from Deliberate Alignment by Walter Reid, written in spring 2026]

The conversation was always the specification. We just couldn't act on it fast enough for that to matter.

Go back to the scene in Chapter One. The new business developer, the client, the product built while the meeting was still happening.

You have the vocabulary now. Read it differently.

The new business developer was holding the depth function — hearing beneath what the client said to what the client meant, tracking the anxiety underneath the brief, understanding which part of the stated requirement was the real requirement and which part was the client’s attempt to describe something they didn’t yet have words for. The conversation wasn’t productive because it was well-facilitated. It was productive because the person across the table was doing something specific and skilled: listening at a depth the conversation was not happening on.

The product that was built during that meeting was not built from the requirements. It was built from the understanding. In every previous version of this process, those two things diverged the moment the meeting ended. The requirements were written down, handed off, and the understanding stayed in the room with the people who had been there. By the time the product arrived, months later, what was built was faithful to the document and foreign to the need.

Now the understanding doesn’t have to survive the handoff. It becomes the product in the room where it was formed. And that changes what the client relationship is for.

What Clients Actually Say

Customers lie. Not maliciously. Not even consciously. Rob Fitzpatrick’s The Mom Test makes the observation that practitioners find either obvious or devastating depending on how recently they have been burned by it: the human instinct when someone asks what you want is to describe something that sounds reasonable rather than something that is true.

The client who says “I want a turnkey marketing execution solution” is not describing a product. They are describing a feeling — the feeling of not having to worry about whether their marketing is working. The product they are imagining is one expression of that feeling. It may not be the best expression. It may not even be a coherent expression. But the feeling is real, and the feeling is what they are actually hiring for.

Christensen called this jobs to be done. The job that Zansei’s clients are hiring for is not “produce a marketing plan.” It is “give me confidence that my business will grow.” A marketing plan might fulfill the stated requirement and fail the actual job entirely, if it arrives as a document that increases uncertainty rather than relieving it.

The person who hears “turnkey execution” and knows the real job is confidence — that person is holding the depth function. And the depth function, in the client relationship, is the hardest work in the room.

The International Client

Consider the international client who came to Zansei. A business operator based outside the United States, trying to reach American consumers, who arrived for a marketing brief and left the first conversation wanting something else entirely — not a plan, but the execution of the plan, and not just for herself but resellable to her own clients.

What she said: “I want a turnkey solution I can offer to my clients.”

What she meant: I am trying to grow a consulting practice in a market I don’t fully understand, and I need something I can trust enough to put my name on.

Those are different conversations, and they produce different responses. The first is a product scoping discussion. The second is a trust conversation. The client who needs to put her name on the product needs to believe it reflects her judgment, not just that it functions. She needs to understand it well enough to defend it. She needs to feel that she has participated in its creation rather than purchased it from a vendor.

The person who can hear the second conversation while the client is having the first one — and then bring what she heard back to a team whose product is still being defined — is doing something that looks deceptively simple from the outside. A good note-taker. A careful listener. What they are actually doing is holding multiple conversations simultaneously: the one the client is having, the one beneath it, the one the team needs to have, and the one the founder will want to have when he hears there is an international client with ambitions he has not yet imagined accommodating.

This is the hardest job in the model. Not the most technical. Not the most strategic in the conventional sense. The hardest.

The Failure Mode

There is a specific way the depth function breaks under the conditions this book describes, and it is worth naming directly.

When execution becomes fast enough that every client request seems immediately accommodatable, the depth function stops asking whether the request is the right request and starts describing how the request could be fulfilled. The shift is subtle. It feels like responsiveness. It is the abandonment of the most important question.

The legal profession has been living a version of this dynamic for years, though the vocabulary is different. A litigation team I spoke with recently described cutting complaint response drafting time from sixteen hours to three to four minutes using an AI system. The efficiency gain is not incremental. It is transformational. And when that gain accumulates across a firm’s practice, it exposes something the billable hour had been quietly concealing: the value was never in the drafting. It was in the judgment that preceded the drafting — knowing which arguments to make, which facts to emphasize, which strategy would serve the client’s actual interest rather than the interest they walked in describing. The billable hour bundled judgment and execution together. When execution approaches zero, the bundle splits, and the question of what the lawyer was actually selling becomes suddenly, uncomfortably clear.

The same dynamic applies to every person holding the depth function. The temptation, when building is instant, is to build first and evaluate later. To hear “turnkey solution” and start building the turnkey solution, rather than staying in the harder conversation about what the client is actually hiring for. Speed makes this temptation feel rational. It is the opposite of rational. It is the fastest possible route to building the wrong thing.

The SOW That Writes Itself

There is a traditional sequence in professional services: discovery process, brief, review, statement of work, negotiation, project begins. That sequence made sense when execution was expensive, because the cost of starting wrong was high enough to justify the overhead of establishing direction before starting.

In the model this book describes, the sequence collapses. Not because the document is unimportant — it is more important than ever, because it is now the primary mechanism by which the understanding in the room survives contact with the people who were not in the room. But because the document is no longer the output of a separate process that happens after the conversation. It is the output of the conversation itself.

The statement of work that writes itself during the client conversation is not a transcript. It is a structured encoding of what was understood: what the client actually needs, what job they are hiring for, what constraints are real and which are negotiable, what success looks like from their perspective and what it looks like from ours.

And this: what we are not doing and why.

That last item is as important as anything else in the document. Every scope expansion in the Zansei project began as a decision that was never closed — a direction that was raised, discussed, and set aside without being written down as set aside. The next conversation arrived with no record of the setting aside, only the raising, and the direction that had been declined was treated as still available. The SOW that writes itself must write both halves of every decision: not just what we will build, but what we will not, and why, while the why is still in the room.

The person who can produce this document in real time — without losing the thread of the conversation, without making the client feel they are being processed rather than heard — is translating depth into legibility at the moment depth is produced. That is not a clerical function. It is the function that determines whether the alignment produced in the room survives into the execution that follows.

The Client as Participant

The client is not the object of Deliberate Alignment. They are a participant in it.

This distinction changes what the client’s presence in the room produces. In the requirements-gathering model, the client was interviewed. Their answers were recorded. They were the source of information that would be processed elsewhere. They were consulted, not included.

In Deliberate Alignment, the client is in the room where the alignment is being built. And this changes what is possible, because the client’s understanding of their own need is incomplete in ways that only become visible in a real conversation. The client who said “turnkey execution” does not know that what she means is trust until someone in the room reflects it back to her at the right moment. The understanding that makes the solution right is not sitting in the client’s head waiting to be extracted. It is produced in the conversation. Which means the client has to be in the conversation — not just at the beginning of it — for the solution to be built from the thing that actually matters.

The international client, in the right room, would tell you that what she needs is to not feel alone in a market she doesn’t understand. That she is building a practice on borrowed confidence — confidence borrowed from the tools and partners she works with, which she can only lend to her clients if she trusts it herself. That what she is asking for when she says “turnkey” is not automation. It is a partner who knows more than she does and will not make her look bad in front of her clients.

That is a buildable product. It is a completely different product from turnkey execution. And it is only visible from inside the right conversation.

What This Requires of the Room

The depth function, when it is working, is invisible. The meeting goes smoothly. The client leaves satisfied. The direction is clear. Nobody sees the specific quality of listening that produced those outcomes because the outcomes look like they just happened.

When the depth function is absent, its absence is also invisible — until the sprint review, months later, when the thing that was built is demonstrably not the thing that was needed, and everyone is genuinely confused about how that happened.

In the Zansei project, the vacancy was eventually filled — not perfectly, but enough. In February, much like a lifeguard pointing at a bystander and saying you, call 911, I pointed at the team member closest to the client and said, in effect, you are depth — without yet having the term for what I was assigning. She ended up holding the client relationship directly, conducting in-person and online surveys, maintaining the connection to the business and customer insight that the rest of the team was too far from the product to see. During Thursday meetings, we worked together on survey design — shaping the questions that would surface what the client actually needed rather than what they said they wanted. The depth function found its holder through assignment, not emergence. Someone had to name the vacancy and point.

Now compress that timeline. When execution takes hours instead of months, the absence of the depth function does not produce a slow accumulation of misalignment that becomes visible at the sprint review. It produces an artifact — built, shipped, delivered — that is faithful to what was said and foreign to what was meant. The misalignment arrives as a finished product. The client’s reaction to it is not “let’s iterate.” It is “you didn’t understand.”

That reaction is correct. And the cost of it, in the relationship and in the direction and in the trust that takes months to rebuild, is higher than the cost of the artifact that was wrong.

This is why the depth function is the hardest job. Not because listening is difficult, though it is. Because the consequence of its absence has accelerated from a slow correction to an immediate rupture, and the person holding it has no buffer. The process that used to catch misalignment — the handoff, the review, the sprint, the course correction — those buffers are gone. What is left is the conversation, and the quality of the listening in it, and nothing else.

The conversation is the specification. It always was. We just had enough time, before, to discover when the specification was wrong.

That time is gone.

The client doesn’t know what they need until the right conversation surfaces it. The conversation is not a step in the process. It is the process.

← Previous: Chapter 4: Deliberate Alignment · Contents · Next: Chapter 6: The Thousand Conversations Problem →

Deliberate Alignment [Chapter 4]

[Chapter 4 from Deliberate Alignment by Walter Reid, written in spring 2026]

The room is not where the work gets reported. It is where the work begins.

There is a name for what happens in the best two and a half hours of the Thursday meeting.

Not a new name. The thing it describes has been happening in good rooms for as long as there have been good rooms. What is new is the urgency of naming it — the specific pressure that arrives when execution becomes fast enough that the thing which was always most important can no longer be deferred past the first conversation.

Deliberate Alignment is a methodology organized around the quality of the decision before execution begins, rather than the management of execution itself. The unit of work is not the sprint. It is the room — the specific convergence of the right people, with visible work, making real decisions that an agent can act on before anyone leaves.

That definition is precise. It is also incomplete without understanding what it is not.

It is not better meetings. Meetings, as they exist in most organizations, are designed either to communicate decisions already made elsewhere or to create the appearance of collective ownership for decisions that will be made elsewhere anyway. The calendar entry and the agenda and the agreed-upon next steps are theater when the real decision has already happened in a hallway or a direct message. Deliberate Alignment is not about running that process more efficiently. It is a different process.

It is not a workshop methodology. Design sprints, war rooms, hackathons — these are relatives of the same instinct, and the iHeart story shows where that instinct comes from. The hackathon changed what was being decided on. A tangible prototype reduces decision latency by changing what the process has to evaluate. Deliberate Alignment takes that instinct and makes it the entire methodology rather than a periodic intervention.

And it is not a framework for eliminating disagreement. The room that produces genuine alignment is not a room where everyone agrees. It is a room where the disagreement is legible — where the tension between perspectives is visible to everyone, where it can be evaluated rather than avoided, and where someone with the authority to commit can make the call and have it mean something. Alignment is not consensus. It is shared understanding of a direction, including an understanding of what was decided against and why.

The Three Functions

Every room that has ever produced genuine alignment has contained three functions. Sometimes three people, sometimes fewer. The number of people is not the point. The functions are.

The first is the function of depth. Someone in the room has to understand what the client, the user, the stakeholder needs beneath what they say. Not the stated requirement. The actual pressure. The competitive anxiety that didn’t make it into the brief. The internal politics that will determine whether the right solution gets adopted or quietly shelved.

In the Zansei project, this function belongs to the person who understands that Zan’s requests for new features are not really product requests. They are expressions of a founder’s anxiety about whether the thing he has built will matter. When he says “now let’s add e-commerce,” he is not describing a product roadmap. He is describing fear that the current product is not enough. The person who hears that and responds to the fear rather than the feature request is doing the depth function. The person who adds e-commerce to the backlog is not.

This function has been systematically undervalued because it is invisible when it is working. The meeting goes smoothly. The client leaves satisfied. The direction is clear. Nobody sees the specific quality of listening that produced those outcomes because the outcomes look like they just happened.

The second is the function of taste. Someone in the room has to be willing to say when the answer is defaulting to mediocrity. Not the obvious wrong answer — that is easy to catch. The answer that is technically correct, defensible, and insufficient. The direction that will satisfy the sprint review and disappoint the user.

This function is the most politically exposed of the three because it requires pushing back against the path of least resistance in a room where the path of least resistance is what everyone wants to take. It requires a specific kind of standing — not authority, exactly, but credibility. The person who says “that’s not good enough” has to have earned the right to say it. Which means the function cannot be assigned. It can only be recognized.

In the Zansei project, this function is currently vacant. Not because the people in the room lack taste — several of them have excellent taste. But nobody has been given, or taken, the explicit role of maintaining the product’s integrity against the gravity of scope expansion. When Zan expands the scope, there is no voice in the room whose designated function is to say “that’s a different product and building it will cost us the product we have.” That absence is structural, not personal.

The third is the function of authority. Someone in the room has to be able to say yes and have it mean yes. Not yes pending approval. Not yes subject to review. Yes, this is the direction, and the execution can begin.

This function sounds simple. It is the most complicated of the three in practice, because authority without understanding is not authority — it is permission for the wrong thing. The person who can commit must be present in the room where the alignment is being built, not receiving a summary afterward. The summary degrades the alignment. It removes the context that made the direction legible and replaces it with a conclusion that looks like the same thing but isn’t.

Zan is the authority function in the Zansei project. The Thursday meeting works, when it works, partly because he is there — present, engaged, making calls in real time. The meetings where he is absent or distracted produce decisions that look like decisions until he encounters them later and reframes them from a different context. The alignment wasn’t built with him. It was built around him. Those are not the same thing.

Understanding Zan requires accepting something the framework does not make obvious: authority without depth is not always a vacancy to be filled. Sometimes it is the permanent operating condition of the person who holds the authority function. Zan is the type of person who tells you to go take pictures in Central Park. And when someone asks which part — the geese, the lake, the people, the trees — he says “Central Park.” Or worse: “I told you Central Park, what don’t you understand.” He does not know what he wants until he sees options. He has never known. He is not going to start.

This type of person thrives with AI, assuming there are people who can translate those words to actions. Before, you had to go photograph everything in Central Park and return like an episode of Mad Men, lay the options on his desk, and have him select. Now the options can be generated in minutes. The translation layer — the people who hear “Central Park” and understand what questions to ask before anyone starts shooting — is more important, not less. The framework’s job is not to fix the founder. It is to build the translation layer that lets the founder’s instinct become actionable without requiring the founder to articulate what he cannot articulate.

The danger is what happens when Zan sees the speed. If you can provide a full prototype in a week that would have taken months before, he will expect the mobile app or the multi-tenant system done by next Monday. Expectation inflation — the authority function seeing AI-enabled speed on one task and generalizing it to everything — is a failure mode the framework has to absorb. The translation layer has to manage not just the founder’s direction but the founder’s sense of what is possible.

Why One Person Can Hold Two Functions

The three functions are not job descriptions. They are capacities that need to be present in the room. The same person can hold more than one.

The person who understands what the client needs beneath what they say often also has the taste to recognize when the answer is insufficient. Those two functions travel together in people who have spent significant time close to users — who have developed their taste through repeated exposure to the gap between what was built and what was needed.

The person with authority to commit sometimes also holds the depth function — the founder who has been closest to the problem, who understands the user’s anxiety because they shared it before they built the solution. That combination is powerful when the authority is paired with genuine understanding and dangerous when it isn’t. Zan at his best is both. Zan on a day when he is running on pattern-matching from a single data point is the authority function operating without the depth function, and the direction that emerges will be confident and wrong.

What the framework requires is not that three distinct people occupy three distinct boxes. It requires that when any significant decision is being made, all three functions are present and active. The check is simple: is someone listening at depth, is someone willing to say when it isn’t good enough, and is someone able to commit with genuine understanding of what they are committing to? If any of those questions has no answer, the room is not ready to produce alignment.

The framework requires that the functions be present. It does not require that they remain distributed across multiple people indefinitely.

The New Prioritization Question

The old prioritization question — given scarce execution capacity, what should we build first? — dissolved in the previous chapter when the denominator disappeared. The new question is: given that we can build almost anything, what should we decide to build at all?

That is not a ranking problem. It is a decision problem. And it requires the three functions to be present. The depth function to understand what building this will actually mean for the person it is built for. The taste function to assess whether this is the direction that will matter or merely the direction that is available. The authority function to commit to one direction and foreclose the others.

The decision that resolves ambiguity for every execution that follows it is worth more than the decision that resolves one task cleanly. The decision that lets the room disperse with shared understanding of what the next month looks like is worth more than the decision that produces one feature quickly.

This is what the Zansei team is missing. Not execution capacity — the team can build almost anything in hours. What it is missing is the decision that would let every member build confidently in the same direction without requiring constant re-alignment. The Thursday meeting produces that decision, sometimes, for a few days. The methodology is the attempt to produce it reliably.

What the Room Requires

A room that produces genuine alignment requires that the work is visible. Not described — visible. The prototype, the draft, the live system, the actual artifact that the decision is being made about. The client who is reacting to a description is imagining something. The client who is reacting to a prototype is evaluating something. These produce different quality decisions.

It requires that the people in the room can make the decision. Not advise on it. Make it, with authority that holds outside the room. A room full of people who are present to inform a decision that will be made by someone who is not present is not an alignment session. It is a research process that will produce a summary that will degrade the alignment before it reaches the person who can commit.

It requires that the decision survives the room. The output of a Deliberate Alignment session is not minutes. It is a shared understanding explicit enough to be acted on independently — specific enough that two people who were in the room can make separate decisions the following day that point in the same direction without checking with each other first.

And it requires that the people in the room trust each other enough to say what they actually think. Psychological safety — the condition where people believe they will not be punished for speaking up — is not a soft organizational concern in this context. It is load-bearing. The room that cannot hold genuine disagreement cannot produce genuine alignment. What it produces instead is the appearance of alignment, which is more dangerous than acknowledged disagreement because it is invisible until the execution is already underway in the wrong direction.

The Framework Applied to Zansei

The Zansei project is not a success story. It is a work in progress, and the framework is being tested on it in real time.

What the Thursday meeting gets right: it assembles most of the functions. The depth is present. The authority is present when Zan engages rather than absorbs. The work is visible on the screen at the end of the table. For two and a half hours, the room functions as the methodology describes.

There was a Thursday in March where it worked. The business consultant, who held the client relationship, asked the developer to produce a brand document and a white-label overview — something a new partner could use to get up to speed quickly. The request was reasonable. The timeline she was imagining was a week. The UX lead, who could have built it with her eyes closed, sat quietly. The developer nodded.

I was annoyed before I understood why I was annoyed. The business consultant had been in every meeting — she was the person closest to the partner’s needs. The UX lead was sitting right next to her, the person who could articulate the brand’s voice in her sleep. And both of them had deferred the ask to the developer. Not because he knew the brand better. Because producing a deliverable still felt like a technical act, even when the deliverable was pure judgment. The knowledge to produce those documents was in the room. It had been in the room for months. The taste and the depth were present. They just didn’t recognize themselves as sufficient.

So I did it while the conversation continued. Opened Claude, shared screenshots of the product flow, attached two media briefs as examples, and asked for both deliverables. Before the meeting moved to the next topic, both documents were in Slack. Not perfect. Good enough to use, good enough to improve, produced in five minutes from the understanding that was already present in the room.

The room went quiet for a moment. Not because the documents were impressive — they were functional, not beautiful. Because the speed made visible something the team had not confronted directly: the gap between what they knew collectively and what they were producing was not a capacity problem. It was a willingness problem. The understanding was there. The encoding was not.

And then the thing I did not say out loud, because it was not the moment: I could produce those documents because I held all three functions simultaneously — I understood what the partner needed, I could judge whether the output was sufficient, and I had the authority to ship it without asking. The business consultant had the depth. The UX lead had the taste. Both were in the room. Neither acted. So I held all three, and for five minutes the framework worked perfectly — and the question I could not stop thinking afterward was why I had needed anyone else in the room at all. That question is not one this chapter can answer. But it is one the book will return to.

What it gets wrong: the taste function is not held consistently. The decision that the meeting produces is not always encoded explicitly enough to survive the week. The authority that commits on Thursday sometimes re-opens what was committed on the following Monday, having encountered a new piece of information that was not in the room. The alignment is real but fragile — produced by proximity and presence, not by a system designed to sustain it. Initially, the Thursdays were demos without direction — work shown, reactions given, nothing decided that would hold past the weekend.

The fix is not to have longer meetings or more meetings. It is to be more deliberate about what the meeting is for. The first fifteen minutes of ritual — what did you do, what will you do, any blockers — is not alignment work. It is status reporting that could be asynchronous. The two and a half hours in the middle is the alignment work.

The more fundamental fix is to name the vacancy. The taste function is not held. Nobody in the room has the explicit standing to say “that is a different product” when the scope expands, and have the authority function hear it as information rather than resistance. Without that voice, the backlog of features and client requests becomes what the previous chapter called an anxiety archive — not a prioritization tool but a growing list of things that might matter, maintained by a team that cannot say no. Naming that vacancy is not a personnel problem. It requires a conversation about what the room needs that it does not currently have, and who is willing to hold it.

That conversation is itself a Deliberate Alignment session. The methodology is recursive. The room that designs the room is the same kind of room as the room it is designing.

The Zansei project will continue after this book is written. Some Thursdays will produce the two and a half hours of real alignment. Some will produce demos without direction.

What the framework offers is not a guarantee that every room will work. It is a description of what a room that works requires, specific enough that you can look at your own room and ask which of those things are present and which are absent. The three functions. The visible work. The decision that survives the room. The trust that makes genuine disagreement possible.

If all of those are present, something will happen in the room that is difficult to describe from the outside and immediately recognizable from the inside. The options become real. The direction becomes clear. The people leave knowing what they are building and why, and the knowledge is specific enough to act on without checking back.

That is what the Thursday meeting feels like in its best two and a half hours. Not efficient. Not optimized. Alive.

It is not a meeting. It is the work.

The room that produces alignment is not the room where everyone agrees. It is the room where the decision is made by the people who have to live with it, in the presence of everything they need to make it well.

← Previous: Chapter 3: What Agile Got Right (And Why It’s No Longer Enough) · Contents · Next: Chapter 5: The Client in the Room →

What Agile Got Right (And Why It’s No Longer Enough) [Chapter 3]

[Chapter 3 from Deliberate Alignment by Walter Reid, written in spring 2026]

This is an autopsy, not a eulogy. The patient solved the right problem. The problem changed.

Every Thursday afternoon, a small team working on a consulting project meets for three hours around a rectangle table with a screen at one end.

For the first fifteen minutes, they run through the ritual: what did you do last week, what will you do this week, any roadblocks. It is a standup stretched to fill its container. It produces the expected output — a shared sense that everyone is accounted for, that progress is happening, that the team exists.

Then something shifts.

From about fifteen minutes in to fifteen minutes before the end, the meeting becomes something else. The screens come out. People show what they actually built. The work connects to other work. Decisions get made in real time because the options are visible to everyone simultaneously. The person who has been working in the background through most of the meeting — quietly building in his code editor while the others talk — surfaces what he has done and it changes what everyone thought was possible.

For two and a half hours, the room works. The alignment that the rest of the week fails to produce arrives, unbidden, in the space between the ritual and the closing roundup.

Then the meeting ends. The week resumes. The work continues, parallel and mostly uncoordinated, until the next Thursday.

This is not a description of agile failing. This is a description of agile’s best instinct — get the people together, make the work visible, let alignment emerge from proximity — fighting against the container that agile built to hold it. The sprint is a two-week version of what this team does in three hours. The standup is a daily version of the check-in that the first fifteen minutes provides. The retrospective is the debrief that nobody has time for before the next week starts.

The instinct was right. The container has outlasted its purpose.

What the Manifesto Actually Said

The Agile Manifesto has been both over-applied and under-read. Over-applied: the practices that emerged from it — scrum, kanban, SAFe, the entire apparatus of agile transformation consulting — were built on top of the manifesto’s values in ways that its authors would not all recognize as faithful. The ceremonies became mandatory. The roles became job titles. The velocity metric became a performance evaluation. The thing that was supposed to make work more human became, in many organizations, a new kind of bureaucracy with its own vocabulary and its own priesthood.

Under-read: every one of its four values was a deliberate inversion of a specific waterfall pathology. And every one of them points, if you follow it far enough, toward something that has not changed and will not change with the next shift in cost structure.

Customer collaboration is more important now than it was in 2001. Responding to change is more important now. The manifesto’s values did not expire. The structures built to implement them did.

The Structures That Were Scaffolding

The sprint is a container for work that takes time to complete. When work completes in hours, the two-week sprint does not accelerate — it becomes a holding pattern. The work is done before the sprint review. The sprint planning session is allocating capacity that has already been consumed.

The standup asks three questions: what did you do yesterday, what are you doing today, what is blocking you. When work moves faster than the standup cadence, the standup is reporting on history rather than coordinating present activity. It becomes a ritual of accountability that nobody believes in but nobody stops performing.

The backlog is a queue for execution capacity. It assumes that the scarce resource is developer time — that ideas are cheap and implementation is expensive, so you maintain a prioritized list and work through it in order of value divided by effort. When implementation approaches free, the backlog is no longer a prioritization tool. It is an anxiety archive. A list of things that might matter, maintained against the day when someone has time to consider them, in a world where time is no longer the constraint.

None of this means these structures were wrong. They were right, for their constraint. The sprint was a rational container for work that genuinely needed two weeks. The standup was a rational coordination mechanism for teams whose work moved at human speed. The critique is not that these structures were badly designed. It is that they were designed for a specific cost structure and that cost structure is changing.

The one agile structure that survives the shift almost unchanged is the one that was always the most honest: the spike. A time-boxed experiment — build it to learn whether it is worth building. The spike was agile’s concession that sometimes you cannot know until you see it, that specification is insufficient and you need the artifact itself to evaluate the direction. When execution takes minutes instead of sprints, the spike is no longer an experiment. It is the product. The demo day is the launch. The distinction between exploring and shipping dissolves because the cost of exploring has fallen to the cost of shipping and neither one is large enough to justify a boundary between them.

I built a synthetic media platform — fifteen AI columnists with maintained voice consistency and ideological positioning — in four days. Designer, developer, visionary, marketer. All one person. That was a spike, except the spike was the finished product. And the demo was not for a billion-dollar launch. Maybe it is for the next consulting engagement, or a role that values the judgment more than the job title. When execution is cheap, the portfolio and the product are the same artifact.

One of the sharpest observers of the agile world wrote recently that the biggest threat to agile practitioners is not that AI will replace them — it is that AI will reveal what many organizations already suspected: they never needed agile practitioners. They needed someone to manage Jira.

That is not a dismissal of the people. It is a diagnosis of the structure. The people who were doing real work — understanding what needed to be built, synthesizing conversations into a coherent direction, being present enough with the client to hear what they meant rather than what they said — those people were doing real work before and will be doing real work after. The Jira management was always a side effect of a system organized around execution.

The Predecessor Concept

Before agile had a name, Kent Beck was doing something called paired programming.

The conventional interpretation is efficiency: two developers at the same keyboard produce better code faster because one types while the other watches for errors, because they keep each other focused, because the constant explanation of what you are doing surfaces assumptions you did not know you were making.

That interpretation is not wrong. But it misses what Beck was actually onto.

The pair was not primarily a code quality mechanism. It was a decision quality mechanism. The moment of value in paired programming is not when the second developer catches a syntax error. It is when the second developer says “wait, why are we doing it this way?” and the question surfaces an assumption that, once examined, turns out to be wrong. The typing is almost irrelevant. The real-time interrogation of the decision being made while the decision is being implemented — that is what paired programming was actually producing.

Beck’s insight was that two minds on a problem in real time produces better outcomes than one mind followed by a review. The review model has a fundamental flaw: by the time the evaluation happens, significant investment has been made in the direction being evaluated. The cost of changing course increases with every line of code written. The paired model collapses that gap to near zero. The evaluation happens while the decision is still live.

This is the ancestor of what the next chapter will name. Not the typing together. The real-time evaluation of the decision, at the moment of the decision, before the investment has been made.

Beck applied this insight to two developers and a keyboard. The extension is: what if you applied the same logic to the decision that precedes the code? What if the pairing happened not between two developers but between the person who understands what the client needs, the person with the taste to catch where the answer is defaulting to mediocrity, and the person with the authority to commit? What if the real-time interrogation happened at the moment of specification rather than the moment of implementation?

Paired programming was pointing at something beyond code.

The Failure That Isn’t Agile’s Fault

Return to the Thursday meeting.

The team running the Zansei project — an AI-powered marketing consultation tool for small businesses — has been using a version of agile since October 2025. Weekly standups. Thursday collaboration sessions. A backlog of features and client requests that keeps growing as the client’s ambitions expand.

By any agile metric, the team is functioning. They meet regularly. They review work. They plan the next cycle.

And yet the project is accumulating a specific kind of dysfunction that agile was designed to prevent. The product’s scope keeps expanding because the person with authority to commit has updated his mental model of what AI can do and generalized it recklessly. New client relationships are producing requirements that don’t cohere with each other or with the original product vision. The person doing research to improve the product is producing seventeen-page reports to answer questions that were never clearly enough defined to be answerable. The ads keep running while the funnel produces nothing.

There was a Thursday in February when the researcher presented a seventeen-page report on the site’s copy. Half-done, he said. The other half would be ready the following Thursday. The team was spending a thousand dollars a week in ads. Zero people had completed the funnel in the previous seven days. What came over me in that moment was not anger — anger would have been easier. It was something quieter and more final: the realization that I could generate new copy with AI and run an A/B/C test that afternoon, and I was sitting in a room where someone needed seven more days and seventeen more pages to tell me what I already knew. I asked him what single question the research was meant to answer. He flipped through the slides. He rambled something about tests. I told Mr. K to turn off the ads. The meeting continued. The ceremonies continued. The dysfunction that produced the report and the silence and the thousand dollars continued, perfectly intact, because the ceremonies had no mechanism for addressing it.

I can indict the researcher because I have been the researcher. At Mastercard, I produced 127 pages of AI-generated product requirements using the OpenAI Playground. It was thorough. It was well-structured. Leadership was impressed. It looked like momentum. It was articulate noise. I didn’t use AI to clarify our direction. I used it to dress up our confusion. And the artifact, polished as it was, gave leadership the ammunition to keep moving — on goals that had little to do with product. The seventeen-page report and my 127 pages are the same failure at different scales: using the tool to produce the appearance of progress when the actual problem — what are we building and why — remained unanswered underneath.

The dysfunction had another dimension that the ceremonies could not see. The team’s UX designer was generating design variants at AI speed — using Claude to produce web artifacts that simulated complete pages, full visual options ready for review. An artist generating a hundred looks and feels before lunch. But the developer had no design specification to build against. Each artifact looked complete on its own — a single page of JavaScript, CSS, and HTML — but none of them connected back to the database, to the TypeScript codebase, to the actual product architecture. There was no shared language between design and development. The UX work and the development work were moving at different speeds, in different media, producing fragments that looked whole individually and could not connect.

This is the opposite of what Beck’s paired programming was designed to produce. Beck’s insight was that two minds on the same problem, in real time, interrogating each other’s assumptions, produces better decisions. The Zansei team had two people producing AI-assisted work at different speeds with different tools and no shared specification to translate between them. Not a coordination problem — the ceremonies were coordinating fine. A language problem. The work could not speak to itself.

The agile ceremonies are not catching any of this. They are providing the appearance of coordination while the actual problem — nobody in the room can say no with authority, nobody has the explicit function of maintaining the product’s integrity against the gravity of scope expansion — continues unchecked.

This is not agile failing. This is agile succeeding at what it was designed to do — coordinating execution — in a situation where execution is not the constraint.

When the Denominator Disappears

The prioritization framework the team tried to use was weighted shortest job first — WSJF. Divide business value by job size and time criticality. The result is a priority order. It is a rational framework for a world where execution capacity is scarce: given limited capacity, what should we build first?

It stopped working for an interesting reason.

When execution cost approaches zero, job size collapses. Everything becomes equally small. The denominator that used to differentiate the list converges toward a constant, and what you are left with is a list ranked only by business value — which is exactly what nobody can agree on, because the product’s identity keeps shifting and the person who could anchor it keeps expanding it.

WSJF is really asking: given scarce execution capacity, what should we build first? When execution capacity is no longer scarce, the question it was designed to answer dissolves. The new question is: given that we can build almost anything, what should we decide to build at all?

That question requires a different kind of answer, and a different kind of room to produce it.

The Scaffold Is Coming Down

The field is producing its own successor frameworks, in real time, without yet having a name for what they are converging toward.

Amazon Web Services, in 2026 guidance for teams building AI-native products, suggested that sprint planning must evolve into what they called “Intent Design” — where architecture defines roles, guardrails, and fallback mechanisms rather than scripting every decision path.¹ The frame has shifted from “here is the plan we will execute” to “here is the intent we will navigate toward.”

What the successor frameworks share, wherever they are emerging, is a common move: front-load the thinking, compress the execution, make the alignment the work rather than the precondition for it. The ceremonies that were designed to manage execution are being replaced, in the organizations that are furthest along, by something that more closely resembles the Thursday meeting working at its best.

Not the ritual fifteen minutes at the start. The two and a half hours in the middle where the work is visible, the options are real, and the decisions are made by the people who have to live with them.

That is not a meeting. That is the methodology.

Agile was right about the values. Customer collaboration matters. Responding to change matters. Working software over comprehensive documentation matters. None of that expires.

Agile was right about the instinct. Get the people together. Make the work visible. Close the gap between building and knowing whether the build was right. These instincts are more important now, not less.

What agile could not have anticipated is that closing the execution gap all the way changes what the gap needs to be closed around. When execution is genuinely fast, the gap that needs closing is not between planning and delivery. It is between the decision and the validated direction. Between what the room understood and what the agent built. Between the intent and the outcome.

The sprint was the right unit when building was the hard part.

The room is the right unit now.

What happens in that room, and who belongs in it, is what the next chapter is for.

The sprint was a container for work that took time. The room is a container for decisions that must be right. They are not the same container.

Notes

AWS Prescriptive Guidance, “Operationalizing agentic AI on AWS,” section “Evolving software delivery for agentic AI,” 2026. https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-operationalizing-agentic-ai/software-delivery.html

← Previous: Chapter 2: When Building Was the Hard Part (And What Happened When It Stopped) · Contents · Next: Chapter 4: Deliberate Alignment →

Symbolic vs Statistical: A Game Developer’s Guide to How AI Remembers

For more than two decades I built games on symbolic AI — finite-state machines, behavior trees, rule systems that knew exactly what a ball was and exactly what it would do next. When I moved into generative AI, that background was both an advantage and a trap. It gave me a vocabulary for memory and meaning that modern systems quietly violate. This is about that violation — how these systems “remember,” how they “understand,” and how my old symbolic assumptions got challenged by the new statistical reality.

TL;DR:

🔧 Symbolic AI (GOFAI — “Good Old-Fashioned AI”) never forgets what a ball is.

🤖 Modern AI (LLMs) never really knew what a ball was in the first place.

The ball, two ways

In symbolic AI, a “ball” is explicitly defined. You write it down:`

Ball = { 
    shape: "round", radius: 0.5, position: [x, y, z], state: "rolling" 
}

You give it rules of behavior:

if ball.position.y > 0 and not supported(ball):
    ball.state = "falling"   # gravity applies whether or not anyone is looking

And object permanence comes for free, because the object exists in a model, not in a sentence:

hide(ball, under=blanket)
assert ball.exists == True        # still there
assert ball.position == under_blanket   # still tracked

Contrast that with a large language model. There is no object — only text. There is no persistent simulation — only plausible continuation. “Ball” is a vector: a high-dimensional point shaped by how the word was used across billions of sentences.

"ball" → [0.0421, -0.118, 0.339, ... ]   # ~thousands of dimensions

It’s a statistical representation of how “ball” relates to “throw,” “catch,” “round,” and “play.” The model doesn’t store the rules. It stores the statistical gravity of those rules.

The machinery of recall — 2026 edition

In 2025, when I first wrote this, the honest answer to “how does a chat model keep track of anything?” was usually RAG: chunk the history, embed each chunk into a vector, store it (FAISS, Pinecone, Weaviate), retrieve the semantically nearest pieces, and paste them back into the prompt. RAG is still here and still useful — but it is no longer the answer, and that change matters for this argument.

A 2026 frontier model has several ways to hold context:

Long context windows — hundreds of thousands to a million tokens, so the whole conversation often just stays in view.
Persistent memory features — the system writes durable notes about you across sessions.
Agentic scaffolding — scratchpads, tool state, and memory files that an agent reads and writes as it works a task.
Retrieval (RAG) — still the move when the corpus is bigger than the window.

Here’s the thing I want to be precise about: none of these is a world model. They are all better and bigger ways to put the right text back in front of the model. The model still reads that text fresh and continues it. We didn’t give it a running simulation; we gave it a much larger, much better-organized desk.

SimCity vs Minecraft

A symbolic system gives you a world. An LLM gives you a seeded world.

Symbolic AI is SimCity — agents tick away even when they’re offscreen. The simulation runs whether or not you’re watching.

An LLM is Minecraft. When you approach a biome, it loads. When you leave, it unloads. You feel like the world persists, but it’s procedurally adjacent, not remembered. The sheep aren’t grazing when you’re not watching — they’re gone, until you say “there are sheep here.” The model won’t know what’s happening at coordinates [3245, 344, 20] until you make it aware again.

LLMs don’t forget. They just never knew until you told them — and they’ll need telling again. They regenerate context rather than remember it.

The 2026 update doesn’t break this metaphor; it sharpens it. A bigger context window is a bigger render distance. Persistent memory is a saved game. Agentic scaffolding is a server that keeps a few chunks loaded between visits. All of it makes the world feel more persistent — and none of it makes the sheep graze when no one’s looking.

Hybrid models: where symbolic meets neural

If LLMs are wandering procedurally generated Minecraft biomes, and symbolic AI was structured, rule-based SimCity — what if you combined them?

That’s the bet hybrid systems make. They don’t just predict what a ball does; they back the prediction with something that models it: state that persists over time (a red cube doesn’t vanish when you stop talking about it), consistent behaviors (a locked door doesn’t open because the next sentence implies it did), and inference, counterfactuals, and planning that reach past language.

What’s interesting in 2026 is that the field moved exactly this direction. The reasoning-model paradigm (extended deliberate “thinking” before answering) and the agent paradigm (a model wrapped in tools, memory, and a control loop) are both attempts to bolt persistence and structured search onto a statistical core. AlphaZero and MuZero showed the template years ago — deep pattern recognition plus Monte Carlo Tree Search, a symbolic planner. Graph neural networks reason over symbolic structure. Logic-augmented networks fold constraints into training so outputs are not just plausible but consistent. The names changed; the move is the same: give the statistical engine a symbolic skeleton.

They’re not AGI. But they’re more than autocomplete — and they don’t forget the ball under the blanket just because the scene changed.

Object permanence, and why it’s hard

Symbolic AI can say “the red cube is under the blanket” and remember it, because it models location, not tokens.

An LLM says “the red cube is under the blanket” and, in 2025, forgot it a few thousand tokens later unless you brought it back. In 2026, with a million-token window, it can hold that sentence for the length of a novel. That is a real improvement — and it is not the same thing as tracking. Even now, the base model doesn’t update an internal world model. It doesn’t track. It guesses, very well, from everything currently in view.

This is why the “ball under the blanket” probe is so revealing. Ask a model “where is the ball now?” and it may answer correctly — but historically only because your sentence structure reminded it. The honest 2026 version: it answers correctly far more often, because far more is in view and the pattern-matching is far better. There’s still no hidden state underneath. There’s contextual coherence, derived from statistical relationships in training, applied to whatever is in the window right now.

Why this feels like AGI (but isn’t)

If you come from symbolic AI or game dev, modern models feel close. There’s behavior. There’s reasoning. There’s even creativity.

But it’s echo, not essence. The output looks right because the model is extraordinary at producing right-looking output. The simulation isn’t running; it’s being sketched in real time, exactly as far as you’re pointing the camera.

Frontier models — Claude, GPT, Gemini — make this illusion dramatically stronger than the 2025 versions I first tested. They hold more, recall more, and in an agentic loop they can carry a goal across many steps by writing it down and reading it back. That last part is the genuinely new wrinkle, and it’s worth saying plainly: when an agent maintains state in a scratchpad or a memory file and consults it each step, the system is doing something closer to symbolic persistence — even though the model at the center still regenerates. The persistence moved into the scaffolding around the model. That’s the hybrid direction this article pointed at in 2025, arriving in production.

Symbolic AI had goals, maps, states, and agents. LLMs have tokens, vectors, and weights. We still haven’t merged them at the core — we’ve gotten very good at layering the old ambitions on top of the new illusion.

What AGI needs (and what LLMs still don’t have)

🔹 Persistent internal goals — ❌ Still no. Models react to prompts. An agent can carry a goal in a file, but the model has no objective of its own.

🔹 Causal reasoning — ⚠️ Partial, and better than it was. They simulate cause and effect by pattern; reasoning models search harder over those patterns. They still don’t model mechanisms.

🔹 Embodied understanding — ❌ Still no. No grounding in the physical world. Multimodal helps perception; it isn’t embodiment.

🔹 Memory with understanding — ⚠️ Partial. They retrieve patterns, not experiences. Memory features store facts; they don’t produce conceptual learning.

🔹 Self-model / agency — ❌ Still no. No concept of “self.” They don’t choose, want, reflect, or persist between calls. LLMs are mirrors — not minds.

Tacking this to my other piece

This is a sibling to “When Memory Isn’t Memory: Reconstructing Context in Conversations with AI.” That one probed how memory feels (and fails) in chat systems. This one is about why the illusion feels so plausible to those of us trained in classic AI.

Symbolic AI taught us that memory had structure. Generative AI shows us that memory has shape. The two aren’t the same — and a year of frontier progress hasn’t closed the gap so much as decorated it. That difference is still what separates a clever assistant from a thinking system.

By Walter Reid for Designed to be Understood (Originally Posted on walterreid.com)

When Building Was the Hard Part (And What Happened When It Stopped) [Chapter 2]

[Chapter 2 from Deliberate Alignment by Walter Reid, written in spring 2026]

Methodology does not follow philosophy. It follows economics. Every time the cost structure changed, the way people organized around it changed to match.

In 1970, a software engineer named Winston Royce published a paper that would become one of the most influential and most misread documents in the history of software development.

The paper described a process in which software moved through sequential phases — requirements, design, implementation, testing, deployment — each completed before the next began. The diagram showed these phases flowing downward, like water over a series of steps. It was called, eventually, waterfall. Royce did not call it that. More importantly, Royce did not endorse it.

The paper’s actual argument was almost precisely the opposite. Royce described the sequential model and then spent the remainder of the paper explaining why it was fundamentally flawed. He called for iteration. He called for early prototyping. He called for the involvement of the customer throughout the process. The diagram that became the emblem of heavyweight process for three decades was an illustration of what not to do.

This matters not as a historical footnote but as a lesson about how methodologies actually travel. What spread was not Royce’s argument. What spread was the diagram. The sequential model was visually clean, organizationally legible, and easy to put in a contract. You could tell a client exactly what they would get and when. The fact that it did not work particularly well was, for a time, less important than the fact that it was understandable.

This is how methodology wins. Not through intellectual persuasion. Through organizational convenience. The thing that is easiest to adopt beats the thing that is most correct, until the cost of the incorrectness becomes impossible to absorb.

Why Waterfall Made Sense

Computing time in the 1970s was expensive in a way that requires historical imagination to appreciate. Organizations paid for access to mainframes by the minute. Running the wrong program was a financial event. Changing code rippled through every piece it touched, and tracing those ripples consumed time that was itself expensive. A modification to a system that had been in production for six months might require weeks of testing to validate that nothing had been broken. The test environments were manually assembled. The tests were largely manual. Change was not free.

In this environment, the sequential model was not irrational. If change is expensive, minimize change. If minimizing change requires knowing what you are building before you build it, invest in knowing. Gather requirements exhaustively. Design comprehensively before coding. Test everything before shipping. The overhead was enormous but the alternative — discovering in month eight that you had built the wrong thing — was worse.

The problem was the one Royce identified in 1970 and that practitioners spent three decades rediscovering: exhaustive upfront specification assumes the future is knowable with precision, and the future is not. Requirements change because businesses change. Clients change their minds because they do not fully know what they want until they see what they asked for.

Waterfall produced a specific, predictable failure mode: software that was precisely what was specified, and not what was needed. The Standish Group’s early data told the story — more than 30 percent of projects cancelled before completion, fewer than 20 percent delivered on time and on budget. Not catastrophically wrong software. Software that arrived late, over budget, and partially wrong. The signature failure of a process that optimized for planning at the expense of adaptability.

The fix was not to plan better. The fix was to make change cheaper.

The Shift That Created Agile

Between 1970 and 2001, the cost of changing software fell steadily, quietly, and cumulatively. Hardware became cheaper. Version control made it possible to reverse bad changes. Test frameworks made validation automatic. By the late 1990s, the math underneath waterfall had shifted. The exhaustive upfront specification was premised on change being expensive. When the cost of getting it wrong and correcting dropped below the cost of the overhead required to get it right the first time, the premise dissolved.

This is the context into which Kent Beck walked with Extreme Programming and seventeen practitioners walked with the Agile Manifesto. They were not describing a philosophical revolution. They were describing the rational response to a new cost structure. Iterate fast because iteration is cheap. Keep the customer close because you can afford to discover you misunderstood and correct quickly. Release often because the overhead of releasing has fallen to the point where infrequent releases are economically unjustified.

The Manifesto’s four values read as philosophy. They are better understood as economics. Each value is a prescription for a world in which iteration is cheap and specification is expensive relative to correction.

Agile did not win because it was philosophically superior to waterfall. It won the same way waterfall won — through adoptability. The ceremonies fit the organizational shape that already existed. That they also happened to be correct for the cost structure was, in a sense, a bonus. The adoptability came first.

What Agile Produced

Delivery frequency increased. DORA’s research confirms what practitioners already felt: the best teams deploy multiple times a day. Project failure rates declined. Developer experience improved. The daily standup, whatever its limitations, surfaces problems earlier than the monthly status meeting.

And something subtler happened that is relevant to everything that follows. Organizations got better at the mechanics of building software and did not get proportionally better at the question of what to build. The sprint became a well-oiled machine for delivering features. Whether the features delivered were the right features remained stubbornly harder than the delivery itself.

This is not a criticism of agile. Agile was designed to make iteration cheap. It was not designed to make the initial decision correct. The assumption was that cheap iteration would eventually produce convergence on the right answer, through repeated feedback and course correction.

That assumption held when iteration cycles were measured in sprints. It strains when iteration cycles are measured in hours.

The Counter-Argument Worth Acknowledging

AI-assisted development is producing measurable productivity improvements. The tools are genuinely useful. But two data points from analysis of AI-generated codebases are worth sitting with separately, because they are telling different stories.

The first: code churn — the percentage of code written and then discarded within two weeks — roughly doubled between 2021 and 2024 in teams using AI assistance heavily. The critics read this as evidence that AI makes code worse. More code is being written and thrown away.

The second, less discussed: the rate of refactored or “moved” code — an indicator that developers are thinking carefully about structure and reuse — declined sharply over the same period.

These are different signals. The churn says wrong decisions get executed fast. The declining refactoring says something more unsettling: people stop thinking structurally when the tool thinks fast. The developer who used to pause before writing a new module — who would ask whether this logic already existed somewhere, whether this function belonged here or in a shared library — that pause is disappearing. Not because the developer lost the skill. Because the tool makes it faster to write the new thing than to find and integrate the existing thing. The economics of the moment favor duplication over design.

The first signal is a decision-quality problem that AI makes visible. The code is discarded because the decision before the code was wrong, and AI executes the wrong decision faster than a human would have. The human writing code inefficiently was, in the process of writing inefficiently, discovering that the decision was flawed before too much had been built against it. The AI removes that accidental correction mechanism.

The second signal is subtler and points somewhere different. It suggests that speed itself degrades a specific kind of judgment — the structural judgment that asks not just “does this work” but “does this belong here.” The churn problem is a decision-quality problem. Deliberate Alignment is designed to address it. The refactoring problem is something else: a capacity problem, operating below the level of any meeting or methodology. It shows up later, as accumulated technical debt that nobody planned and nobody measured, produced by a cognitive habit that nobody noticed was disappearing.

The first signal says the next problem is upstream of execution. The second says it may also be inside the people doing the executing. This book addresses the first. The second is worth naming honestly, even here, because pretending both signals point the same direction would be the kind of false resolution the rest of this book is trying to avoid.

The Pattern, Stated Plainly

When building was expensive, you planned exhaustively before building. Waterfall.

When building became cheap, you iterated toward the answer. Agile.

When building approaches free, iteration is no longer the bottleneck. Something else is.

There is a circle worth closing here. When Royce and the businesses that adopted his diagram front-loaded planning, they did so because development was costly. Mainframe time was expensive. A mistake in month six meant a budget-ending rewrite. So they invested in knowing before building, because building was the thing they could not afford to get wrong.

Deliberate Alignment front-loads thinking for the opposite reason. Building is approaching free. The wrong thing arrives instantly. The cost is no longer the build — it is the rework cycle when what arrives is not what was needed, multiplied by the speed at which the wrong thing propagates. You plan before you build not because building is expensive, but because it is so cheap that an undirected build produces waste at a rate no team can absorb.

The same conclusion — think before you act — reached from opposite ends of the cost curve. DA is not a return to waterfall. It is arriving at waterfall’s instinct from the other direction.

It is like baking bread. Once the ingredients are in and you start to bake, if the bread doesn’t taste good or doesn’t rise, you don’t fix the bread. You make another loaf. So you get the ingredients ready ahead of time and you plan the recipe — but now the bake takes one minute. The planning is not because baking is hard. The planning is because baking is so easy that a bad recipe wastes nothing but your attention, and attention is the thing you cannot get back.

The practitioners who defended waterfall in 1999 were not irrational. They were experienced. They had seen agile’s predecessors come and go and concluded, reasonably, that each new methodology was mostly repackaging with new vocabulary. They were right that most of what agile claimed was not new. They were wrong that the underlying shift was incremental.

The practitioners defending agile-with-AI as the appropriate response to this moment are not irrational either. They may be right that better tools improve agile practice in the short term. They are, this book argues, wrong that the underlying shift is incremental.

The pattern says so. The pattern has said so twice before.

The Bottleneck Has Moved

The constraint was never the code. It was always upstream. Execution time was just good enough at hiding it.

Around 2012, a mobile team at iHeartRadio went on a ski trip.

The trip was a hackathon. Four days, no meetings, build whatever you think is worth building. The lead developer was learning Swift — not because anyone asked him to, but because the potential was obvious and the potential was new and that combination produces a specific kind of energy in a good engineering team. They were not waiting to be told what mattered. They already knew.

By the end of four days, they had built things. Real things. A customer talk radio station concept. A full-screen album art redesign that changed the entire feel of the listening experience. Prototypes that answered questions nobody had been able to get answered through the normal process of design reviews, stakeholder meetings, and prioritization discussions.

Then they went back to the office.

The prototypes sat. Not because nobody was interested. Because it wasn’t clear who could decide. The executives had opinions. The design organization had designed, by the CDO’s own account, every conceivable UX and UI option. And yet the decisions that would have let the team move — which direction, which experience, what to build toward — did not come.

The CDO said something to the mobile product team that stayed with me. Paraphrased: don’t come to a meeting with opinions, because the people you’re talking to have better titles.

The team built fast. The decisions moved slowly. The competitive window was wide enough, in 2012, to survive the wait. Nobody felt the full cost of the delay because the delay was normalized into the rhythm of how things worked.

That was the constraint. Not the code. Never the code. The constraint was upstream, invisible to anyone measuring sprint velocity or deployment frequency, and protected by an organizational structure that had confused hierarchy with judgment.

What AI changes in that story is not the politics. It is the cost of the delay.

The Constraint Moves

Goldratt’s central insight is simple enough to state in a sentence: every system has one constraint at any given time, and the performance of the system is determined by that constraint.

The five focusing steps that follow are what make it operational. Identify the constraint. Exploit it — get the most out of it before doing anything else. Subordinate everything else to the constraint — stop optimizing what is not the bottleneck. Elevate it — if exploiting is not enough, invest in increasing its capacity. And when it breaks through, go back to step one. Because the constraint will have moved.

That fifth step is the entire argument of this book.

For most of software development’s history, execution was the bottleneck. There were not enough developers. The ones you had could only build so fast. The field identified that constraint and optimized against it for two decades. Lean software development. Kanban. DORA metrics. Continuous deployment. Each optimization was applied to the right constraint and each one worked. The organizations that invested in them got measurably better.

The constraint has broken through. Execution, for teams at the frontier of this shift, is no longer what limits the system. But the field is still on step three — subordinating everything to a constraint that has already moved. Continuing to optimize deployment frequency and cycle time is improving something that is no longer the bottleneck. It produces the appearance of progress. The velocity metrics go up. The wrong things get built faster.

Matt Gunter, writing about the misapplication of constraint theory to software, arrives by a different route at the same destination.¹ His argument against TOC in software is that the flow metaphors break down for knowledge work, that throughput optimization creates what he calls “intention blindness” — it cannot reflect the value of strategic decisions. The real levers, he argues, are not throughput optimization but something else — improving skills, reducing unforced errors, increasing the level of decision quality. He is arguing against the vehicle and pointing at the destination. The conclusion he reaches independently — decision quality — is the one this chapter is built around. Convergent evidence from someone trying to argue the other way is worth more than confirming evidence from someone already on your side.

The constraint is upstream. It is the quality of the decision before execution begins.

Decision Latency

Velocity measures how fast a team executes. It is a reasonable measure of execution speed and a poor measure of anything else.

The metric the field does not yet have a name for is the one that matters most in a world where execution is cheap. Call it decision latency — the gap between when a commitment is made and when its quality is validated.

In the iHeart story, the decision latency was months. The prototypes existed. The options were concrete. But the validation — did we build toward the right thing — arrived slowly, through the slow accumulation of user data, competitive signal, and executive opinion. The execution was fast. The decision latency was long. The constraint was not the sprint. It was the gap between commitment and confirmed direction.

When execution takes weeks, long decision latency is painful but recoverable. You discover in month three that the decision in month one was wrong, you course-correct, you lose three months.

When execution takes hours, long decision latency is catastrophic. The bad decision propagates into artifacts before anyone has asked whether it was right. The doubled code churn is this dynamic made visible. The execution is faster. The decision latency is unchanged. The wrong things are built at speed and the waste arrives before the course correction.

Decision latency is the new constraint. Shrinking it is the new work.

The Constraint You Think You Have

There is a version of this misidentification that is worth naming directly, because it explains why entire sectors are moving slower than they should.

I have watched it happen in healthcare IT. The regulatory barriers are real — HIPAA, FDA clearance, payer integration standards that took decades to partially achieve. Anyone who tells you these do not matter has not worked in a health system.

But here is what the data actually says. When health system leaders are surveyed about the biggest barrier to AI adoption, the top answer is not regulatory uncertainty. It is immature AI tools — cited by 77 percent of respondents. Financial concerns come second at 47 percent. Regulation comes third, at 40 percent.²

The thing most health system leaders cite first in conversation is third in the data.

That gap between the conversation and the data is the diagnostic. The regulation is real. The regulation is also performing a psychological function that has nothing to do with compliance. It is providing the story that makes the real constraint — immature infrastructure, missing talent, slow decision-making — feel like someone else’s problem. The external constraint is more comfortable than the internal one. Regulation is a wall you can point at. Decision-making speed is a mirror.

What makes this pattern durable is that it is self-reinforcing. The organization that identifies the wrong constraint invests in managing it, builds reporting structures around it, develops institutional expertise in navigating it. That investment creates its own justification. The people who have spent three years managing regulatory risk are not wrong that regulatory risk exists — they are wrong that it is the binding constraint, and they now have careers that depend on not seeing the difference. The external constraint stops being a misidentification and becomes an identity.

This pattern is not unique to healthcare. Every organization pointing at an external constraint while the internal one goes unnamed is doing the same thing. “Technical debt” can be a version of the same misidentification — teams fixing code when the real problem is decision quality upstream, velocity treated as a vanity metric while the constraint it measures has already moved. The question is always the same: what would you do if the external barrier were removed tomorrow? If the honest answer is “we still could not move quickly,” you have been managing the wrong constraint. Possibly for years. Possibly while building an organization optimized to keep managing it.

The Boundary Condition

There is a version of the Mastercard story that belongs here as a boundary condition — and it is worth understanding why Click to Pay existed before understanding why the constraint theory breaks against it.

Click to Pay was born from a relevance crisis, not a technology problem. As Apple Pay, Google Pay, and other wallets proliferated, they used the Visa and Mastercard rails invisibly. The acceptance mark — the thing that once told a consumer this place takes your card — stopped meaning anything when every place took everything. The brand was disappearing into the infrastructure it had built. Click to Pay was the response: a product designed to solve a relevance problem, organized as if it were solving a technology problem. That misidentification — strategic constraint dressed as technical constraint — is the healthcare pattern from earlier in this chapter, operating at the scale of a global payments network.

At scale — three hundred or more developers, multiple competing institutions, decisions that required alignment across Visa, Mastercard, American Express, and Discover before any code could be written — the constraint was not execution and it was not decision quality in the traditional sense. It was decision authority. Nobody could say yes in a way that meant yes. The committee’s real function was not to make decisions but to provide political cover for the absence of decisions.

AI would not have helped that. AI might have made it worse — faster execution of a direction nobody was actually committed to, amplifying the incoherence before the political process had time to quietly bury it.

This is the boundary of the argument. When decision authority is so distributed across competing interests that yes cannot be said at all, the constraint is not decision quality. It is organizational structure. That is a different problem, and this book does not solve it.

How common is that situation? More common than the framing of “boundary condition” implies. Enterprise software teams, government contractors, any organization where multiple institutions must align before a single line of code can be committed — these are not rare. They are a substantial portion of the industry. The Mastercard dynamic is not an edge case. It is the normal operating condition for a significant fraction of the people reading this book.

What this book addresses is the iHeart situation: capable people, real potential, decisions that could have been made but weren’t, because the structure around decision-making was unclear and the culture was hostile to the expression of informed opinion. If you are in that situation, the framework in the following chapters is for you. If you are in the Mastercard situation, the framework will not be sufficient. Knowing which situation you are actually in is itself a decision-quality problem — and it is worth solving before you go further.

What This Means for the Metrics

Velocity will not disappear. It will be demoted.

The useful analogy is heart rate. Heart rate is real. Monitoring it tells you things worth knowing. But no serious athlete optimizes for maximum heart rate. It is a health indicator, a lagging measure of effort expended. Optimizing for it directly selects for stress rather than fitness.

Velocity is the heart rate of software development. Useful to monitor. Dangerous to optimize. The organizations that built their entire performance culture around it will find, as execution costs fall, that they have tuned an instrument measuring something increasingly peripheral.

Decision latency will become the primary metric for teams at the frontier. Not because it is easy to measure — the field does not yet have standard instrumentation for it. But because it is the measure that corresponds to the actual constraint. Speed at low quality produces more waste faster. Quality at low speed produces the iHeart hackathon — right direction, wrong pace. Quality at high speed is what Deliberate Alignment is designed to produce.

The hackathon worked, imperfectly, because it changed the cost of decision-making. A tangible prototype is cheaper to evaluate than an abstract proposal. The executive who cannot decide between two UX directions described in a document can sometimes decide between two they can actually use. The concreteness reduced the decision latency — not by speeding up the process, but by changing what the process had to evaluate.

That instinct — make the decision easier by making the options real — is the same instinct behind what this book will name in two chapters. The difference is that in 2012 the hackathon took four days to produce the prototypes. Now the prototypes can exist before the meeting that will decide between them.

The constraint is the same as it always was. The cost of carrying it has changed.

Velocity measures how fast you move. Decision latency measures whether you moved in the right direction. Only one of those was ever the constraint.

Notes

Matt Gunter, “How ‘Theory of Constraints’ misguides software improvement,” Medium, March 2024.
“Adoption of artificial intelligence in healthcare: survey of health system priorities, successes, and challenges,” Journal of the American Medical Informatics Association 32, no. 7 (2025). Scottsdale Institute member survey, Fall 2024, 43 responding US health systems. https://academic.oup.com/jamia/article/32/7/1093/8125015

← Previous: Chapter 1: The Meeting That Finished After the Work Did · Contents · Next: Chapter 3: What Agile Got Right (And Why It’s No Longer Enough) →