David Monnerat

Product + AI | Systems Thinker | Enterprise Reality

  • Triage Isn’t a Process Failure

    Triage Isn’t a Process Failure

    Every quarter we grade unplanned work like it’s a mistake. What if it’s just the job?

    The retro slide had two numbers on it. Unplanned work: thirty percent last quarter, forty percent this one. Next to it, a line for next quarter, how much capacity to hold open for the same thing happening again. Nobody could say what that number should be with any confidence, if we knew in advance how much unplanned work was coming, it wouldn’t be unplanned, but holding zero capacity for it, after two straight quarters trending up, wasn’t really an option either.

    The trend line matters more than either number alone. It’s not that the team got worse at planning. It’s that whatever’s generating the unplanned work, shifting priorities, a business figuring itself out in real time, isn’t slowing down. An ER’s caseload isn’t a reflection of the ER. It’s a reflection of what’s happening in the city. Ours was telling us something about the business, not about us.

    Then someone on the product side pointed at something else on the list entirely, something planned, already prioritized, already committed to.

    Where are the requirements for this?

    That was a fair question, aimed at the wrong kind of item for it to sting the way it usually does. The work itself wasn’t a walk-in. It had been on the roadmap for weeks. Nobody had done the diagnostic work of figuring out what it actually was before it landed there, someone with authority had said it mattered, and that had substituted for a spec. The requirements gap was real. It just wasn’t the same gap as the number climbing one line above it.

    I’ve watched this exact scene play out more than once, in multiple organizations, two different problems getting read as one complaint.

    The List Already Works

    Every quarter we build the same artifact: must have, should have, nice to have. We present it like a plan. Stakeholders nod, occasionally push on something they care about, and by and large the list ends up matching what actually needed to happen. That part isn’t broken. We’re good at knowing what matters.

    What we don’t have is the thing the list implies we have: a clean chain from requirements to prioritization to execution. Nobody says “this isn’t on the list because we don’t have requirements yet.” Nobody says “this item is already at risk because the requirements aren’t there.” We skip straight to the list, because we already know, more or less, what needs to get done.

    Two Different Problems Wearing the Same Complaint

    “We don’t have requirements” gets used to describe two different things, and they’re not the same failure.

    One is the true walk-in: work that shows up mid-quarter, unscheduled, because something broke or something new became urgent. Nobody could have scoped it in advance. That’s the situation an ER doctor treats without taking a full history first, not negligence, just the job.

    The other is work that’s already on the list, already prioritized, already committed to, and still has no real definition of what it actually is. Someone with authority said this matters, so it went on the roadmap, and the team started building before anyone had done the diagnostic work of figuring out what “this” means. That’s closer to a case getting booked into tomorrow’s OR schedule off a referral: the surgeon commits to the slot because the person making the call is trusted, not because the workup happened. The team ends up defining the work in real time, mid-procedure, because the priority call substituted for the specification.

    Both get called “no requirements.” Only one of them is actually about triage.

    Unplanned Work Needs Triage, Not Negligence

    For the true walk-ins, the skill isn’t complete information, it’s making the right call fast, with what you have, and adjusting as more comes in. That’s a real discipline. It has its own competence, its own way of being good or bad at the job, and it looks nothing like a GP’s.

    What that competence actually looks like, concretely: someone with the authority to make a fast call without waiting for a full workup. A shared, fast way to size up what’s in front of you, more like a severity check than a requirements doc. Capacity that’s planned for the unplanned, a real percentage of the quarter held open, not treated as slack that shouldn’t exist. Retros that ask whether the call was good, given what was known at the time, instead of asking why the paperwork wasn’t done.

    The scheduled-but-unspecified work needs a different fix, and it has to happen earlier. By the time the case is booked into the OR schedule, it’s too late to ask what the surgery actually involves, the slot is already committed. The fix isn’t a better question mid-procedure, it’s a checkpoint before the slot gets booked: whoever has the authority to say “this is a priority” also owns getting a rough diagnostic done before it lands on the list, not a full requirements doc, just enough to know what kind of case this is. If that checkpoint doesn’t exist, the priority call itself becomes the only gate the work has to pass, and everything downstream inherits however vague that call was. That sits with whoever controls the list, not with whoever ends up doing the work. In a lot of orgs that’s not a formal role, it’s whichever PM said yes fastest, or whoever has five other titles and this happens to be one of them. The fix doesn’t require a new position. It requires that whoever already holds that yes also holds the job of asking one more question before it counts as a priority.

    The Dance

    Naming which one you are doesn’t mean sitting still inside it. Two different problems, two different responses.

    The true unplanned work isn’t a visibility failure to be coached out of the business. The business doesn’t know either. That’s the actual condition, not a lack of effort on their part. Something being on the list at all is already the earliest signal they have, the moment they know enough to say “this is coming” is usually the moment it lands on the roadmap, half-formed. There isn’t a version where they see further ahead and hand you a cleaner list. The lever here isn’t upstream, it’s capacity: plan for the volume, not the shape. Hold room open on purpose, sized to the trend, not to some target number that assumes the volatility will politely go down because a slide says it should.

    The planned-but-unspecified work is the one place a real lever exists, because it’s already inside your process, not out in a business that doesn’t know yet. If something’s on the list and nobody can say what it actually is, that’s grounds to question whether it belongs there, or belongs there yet. Being on the list because someone with authority wants it isn’t the same as being ready to build. Pushing back on that isn’t obstruction. It’s the checkpoint from the previous section, just applied with some teeth.

    That’s the actual work, every quarter: not eliminating unplanned work, since that’s asking the business to know something it doesn’t, but sizing capacity to absorb it honestly, and refusing to let priority substitute for a spec on the things that are supposed to be plannable. One problem gets absorbed. The other gets pushed back on. Different tools, because they’re not the same problem.

    Nobody’s Picked

    Here’s what actually demoralizes a team: not being an ER. Being asked to run like one and graded like a GP, quarter after quarter, without anyone in leadership saying out loud which one we’re supposed to be, or admitting that some of our work is genuinely one and some is genuinely the other.

    A GP shop is a legitimate way to run this work. Slower cycles, real requirements gathering up front, patience from stakeholders while that happens, a willingness to say no to the mid-quarter fire because it doesn’t fit the plan. An ER shop is also legitimate, with its own version of rigor, just a different one. What isn’t legitimate is asking for ER speed with GP process, or booking OR slots off referral and then grading the surgeon on intake paperwork.

    Nobody’s picked. And I don’t think that’s neutral, it’s what keeps the frustration alive. Not deciding doesn’t preserve flexibility, it just means everyone keeps operating on their own private guess about which one we are, and gets penalized whenever that guess doesn’t match what leadership grades against. Ambiguity isn’t neutral ground, it’s a cost, paid every quarter, by whoever’s closest to the work.

    Agreement is what changes it. Not agreement in the sense of everyone liking the answer, agreement in the sense of a decision that’s been said out loud, that people are empowered to act on. Once a team knows which one it is, it stops guessing and starts building the things that make that model good: someone with the authority to call it, a checkpoint before priority turns into commitment, a retro that grades the call instead of the paperwork. None of that is possible while the question’s still being avoided.

    I’ve worked in both kinds of shops. The difference was never which one was better. It was whether anyone had actually decided.

  • The Access Paradox

    The Access Paradox

    Enterprise AI access was supposed to be simple. Give everyone the tools; unlock the value. Here’s what actually happened.

    The pitch is always the same. Give everyone AI. Supercharge productivity. Unlock unlimited value across the organization.

    So companies do. They negotiate enterprise contracts, stand up approved tools, build guardrails for data protection, and roll out access. It takes months, sometimes longer. But eventually, the announcement goes out. AI for everyone.

    Then people actually use it.

    Not the way anyone modeled. Not for the specific use cases in the business case. For everything. Writing emails. Summarizing meetings. Answering questions they used to Google. Exploring problems they would have left alone. Token consumption doesn’t grow linearly when people find a tool genuinely useful. It grows exponentially.

    The cost model wasn’t built for this. The contracts were negotiated based on assumptions about usage that were made before anyone knew what real adoption looked like. So the organization that just announced AI for everyone starts asking a different question: who can we actually afford to give it to?

    Governance First, Then Cost

    Access decisions in large enterprises follow a predictable sequence.

    The first filter is governance. Which tools have been vetted? Which data can flow through them? Which use cases have cleared compliance, legal, and security review? This is the right conversation to have, and it takes longer than most organizations plan for. The result is a tiered system: some tools for everyone, more capable tools for specific groups, the most powerful tools in pilot programs with restricted access.

    The second filter is cost. Once governance is satisfied, the assumption is that access can scale. But scaling access scales consumption. A contract negotiated with one usage pattern in mind produces a different cost picture when people actually depend on the tool. The pilot that was generating real value gets shut down not because it failed but because it succeeded too well.

    Now the access decision isn’t “where does this generate the most value?” It’s “who can we give it to with the least risk and the lowest cost?”

    Those are different questions. They produce different answers.

    The Distribution Problem

    The people who end up with access to the most capable tools aren’t necessarily the people who could generate the most value with them. They’re the people whose use cases cleared governance most easily and whose consumption patterns fit within whatever cost model survived the budget conversation.

    The analyst who works with data all day and could use AI to surface insights that previously required weeks of manual work is in a pilot that got shut down because token consumption exceeded projections. The product manager who uses AI to write Jira tickets has full access because connecting to a project management tool presented lower governance risk.

    This pattern holds beyond any single organization. Deloitte’s 2026 State of AI in the Enterprise report found that 37% of companies are using AI at a surface level with little or no change to existing workflows. The ceiling isn’t the technology. It’s the distribution decision — driven by governance and cost rather than by where the work actually changes.

    And the people who don’t have access find it anyway. Up to 65% of enterprise employees report using AI tools not approved by their IT department. The governance risk the restrictions were designed to prevent is materializing without the organizational visibility to manage it.

    The Free Coffee Problem

    Here’s what makes this hard to fix: the ship has largely sailed.

    People have access to tools they depend on. Taking them away produces exactly the behaviors organizations are trying to avoid. Shadow AI. Workarounds. Tools expensed on personal cards. The resentment that comes from removing something people have built their work around.

    This is the free coffee problem. Once the perk exists, removing it doesn’t return you to neutral. It actively makes things worse.

    But there’s a path through it that doesn’t require subtraction.

    Contract renegotiation is the least glamorous and most important lever. Most enterprise AI contracts were signed before real usage patterns emerged. Usage-based pricing that reflects actual consumption is harder to negotiate but produces better long-term alignment between cost and value. It’s a strategic decision that requires someone to own it at the right level.

    Usage limits are imperfect but better than binary access decisions. Daily or monthly caps force prioritization without eliminating access. They make consumption visible and create the conditions for a conversation most organizations haven’t had: where does this actually matter most?

    Model tiering is the most underused option and the one with the most upside. Most users don’t need the most capable model for most tasks. A well-structured tiering system reserves the powerful models for work that actually requires them and routes routine work to capable but less expensive alternatives. The challenge is that most users don’t have enough context about what different models do to make that decision themselves. They don’t know what a context window is or why it matters. They can’t tell the difference between a task that benefits from Claude Opus and one that Haiku handles just as well. That means the organization has to make the tiering decision, not the user. It’s a governance and design problem, not a technology problem. And it’s solvable.

    The Question Worth Asking Now

    The rollout happened the way it happened. The governance conversations were necessary. The cost surprises were predictable in hindsight. The distribution decisions made sense given the constraints at the time.

    The question worth asking before the next contract renewal, the next access decision, the next pilot that gets shut down because it consumed more than projected: where in this organization does AI actually generate meaningful value?

    Not where is it easiest to deploy. Not where does it fit the existing cost model. Where does it change the work in a way that matters?

    The organizations that answer that question first will have more people using AI where it counts. Not fewer people using it everywhere.

  • Solutions Looking for Problems

    Solutions Looking for Problems

    Agentic AI is changing how fast teams can build. The question worth asking before you start is still the same one it’s always been.

    I’ve been in a few conversations recently with consultants selling agentic AI capabilities. The pitch is compelling. Agents can work autonomously, iterate on tasks, chain actions together, and operate at a scale no human team could match. The demos are impressive. The potential is real.

    What’s missing from most of those conversations is a question.

    Not “what problem are you trying to solve?” Not “what does your current process look like and where does it break?” Not “what would success look like and how would you measure it?” Just: here’s what agents can do, here’s how we’d deploy them, here’s what it would cost.

    The capability is the answer. The problem is implied.

    I’ve been thinking about that pattern since reading Andrew Ng’s recent letter in The Batch about agentic coding loops. His framing is worth engaging with directly because it’s honest and specific in a way that a lot of the current conversation isn’t. He’s describing a practice for building 0-to-1 prototypes in domains you don’t fully understand yet. Use a coding agent to build something quickly, react to what it produces, refine the spec, repeat. The argument is that seeing a working prototype is often the fastest way to discover what you actually want to build. Human judgment is scarce and expensive. Agent output is cheap. Use the cheap thing to sharpen the expensive thing.

    That’s a legitimate practice for a specific context. It’s not a general theory of how to use agents.

    When Exploration Becomes the Default

    The pattern Ng describes works because it has a boundary. You’re exploring an unfamiliar domain. You don’t yet have enough knowledge to write a good spec. The agent output isn’t the product. It’s a tool for developing the spec that will eventually drive the product. The iteration is purposeful. You’re getting smarter with each loop.

    The problem is when that exploratory posture gets extracted from its context and applied to everything. When “put agents on it and iterate” becomes the answer to problems that aren’t unfamiliar domains but rather well-understood organizational failures, poorly defined requirements, or processes nobody has bothered to map. When the iteration isn’t developing the spec. It’s substituting for it.

    This is the thousand monkeys problem. An infinite number of agents iterating on an undefined problem will eventually produce something that looks like a solution. You’ll have burned significant compute to get there, you won’t be certain the output is right, and you’ll still need a human to evaluate it against a definition of success that was never written down. The eval problem hasn’t been automated. It’s been deferred.

    What makes this harder to see than it sounds is that the iteration looks like progress. Things are being generated. Outputs are appearing. The agent is doing something. With human teams, the cost of spinning on an undefined problem was visible. It showed up in headcount, in sprint reviews, in frustrated engineers asking what they were actually building. With agents, that friction disappears. The inefficiency doesn’t. It scales.

    Solutions Looking for Problems

    This isn’t a new pattern. Every capability wave produces it. Someone gets good at building a thing. The thing is genuinely impressive. The capability becomes the product. And the question of whether the capability fits the problem gets answered implicitly because the capability is the answer.

    The organizations that get the most value from new technology are consistently the ones that start with a problem worth solving and find the technology that fits it. The ones that start with the technology and work backward to the problem spend a lot of time discovering that the fit isn’t what they expected.

    Agents are not exempt from this. They’re extraordinarily capable. That’s precisely what makes the skipped question more dangerous, not less. The more capable the tool, the easier it is to mistake activity for progress.

    The Question That Should Come First

    Ng’s framing contains the answer to the problem it doesn’t fully address. He says coming up with the spec, the evals, and the test set is one of the hardest tasks in agentic AI. Then he offers techniques for managing that difficulty once you’re already iterating. What he doesn’t dwell on, because his context is exploration where this is expected, is what happens when you start iterating before the spec exists in a context where it should.

    The question that should come before any agent deployment isn’t “what can agents do?” It’s the same question that should precede any technology investment: what problem are we solving, and how will we know when we’ve solved it?

    If the answer is clear, agents may be exactly the right tool. They can execute at a scale and speed that changes what’s possible. But if the answer is vague, or if the answer is “we’ll figure it out as we go,” then what you’re buying is expensive iteration on an undefined target. The agent will work very hard in a direction nobody has specified.

    That’s not a technology problem. It’s the same problem it’s always been.

    When a consultant walks in selling agents, the right first question isn’t about the technology. It’s about what breaks in your organization today that you believe agents would fix. If they can’t answer that, or if they’re surprised you asked, that’s useful information.

    The problem should come before the answer. It always should have.

  • If You Want to Keep Reading This Post

    If You Want to Keep Reading This Post

    If you want to keep reading this, I’m going to need you to type something on your keyboard every two minutes.

    Can you imagine? You’d close the tab. You’d go somewhere else. You’d tell someone about it.

    That’s the experience I had last night trying to activate a new phone through a major telecommunications company — one I actually worked for, about six years ago, when we were identifying these exact kinds of problems and trying to fix them.

    I typed my issue into the chat assistant. It responded with a workflow of pre-set options, none of which matched my situation. I clicked through five or six of them before typing “agent.” It asked me three more questions. Then it connected me to a human.

    The first thing the human said, after the greeting, was that I needed to type a message every two minutes to keep the session alive.

    Not them. Me. The customer who already has a problem. I have to do work to stay connected to the person trying to help me.

    That’s not an AI problem. It’s not even a problem AI can solve. It’s a product decision that someone made, or a technical limitation that someone accepted, and it’s been sitting there making customers feel like a burden since before I worked there.

    The Mute Button That Wasn’t

    While I waited, I started my audiobook on the same phone I was using for the chat. Every time a message came in from the agent, a notification sound interrupted the audio.

    I noticed a mute icon at the top of the chat. I tapped it. The icon changed to show it was muted. I restarted the audiobook.

    The next message came in. The sound played. The audiobook stopped.

    The mute button didn’t mute anything. It changed its icon. Those are not the same thing.

    This is a product problem. A design problem. Someone built a feature, shipped it, and either never tested it in a real use scenario or tested it and accepted the gap between what it looked like and what it did. A customer using a phone to listen to something while they wait on a chat is not an edge case. That’s Tuesday.

    These are the kinds of things you find when you walk through your own product as a customer. Not in a lab. Not with a test account. As a customer, with a real problem, in a real context, trying to get something done.

    An Hour Later

    After about an hour of troubleshooting, the agent, who was genuinely helpful and clearly trying, told me there was a process that needed to run on the back end. They’d put in a ticket. It would be resolved, but not tonight.

    Which meant I’d be without a phone until it was.

    I asked what I should do if there was an emergency. They offered a workaround: set up a new line, activate the phone on that, switch back later. Creative. But if the activation experience was this complicated, kicking it down the road felt like borrowing trouble. I declined and started wrapping up the chat.

    Then the agent, almost certainly prompted by their system, offered to tell me about current internet plan upgrades.

    I want to be precise about what happened there. My problem wasn’t solved. I was going to be without a phone overnight. The chat had taken an hour. And the system fired an upsell.

    That’s not a bug. Someone designed that. Someone looked at the data on upsell conversion and decided the trigger should fire regardless of whether the customer’s issue was resolved. The metric the team is measured on includes upsell attempts. So the system attempts the upsell. The customer experience is not the metric.

    What AI Has to Do With Any of This

    None of these problems are AI problems. The session timeout, the mute button, the upsell timing — none of them require a language model to fix. They require someone to walk through the product as a customer, identify what’s broken, and have the organizational support to fix it.

    Six years ago, when I worked there, we were calling out problems like these. Some got fixed. Some didn’t. The ones that didn’t weren’t technically hard. They were prioritization decisions. There was always something more exciting to work on, something more fundable, something that showed better in a demo. Now that something is AI.

    I work in AI. I know what the technology can do and I believe in it. But companies are investing heavily in making their customer service smarter while the foundational product and design problems that have existed for years go unfixed. The AI layer gets better. The experience layer stays broken. The customer lives in the experience layer.

    Here’s the question worth asking before the next AI investment: if you asked your customers what frustrated them most about your product, would any of them say it doesn’t have enough AI?

    Probably not.

    They’d say the mute button doesn’t work. They’d say they had to type every two minutes to keep the session alive. They’d say someone tried to sell them an internet upgrade after failing to activate their phone.

    Those are fixable. They were fixable six years ago. They’re still broken.

    Not because the technology doesn’t exist to fix them. Because the attention is somewhere else.

    I’m still thinking about the mute button.

  • Nobody Gets Credit for the Fire That Didn’t Start

    Nobody Gets Credit for the Fire That Didn’t Start

    Proactive leadership sounds straightforward. Here’s why the incentive structure works against it — and what it takes to change that.

    I’ve sat in a lot of status meetings where the room wasn’t really in the room.

    Leaders multitasking. Half-attention on the slide, half somewhere else. Risks documented, bubbled up, noted in the status email that went to the right distribution list. The process worked exactly as designed. The signal was observed, communicated, and received — technically. Then something breaks and the questions start. Why didn’t I know about this? You should have made sure I was more aware.

    And there it is. The accountability transfers from the person who didn’t receive the signal to the person who sent it. We told you. In the meeting. In the email. In the status. That’s the losing argument, even when it’s true.

    The Signal Was There

    This is worth sitting with, because it’s easy to read this as a leadership failure and stop there. It’s more complicated than that.

    The information existed. The risk was documented. The communication happened. By every formal measure, the organization did what it was supposed to do. The signal was in the system.

    But the signal was in our language, not theirs. We led with the technical risk, the process concern, the architectural debt. We expected the decision maker to translate that into their own terms — to connect the signal to the metric it would eventually impact and decide whether to act.

    That’s not their job. It’s ours.

    I spent a long time trying to convince decision makers in my own way, with what I thought was important, communicated the way I thought it should be communicated. The frustration when they didn’t respond felt justified. But it was misplaced. It wasn’t about me, or my argument, or the quality of the data. It was about whether I’d connected the signal to something they were already watching.

    That’s failure mode one. And it’s on us to fix it.

    The Signal Was There and It Didn’t Matter

    Failure mode two is harder, because it doesn’t have a personal fix.

    Even when the connection to the metric is made clearly — even when you’ve done the work to translate the risk into their language and show them what it will cost when it lands — if the metric isn’t hurting yet, the signal still loses the priority battle. The urgency isn’t there. There are other fires already burning, other things costing them something today rather than something they’d have to imagine.

    Future-tense risk is always competing against present-tense urgency. And present-tense urgency wins almost every time.

    I watched this play out at a company I worked for earlier in my career. Warning signs that a platform wasn’t scaling properly. The data was there. The analysis was done. The flags were raised. The response was essentially: we see it, we’ll deal with it, it’s not breaking anything yet. Until it was. The failure spread faster than anyone had planned for, the recovery was harder than it needed to be, and customers felt it in ways that could have been smaller or avoided.

    That’s not a communication failure. That’s a structural one.

    Know Your Audience

    The practical lesson from failure mode one — the one I learned the hard way — is simple to say and harder to do consistently.

    Lead with the metric. Not the technical risk, not the process concern, not the backstory. The number. The thing they’re already watching. Show them what happens to that number if the risk materializes, and when.

    The quality of your argument in your own terms is irrelevant if it doesn’t connect to theirs.

    Every decision maker has a set of incentives they’re optimizing for. Your job, when you need a decision, is to understand those incentives and use them to frame the choice. Show me the incentive and I’ll show you the outcome — that applies to the person you’re trying to persuade as much as it applies to the market.

    The frustration of learning this is real. There’s something that feels like a concession in it — like the data should be enough, the risk should be obvious, the right thing to do should be self-evident. It isn’t. The person who learns to speak the language of the people making decisions gets heard. The person who keeps communicating in their own language keeps getting frustrated.

    What This Can’t Fix

    Failure mode one is solvable. Better communication discipline, more deliberate connection of signals to metrics, more investment in understanding what the decision maker is watching. Teams can get better at it.

    Failure mode two is different. Even with perfect communication, risks that don’t impact a current metric still lose. Prevention doesn’t have a metric.

    Nobody gets credit for the fire that didn’t start.

    The fire that never started doesn’t show up in the quarterly review. The only thing that changes that is when the organization decides to measure it. When preventing the fire becomes something someone is accountable for. When the proactive decision gets credited for what it avoided rather than penalized for what it cost.

    Most organizations don’t do that until the fire forces them to.

    The Direction Worth Moving In

    If we can get better at failure mode one — close the communication gap, build the language, show through data that proactive decisions compound better than reactive ones — we earn something more valuable than avoided crises. We earn credibility. And credibility is what opens the door to the harder conversation.

    The harder conversation isn’t about this project or this risk. It’s about whether the metrics themselves are right. Whether the incentives the organization is optimizing for are the ones that produce the future it says it wants. The same discipline that connects a technical risk to a business metric can connect a business metric to a longer-term outcome. If you’ve built enough trust by being right about the near-term things, you get a hearing on the longer-term ones.

    That’s the direction. Reactive to proactive. And then, proactive about what we’re actually optimizing for.

    Right now, inside most organizations, the fire is still what gets attention.

    The goal is to change that before the fire starts.

  • Show Me the Incentive

    Show Me the Incentive

    AI investment priorities reveal more about what we value than any mission statement. Here’s what the numbers are actually saying.

    I was sitting in the gym at my son’s school on career day, watching kids rotate through tables staffed by a dog groomer, a police detective, a state park maintenance worker, and me. My topic was AI.

    I’d played them a song my son made using AI tools. I’d watched their faces when the music came out of a prompt. I’d thought about what these tools could mean for kids like the ones in that room — kids with different abilities, different challenges, different relationships with the systems that were supposed to serve them. The technology felt genuinely hopeful in that moment.

    Then I drove home and opened my inbox.

    I work in AI. I’ve spent more than a decade in this space. I believe in what the technology can do — I’ve seen it do things that matter. But I also watch the money, and the money is telling a different story than the hope.

    In 2026, four hyperscalers committed to a combined $700 billion in capital expenditure, nearly double what they spent the year before. That same year, federal funding for health and science research took cuts that one analysis described as a screeching, and possibly irreversible, halt for many projects. The Gates Foundation, Novo Nordisk Foundation, and Wellcome jointly committed $60 million to evaluate AI health tools in low- and middle-income countries. Sixty million dollars. Against $700 billion.

    That ratio is not an accident. It’s an incentive structure.

    Charlie Munger said it plainly: “Show me the incentive, and I’ll show you the outcome.” The incentive right now is return. The outcome is what we’re seeing — infrastructure investment at a historic scale, enterprise deployments producing almost no measurable ROI, and the applications that could matter most to the most people starved of the capital that’s going elsewhere.

    The Market Is Working Fine

    That’s the uncomfortable part. This isn’t a story about a broken system. The market is functioning exactly as designed. Capital flows to the highest expected return. Consumer AI applications have enormous addressable markets. Infrastructure that powers those applications generates reliable revenue. Health AI for rare neurological conditions has a small addressable market and a long development timeline. The math isn’t hard.

    Upton Sinclair put the human version of it this way: “It is difficult to get a man to understand something when his salary depends on his not understanding it.” The people making investment decisions aren’t ignoring the potential of medical AI out of malice. They’re ignoring it because the incentive structure doesn’t reward understanding it. Not yet. Maybe not until it’s too late to matter.

    My son has epilepsy. I think about what AI-driven research could mean for conditions like his — better seizure prediction, smarter medication titration, earlier intervention. I think about it the way any parent thinks about something that could help their kid. And I know better than to frame it as epilepsy versus cancer, because that’s a trap. The question isn’t which disease deserves the investment. The question is why we’ve built a system that forces us to choose between them at all, while $700 billion goes elsewhere.

    The answer is incentive. And right now, the incentive doesn’t point there.

    Progress and Profit Are Not the Same Thing

    Companies should make money. Profit funds research, attracts talent, builds the infrastructure that eventually enables the things that matter. The hyperscaler investments aren’t going nowhere — they’re building the compute layer that researchers will use for decades. AlphaFold happened because the underlying models and infrastructure existed. I know this. And the productivity gains from AI deployment are real. The capability improvements are real. Some of what’s being built right now will matter enormously.

    But profit and progress are not the same thing, and we keep talking as if they are. We tell the story of AI as the technology that will solve our biggest problems — climate, disease, inequality — while the actual investment pattern optimizes for something else. That gap between the story we tell and the system we’ve built is worth naming.

    The tendency to optimize for what’s measurable and near-term at the expense of what’s important and long-term is not something AI introduced. We’ve been here before. But the scale of this wave, its speed, and the environmental cost of the compute it requires compound the stakes in ways that previous cycles didn’t.

    The bubble will eventually correct. It always does. Ninety-five percent of enterprise AI pilots are producing no measurable return. The capital is burning, and the patience of the people funding it has a limit. When the correction comes, the investment will contract, the priorities will shift, and whatever window existed to point this technology at the hard problems will have narrowed.

    The people most likely to benefit from AI-driven medical research are not the people funding the infrastructure. The people absorbing the cost of the job displacement are not the people who will capture the upside when the next wave arrives. That asymmetry isn’t new. It’s the pattern every technology wave produces.

    What I Do Know

    The bubble will correct before the incentives do.

    That’s the pattern. And when it does, the window on the things that actually mattered will have narrowed — maybe irreversibly for some of them. Climate doesn’t wait for market corrections. Disease outbreaks don’t pause while capital regroups. Federal research budgets, once cut, don’t come back on the same timeline they left.

    The market won’t fix this on its own. It doesn’t have to — that’s not what markets are for. Regulation could change the incentives. Public funding could change them. Coordinated pressure from the organizations deploying AI could change them if those organizations decided that the story they’re telling about AI’s potential was one they wanted to be accountable for.

    None of that is happening at the speed the problem requires.

    Show me the incentive. The outcome is right there.

    What I’m Left With

    I drove home from career day thinking about those kids. About what the technology could mean for them if it pointed in their direction. About my son and what a different investment pattern might make possible for people like him.

    I still believe in the technology. I believe in what it can do when it’s pointed at the right problems. I’ve seen it.

    I just think we should be honest about where it’s pointed right now. And curious enough to ask whether that has to be true.

    Why are we doing it this way? Does it have to be this way? What would it look like to do it differently?

    Those aren’t rhetorical questions. They’re the ones worth sitting with.

  • The Lesson We Keep Not Learning

    The Lesson We Keep Not Learning

    Organizational learning is supposed to be how we get better over time. Here’s why we keep skipping it — and what AI reveals about that failure.

    I’ve been the person who knew better.

    Not once. More than once. You have data. You have a model. You have something that genuinely works, that you’ve tested, that you believe in. And you walk into a room with the business and you expect the quality of the thing to do the persuasion work. Because it’s good. Because you can see what it will do for them. Because if they just understood it the way you understand it, they’d want it too.

    It almost never works that way.

    The business isn’t wrong to resist. They have a roadmap. They have commitments. They have things they’re already behind on. You’re asking them to absorb something new, change how they work, take on risk, and trust that the upside you’re describing will actually materialize. The idea being good doesn’t answer any of those questions. It just asks them to take your word for it.

    I’ve watched this pattern play out more times than I can count — in myself, in colleagues, across organizations. Someone builds something they believe in, takes it to the business, gets a lukewarm response or an outright no, adjusts the what, and tries again. New idea, same method. The next version is better. The pitch is cleaner. The deck has more data. And it fails for the same reason the first one did, because the method didn’t change, only the artifact.

    The question that would have helped — and almost never gets asked — is this: based on what has and hasn’t worked before, what does successful adoption actually look like here, and what’s the path to get there?

    That’s not a question about the idea. It’s a question about the method. And it requires looking back at your own history before you move forward.

    We don’t do that. Not consistently. Not structurally. We survive the last failure, close the chapter, and start the next project with conviction instead of context.

    The Pageantry of the Post-Mortem

    When something goes badly enough that it demands acknowledgment, we have rituals for it. The retrospective. The lessons learned document. The post-mortem that produces action items nobody looks at again.

    I’ve sat in those rooms. There’s a specific energy to a post-mortem that’s being performed rather than practiced. Everyone agrees on what went wrong. The right language gets used. The document gets written. And then the next project starts and nobody opens it. Nobody asks: have we seen this before? Nobody maps the current situation against the last one.

    The lesson learned becomes a historical artifact rather than an operational input.

    I’ve watched senior leaders run the same failing initiative multiple times — different team, different framing, different artifact — because the diagnosis from the last attempt never got applied to the next one. The what kept changing. The how never did. The loop ran for years.

    Nobody was malicious. Nobody was incompetent. The lesson was available every time. It just never got encoded into anything that changed the next decision.

    What AI Does That We Don’t

    There’s a specific irony in this pattern emerging at the same moment that AI has become the dominant technology investment across industries.

    AI systems learn from the past. Not as a best practice or a cultural value, but as a structural requirement. A model that hasn’t been trained on historical data isn’t a model. The learning is automatic, systematic, and non-optional. Every inference is shaped by everything that came before it.

    More precisely: AI doesn’t just learn what happened. It learns the conditions under which things happened. A recommendation model doesn’t encode that users liked item X. It encodes that users liked item X when they arrived from a certain channel, at a certain point in their journey, after certain prior interactions. The context is part of the pattern. The how is part of what gets learned.

    We tend to only learn from the what.

    The product team changes the idea but not the method. The senior leader changes the team but not the diagnosis. The organization runs the post-mortem but doesn’t connect it to the next decision. We update the what and treat the how as a fresh problem every time.

    And then we deploy AI — a technology whose entire value proposition is systematic learning from history — without applying that same discipline to the organizational decisions about how to deploy it.

    We ask the model to learn from the past. We don’t ask ourselves the same thing.

    The Question Nobody Asks

    Before AI it was a compelling cloud architecture. Before that a web framework that would change everything. The pattern doesn’t belong to any particular technology. Conviction about the what has always had a way of short-circuiting the discipline of asking about the how.

    The question that would break the pattern isn’t complicated. It’s just uncomfortable.

    What has and hasn’t worked before, in this organization, with this kind of change? Not in general. Not at other companies. Here. With these people. Under these conditions. What did we try? What did we learn? What were the conditions when it worked, and what were the conditions when it didn’t?

    And then: given all of that, what’s the approach that gives this the best chance of actually landing?

    Before the next project kicks off, before the roadmap gets locked, before the pitch deck goes to leadership — pull up the last one. Not to relitigate it. To learn from it. Ask: did we change the how, or just the what?

    If the honest answer is just the what, you already know how this one ends.

  • The Question Is the Creativity

    The Question Is the Creativity

    The conversation around AI tends to focus on outputs. This post is about something upstream from that.

    I was in a room with a small group of engineers and product people. We had a standing rule for these sessions: no constraints. Not on money, not on time, not on what the law currently allowed. Laws change, and if we only invented inside existing rules we’d never get ahead of them. The goal was to ask questions nobody had thought to ask yet.

    One of those sessions started with a conversation between me and a colleague. His father had Parkinson’s. My son had ataxia, a neurological condition affecting coordination and balance that causes involuntary movement. We were talking about tremors, how they made it hard for devices to understand intentional gestures, how the technology kept misreading the signal. Somewhere in that conversation someone said: what if we thought about this the way noise-cancelling headphones work? Not filtering out the gesture, but filtering out the tremor. Separating the signal from the noise at the body level.

    That question became a patent.

    The patent room is an extreme version of something that happens every day in less formal settings. The standard for a patent is legal novelty, something that hasn’t existed before in that form. But the same upstream act, two experiences colliding into a question worth asking, happens whenever someone brings their specific life to a problem and asks it differently than anyone else would have. The question doesn’t have to be patentable to matter. It just has to come from somewhere a model can’t go.

    I’ve thought about that moment a lot since AI became the dominant conversation in technology. Because that question could not have come from a model. Not because the model isn’t capable of sophisticated reasoning. It is. But because the question didn’t come from reasoning. It came from two people’s lives colliding in an unconstrained space.

    That’s where creativity actually lives. Not in the execution. In the question.

    What the Room Was Actually Doing

    Those sessions had a specific energy. You removed the practical objections that normally narrow thinking before it has a chance to go anywhere interesting. No one said “that’s too expensive” or “we can’t do that yet.” You created space for people to bring their actual experience, not their professional expertise, but their lives. Their parents. Their kids. Their frustrations. Their observations from places that had nothing to do with the problem on the table.

    And then you let those things collide.

    We did a session focused on aging in place, how to help elderly people live independently longer, especially when their families were far away. Every person in that room had a version of that worry. A parent in another state. A grandparent who had fallen. The anxiety of not knowing. The ideas that came out of that session didn’t come from market research or competitive analysis. They came from people who were living the problem and had been given permission to imagine solutions without limits.

    That combination of unconstrained thinking plus personal stakes is what produces the questions worth asking. Remove the constraints and you get speculation. Add the personal stakes and you get invention.

    The cochlear implant came from a researcher whose child was deaf. He wasn’t analyzing the hearing aid market. He was watching his daughter navigate a world that hadn’t been designed for her and asking whether it had to be that way. The sticky note came from a choir singer who had been frustrated by a bookmark falling out of his hymnal for years before he connected that frustration to an adhesive a colleague had invented that nobody wanted. Neither of those connections was the product of a logical process. They were the product of a life that had been paying attention to a problem long enough to recognize an answer when it appeared from an unexpected direction.

    Personal stakes aren’t the only path to the right question. Plenty of inventors have no direct connection to the problem they’re solving. But stakes create a kind of attention that’s hard to replicate any other way. You notice differently when you care.

    The question came first. The execution came after.

    What AI Actually Does

    AI is extraordinarily good at execution. Given a well-formed question, it can explore the solution space faster and more thoroughly than any human team. It can find patterns across domains that no individual would have the bandwidth to survey. It can synthesize, generate, iterate, and refine at a scale that would have seemed impossible five years ago.

    I use it this way every day. And the back-and-forth of working with a model, the “that’s close but not quite it,” the steering toward something you can sense but not yet fully articulate, has its own creative quality. It reminds me of those patent sessions. The iterative energy of a room where ideas are being shaped in real time, where one person’s response moves another person’s thinking, where the answer emerges through the conversation rather than arriving fully formed.

    But there’s a difference. In that room, every person brought something the others didn’t have. Their specific experience, their specific frustration, their specific version of the problem. The model brings what it was trained on. Which is vast, more than any person in any room could hold, but it is still bounded by what humans have already thought, written, and recorded. It can recombine brilliantly. It cannot bring something from outside its training the way a person brings something from outside their expertise.

    The Constraint That Isn’t a Constraint

    We told those rooms: imagine no constraints. And it worked, because removing the practical filters let thinking go somewhere it couldn’t go otherwise.

    But you could give an AI the same instruction. “Imagine no constraints on money, time, or law. Solve this problem.” And it would produce output. Sophisticated output. Options and combinations and lateral connections across domains it has been trained on. It might even produce something that looks creative.

    What it can’t do is bring something from outside its training into that unconstrained space. The model has no constraints to remove because it has no constraints in the first place, and also no life experience pressing against those constraints, no accumulated frustration waiting for permission to become a question. The removal of constraints only matters if something was being constrained. In a human, what gets constrained is everything they’ve lived and observed and felt and noticed. Remove the filter and that floods in.

    The model has no equivalent. It can go wide within what it knows. It cannot go to the place where my colleague’s father’s tremor and my son’s tremor became the same problem.

    The Most Important Skill

    There’s a version of the AI conversation that focuses on prompting. How to write better prompts. How to get better output. How to work with the tools more effectively. That’s useful, and I’m not dismissing it.

    But I think it understates where the leverage actually is.

    The prompt is downstream of the question. And the question is downstream of the specific collision: your son’s tremor meeting your colleague’s father’s tremor, a choir singer’s bookmark meeting a chemist’s unwanted adhesive, a researcher’s deaf daughter meeting a question about whether the world had to be that way. That’s not experience in the abstract. It’s experience that has been building pressure against a specific problem long enough to recognize an answer when it comes from an unexpected direction.

    That capacity lives in you, not in the tools.

    What the Model Will Never Have

    The model has no son with ataxia. It has no colleague’s father with Parkinson’s. It has no parent far away whose silence worries it. It has no memory of a room where someone said “what if we” and everything shifted. It has no frustration that has been accumulating for years, waiting for the right collision.

    It has no stakes. It notices nothing differently because it cares about nothing. It brings no life to the question because it has no life to bring.

    Those aren’t limitations that will be engineered away. They’re not gaps in the training data or constraints on the context window. They’re the definition of what the tool is.

    And they’re the definition of what you are.

    The question comes from you. The creativity is yours. The execution, extraordinary, useful, genuinely remarkable, is something you can share.

    Don’t confuse the two.

  • The Same Rocket, A Different Ship

    The Same Rocket, A Different Ship

    AI investment is accelerating faster than any technology wave before it. The pattern underneath it is older than most of us realize.

    There is something deeply human about looking up.

    We’ve always done it. We looked at the stars and decided we belonged there. We looked at the horizon and built ships to cross it. We looked at problems that seemed impossible and found ways to make them less so. That instinct, the refusal to accept limits as permanent, is responsible for most of what we’ve built.

    It’s also responsible for a pattern that keeps repeating. And we never seem to learn it.

    Every generation gets a technology that feels like the one. The thing that will finally close the gap between what we can do and what we’ve always wanted to do. Computers. Then software. Then the internet. Then big data. Each one arrived with genuine capability and genuine promise. Each one attracted enormous investment. Each one produced real gains, new industries, new efficiencies, new possibilities that didn’t exist before. And each one, eventually, ran into the distance between what the demo promised and what the real world required.

    That gap never closed the way we expected. So we did what we always do.

    We threw more fuel at it.

    (more…)

  • The Leveler: The Use Cases Nobody Planned For

    The Leveler: The Use Cases Nobody Planned For

    I sat at a table in the gym at my son’s school. Around the room there was a dog groomer, a police detective, someone from the state park maintenance crew, and an archaeologist. We were there for career day. My topic was AI.

    When each group of kids came over, I played them a song. I told them my son made it. He had the idea, shaped the lyrics, and used AI tools to bring it to life. It’s on Spotify and Apple Music. The instruments, the vocals, the production were all generated by AI. But the idea, the story, the words were his.

    Some of the middle school kids had already used ChatGPT. A few had used it for homework. One wanted a training plan for a video game he was trying to get better at. One girl said she used it as someone to talk to.

    That last one stopped me. The adults in the room were thinking about AI in terms of what it might take from these kids. That girl was using it for something none of the adults had thought to offer her.

    (more…)