I used to think that when AI initiatives stalled, it was because the models weren’t good enough. Over time, what I’ve learned is that this is rarely the case. More often, AI exposes something else entirely: programs that were never designed to support systems that learn. In many organizations, AI is treated as the most complex part of the stack. In practice, it’s often the surrounding program design - how work is structured, governed, and measured - that becomes the real constraint. When AI “fails,” it usually isn’t because the model is incapable. It’s because the program around it assumes a level of stability that AI systems simply don’t have. When “Good Accuracy” Started Feeling Misleading When “Good Accuracy” Started Feeling Misleading Accuracy is one of the first numbers teams reach for when evaluating AI systems. It’s familiar, easy to communicate, and comforting when it’s high. For a long time, I accepted it at face value too. What eventually started to bother me was how little that number explained what was actually happening in the system. Accuracy compresses very different kinds of errors into a single percentage, even though those errors can have very different consequences. In many real-world contexts, a small number of the “wrong” errors matter far more than a large number of benign ones. In practice, this shows up in subtle ways. A model can look excellent on paper while creating additional operational work, increasing overrides, or quietly eroding trust. The metric moves in the right direction, yet the system feels harder to run. That disconnect is often the first sign that the program is optimizing for a proxy, not for the outcome it actually cares about. Over time, I’ve seen teams shift their attention toward more nuanced signals, not because they’re academically interesting, but because they explain reality better. The challenge is that many programs still reward headline metrics, even when the real work lies in managing trade-offs that don’t fit neatly into a single score. Why Better Models Didn’t Automatically Change Outcomes Why Better Models Didn’t Automatically Change Outcomes One of the more counterintuitive lessons for me was realizing how often technical improvements fail to translate into meaningful impact. Improving a model does not automatically improve the system it operates in. Impact comes from changing decisions and workflows, not from generating better predictions in isolation. I’ve seen situations where predictive performance improved meaningfully, yet downstream behavior barely changed because the surrounding processes, incentives, and constraints stayed the same. When this happens, teams often feel stuck. The AI work is clearly better, but outcomes don’t move in proportion. This isn’t a failure of effort or execution, it’s a design problem. Programs that treat AI as an add-on to existing structures tend to capture only a fraction of its value. The ones that benefit are those that revisit how decisions are made, who owns them, and how success is measured once new information becomes available. Why Our KPIs Couldn’t Keep Up With the Models Why Our KPIs Couldn’t Keep Up With the Models What surprised me most wasn’t how quickly models evolved, but how slowly program scorecards adapted around them. Many KPIs were built for technologies that behave predictably after deployment. They assume a clear “before” and “after,” followed by a long period of stability. AI systems don’t work that way. They continue to change as data shifts, assumptions age, and usage patterns evolve. I’ve seen teams iterate rapidly on models while governance and review cycles move at a much slower cadence. On paper, everything still looks fine. But important signals, subtle changes in behavior, rising overrides, early signs of drift don’t have a natural home. They fall between dashboards, reviews, and owners. This rarely leads to dramatic failure. Instead, it creates a slow loss of momentum. Teams become hesitant to make improvements because the program can’t absorb them quickly. Or changes happen without shared visibility, increasing risk in ways that only become obvious later. In both cases, the system’s ability to learn is limited not by the model, but by the program structure around it. At some point, it became clear to me that the discipline itself wasn’t the problem. It was simply designed for a slower world. Why “Just Managing the Program” Wasn’t Enough Anymore Why “Just Managing the Program” Wasn’t Enough Anymore As AI became more central to the systems I worked with, the role of program management started to feel different. Coordinating timelines and deliverables was no longer sufficient. AI systems behave less like static software and more like socio-technical systems, shaped by interactions between data, models, tools, and people. Their behavior emerges over time, often in ways that aren’t obvious at launch. The most effective program leaders I’ve seen don’t just ask when something will ship. They ask how the system will behave once it’s in the hands of users, how it will change as conditions evolve, and how those changes will be detected and handled. That shift in perspective from coordination to ownership is subtle, but it matters. It also requires comfort with uncertainty. Rather than trying to lock everything down upfront, the focus moves toward designing guardrails, feedback mechanisms, and decision rights that allow the system to adapt safely. What AI Forced Me to Rethink About Program Design What AI Forced Me to Rethink About Program Design Over time, a few patterns consistently stood out to me in programs that handled AI well. First, they started with decisions, not models. Instead of asking what kind of AI to build, they asked which decisions needed improvement and why. Working backward from decisions made it easier to connect model behavior to real outcomes and to recognize when improvements were meaningful versus cosmetic. Second, they treated data as ongoing work. Data pipelines weren’t viewed as a setup task to complete before “real” development began. Ownership, quality, and change detection were treated as continuous responsibilities, not one time milestones. Third, they made feedback loops explicit. Performance wasn’t something to review after the fact. Signals from operations, users, and outcomes were intentionally routed back into the system, with clear ownership over what those signals triggered. This made learning visible instead of accidental. Finally, they aligned incentives across the system. Model metrics, operational metrics, and outcome metrics weren’t tracked in isolation. When improvements in one area created friction in another, that tension was surfaced rather than hidden. Alignment didn’t eliminate trade-offs, but it made them discussable. Why Coordination Slowly Turned Into System Ownership Why Coordination Slowly Turned Into System Ownership The biggest shift for me was realizing that AI changes what it means for a program to be “done.” AI systems don’t settle into a steady state after launch. They continue to evolve as data shifts, usage patterns change, and assumptions age. In that environment, simply coordinating delivery milestones isn’t enough. Someone has to own how the system behaves over time. That ownership looks different from traditional program responsibility. It’s less about tracking tasks and more about understanding interactions - how model changes affect operations, how human overrides shape outcomes, and how small shifts compound over time. When something starts to degrade, the question isn’t just what broke, but why the system allowed it to happen quietly. what broke why the system allowed it to happen quietly What I learned is that this kind of ownership can’t be bolted on after the fact. It has to be designed into the program from the start: clear decision rights, visible feedback loops, and mechanisms that make change observable and reversible. Without that, teams end up reacting late, often after trust has already been affected. Once programs are designed with system ownership in mind, AI stops feeling unpredictable. It becomes something you can reason about, monitor, and adjust, not because it’s simple, but because responsibility for its behavior is clear. Closing Thought Closing Thought AI rarely fails loudly. Programs do, slowly, quietly, and often in ways that dashboards don’t immediately capture. When programs are designed for learning instead of stability, AI stops being perceived as the bottleneck. It becomes one part of a larger system that’s capable of adapting, improving, and correcting itself over time. Further Reading (Optional) Further Reading (Optional) Forrester: Real-Time Enterprise Architecture in the Age of AI
Google Cloud: KPIs for Generative AI
MindTitan: AI Project Management vs Traditional Software Projects
Antler Digital: Designing Feedback Loop Architectures Forrester: Real-Time Enterprise Architecture in the Age of AI Google Cloud: KPIs for Generative AI MindTitan: AI Project Management vs Traditional Software Projects Antler Digital: Designing Feedback Loop Architectures

AI Is Not the Bottleneck - Your Program Design Is

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How AI-Powered Decision Intelligence is Transforming Enterprise Cost Optimization

I Built a "Baby Algorithm" to Cure My Decision Fatigue (And Save My Relationship)

The Noonification: Charting a Path for Global AI Regulation (11/14/2023)

AGI 2029: Walking the Fine Line Between Utopia and Existential Risks

Biden Charges Federal Government Agencies to Adopt AI

Biden Signs Executive Order to Support Workers Affected by AI

How AI-Powered Decision Intelligence is Transforming Enterprise Cost Optimization

I Built a "Baby Algorithm" to Cure My Decision Fatigue (And Save My Relationship)

The Noonification: Charting a Path for Global AI Regulation (11/14/2023)

AGI 2029: Walking the Fine Line Between Utopia and Existential Risks

Biden Charges Federal Government Agencies to Adopt AI

Biden Signs Executive Order to Support Workers Affected by AI

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps