David Monnerat

Product + AI | Systems Thinker | Enterprise Reality

Category: leadership

  • 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…)
  • Defining Success Criteria: Do You Know Where You Are Going?

    Defining Success Criteria: Do You Know Where You Are Going?

    It was the tenth call.

    I had been on the first one. A customer data project, matching records across systems to connect outcomes to the right source. It seemed straightforward enough that I handed it off and moved on. What followed was eight more calls between my team and the customer, each one ending with a tweak to the logic, each tweak fixing something and revealing something else.

    The problem wasn’t the code. It wasn’t the team. It was that nobody had defined success criteria before the work started. Nobody had asked: what does done actually look like?

    By the time my team pulled me back in, it was already swirling. The customer’s manager had joined too. I suspect that because the issue still wasn’t resolved, he felt the need to get involved. We had a piece of logic built by people who were no longer on the team, results that were almost always right, and a team that had been grinding on this for weeks.

    I asked a simple question: What do you actually want?

    That was it. Every previous conversation had been about what the code wasn’t doing right, assuming the approach was sound and just needed adjustment. Nobody had stopped to ask whether the approach itself was the right one. The answer to that simpler question was: when this happens, here is what we expect to see. And the solution that followed was far simpler than what we had been building toward. A defined set of conditions, clearly mapped to outcomes. The complexity we had been wrestling with wasn’t a feature of the problem. It was a feature of never having properly defined the problem.

    We left that meeting with a clear destination. We should have had that conversation on call one.

    (more…)
  • The White Whale

    The White Whale

    In Moby-Dick, Captain Ahab’s relentless pursuit of the white whale isn’t just a quest for revenge; it’s a cautionary tale about obsession. Ahab becomes so consumed by his singular goal that he ignores the needs of his crew, the dangers of the voyage, and the possibility that his mission might be misguided.

    This mirrors a common trap in problem-solving: becoming so fixated on a single solution—or even the idea of being the one to solve a problem—that we lose sight of the bigger picture. Instead of starting with a problem and exploring the best ways to address it, we often cling to a solution we’re attached to, even if it’s not the right fit or takes us away from solving the actual problem.

    A Cautionary Tale

    Call me Ishmael.1 – Herman Melville

    I once worked on a project to identify potential customer issues. The business provided the context and success metrics, and we were part of the team set out to solve the problem.

    After we started, an executive on the project who knew the domain had a specific vision for how the solution should work and directed us on exactly what approach to use and how to implement it. While their approach seemed logical to them, it disregarded key best practices and alternative solutions that could have been more effective.

    We ran experiments to test both the executive’s approach and an alternative, using data to demonstrate how a different approach produced better results and would improve business outcomes.

    But the executive was undeterred. They shifted resources and dedicated teams to their solution, intent on making it work. We continued a separate effort in parallel but without the resources or backing of the received by the other team.

    The Crew

    Like the crew of the Pequod, the teams working on the executive’s solution were initially excited about the attention and resources. They came up with branding and a concept that made for good presentations. The initial few months were spent creating an architecture and building data pipelines under the presumption that the solution would work. Each update gave a sense of progress and success as items were crossed off the checklist.

    That success, though, was based on output, not outcomes. Along the way, the business results weren’t there, and team members began to question the approach. However, even with these questions and the evidence that our approach was improving business outcomes, the hierarchical nature of the commands kept the crew from changing course.

    The Prophet

    In Moby Dick, Captain Ahab smuggles Fedallah, an almost supernatural harpooner, onto the ship as part of a hidden crew. Fedallah is a mysterious figure who serves as Ahab’s personal prophet, foretelling Ahab’s fate.

    Looking for a prophet of their own, our executive brought in a consulting firm to see if they could get the project on track. The firm’s recommendations largely mirrored those of our team. However, similar to Fedallah’s prophecies, the recommendations were misinterpreted. What we saw as clear signals to change course, the executive saw as a chance of success and doubled down on their solution.

    The Alternate Mission

    Near the end of the novel, the captain of another vessel, the Rachel, pleads with Ahab to help him find his missing son, lost at sea. Ahab refuses because he is too consumed by his revenge. Ultimately, the obsession costs Ahab his life as well as those of his crew, with the exception of Ishmael, who was, ironically, rescued by the Rachel, the whaling ship that had earlier begged Ahab for help.

    We tried to bridge the gap between the two efforts for years, but the executive’s fixation on their solution made collaboration impossible. We made a strong case using data to change the mission from making their solution work to refocusing on the business goals and outcomes. Unfortunately, after many attempts, we weren’t able to convince them or affect their bias and feelings that their solution should work. Too many claims had already been made, and too much had been invested to change course. The success of their solution was the only acceptable end of the journey, with that success always being just over the horizon.

    A Generative White Whale

    I’ve been thinking about this story lately because I see the same pattern happening with generative AI. Just as Captain Ahab chases Moby Dick, many companies chase technological solutions without fully understanding if those solutions will solve their real business problems.

    Since ChatGPT was launched to the public in 2022, there has been pressure across industries to deliver on generative AI use cases. The impressive speed at which users signed up and the ease at which ChatGPT could respond to questions gave the appearance of an easy implementation path.

    Globally, roadmaps were blown up and rebuilt with generative AI initiatives. Traditional intent classification and dialog flows were replaced with large language models in conversational AI and customer support projects. Retrieval-augmented generation changed search and summarization use cases.

    Then, the world tried to use it. Everyone quickly learned that the models didn’t work out of the box and underestimated the amount of human oversight and iteration needed to get reliable, trustworthy results.2 We learned that their data wasn’t ready to be consumed by these models and underestimated the effort required to clean, label, and structure the data for generative AI use cases. We learned about hallucinations, toxic and dangerous language in responses, and the need for guardrails.

    But the ship had sailed. The course had been set. Roadmaps represent unchangeable commitments3. The mission to hunt for generative AI success continued.

    What started with use cases with clear business outcomes inherited from the pre-generative AI days started to change. Rather than targeting problems that could significantly impact business goals, the focus shifted to finding problems that could be solved with generative AI. Companies had already invested too much time, money, and opportunity cost, and they needed to deliver something of value to justify the voyage.4,5

    It became an obsession.

    A white whale.

    Chasing the Right Whale

    I try all things, I achieve what I can.6 – Herman Melville

    That’s not to say there isn’t a place for generative AI or other technology as possible solutions. I’ve been working with AI for almost a decade and have seen how it can be truly powerful and transformative when applied to the right use case that aligns with business outcomes and solving customer or business problems.

    Experimenting with the technology can foster innovation and uncover new opportunities. However, when the organization shifts focus away from solving its most critical business problems and towards delivering a solution or leveraging a specific technology for the sake of the solution or the technology, misalignment between those two paths and choosing the wrong goal can put the entire mission at risk. The mission should always be the success of the business, not the technology.

    That’s the difference between chasing the white whale and chasing the right whale.

    Assess Your Mission

    The longer a project goes on, the more likely it will veer off course. Little choices over time make small adjustments to direction that can eventually lead to being far away from the intended destination. The same thing can happen with the overall mission. Ahab started his journey hunting whales for resources and, while he was still technically hunting a whale, his mission changed to revenge. If he took the time to reassess his position and motivation, Moby Dick would have had a less dramatic ending.

    As product and delivery teams, it’s healthy practice to occasionally look up and evaluate the current position and trajectory. While there may be an argument for intuition in the beginning, as more information becomes available, it’s important to leverage data and critical thinking rather than intuition and feelings which are more prone to bias.

    These steps can help guide that process.

    1. Reaffirm Business and Customer Priorities.

    Align leadership around the most critical problems. Start by revisiting the company’s core objectives and defining success. Then, identify the biggest challenges facing the business and customers before considering solutions.

    2. Audit and Categorize Existing Projects

    Identify low-impact or misaligned projects. List all ongoing and planned AI initiatives, categorizing them based on:

    • Business impact (Does it solve a top-priority problem?)
    • Customer impact (Does it improve user experience or outcomes?)
    • Strategic alignment (Is it aligned with company goals, or is it just chasing trends?)

    An important factor here is articulating and measuring how the initiative impacts business and customer goals rather than relates to a business or customer goal.

    For example, a common chatbot goal is to reduce support costs (business goal) by answering customer questions (customer goal) without the need to interact with a support agent. A project that uses generative AI to create more natural responses might look like it’s addressing a need, but it assumes that a more conversational style will increase adoption or improve outcomes. However, making responses more conversational doesn’t necessarily make them more helpful. If the chatbot still struggles with accurate issue resolution, customers will escalate to an agent anyway.

    3. Assess Generative AI’s Fit

    Ensure generative AI is a means to an end, not the goal itself.

    Paraphrasing one of my mantras I would use when a team approached me with an “AI problem” to solve:

    There are no (generative) AI problems. There are business and customer problems for which (generative) AI may be a possible solution.

    For each project, ask: Would this problem still be worth solving without generative AI?

    If a generative AI project has a low impact, determine if there’s a higher-priority problem where AI (or another solution) could create more value.

    4. Adjust the Roadmap with a Zero-Based Approach

    Rather than tweaking the existing roadmap, start from scratch by prioritizing projects based on impact, urgency, and feasibility.

    Reallocate resources from lower-value AI projects to initiatives that directly improve business and customer outcomes.

    5. Set Success Metrics and Kill Switches

    Define clear, measurable success criteria for every project. Establish a review cadence (e.g., every quarter) to assess whether projects deliver value. If a project fails to meet impact goals, have a predefined exit strategy to stop work and shift resources.

    This structured approach ensures that AI projects are evaluated critically, business needs drive technology decisions, and resources are focused on solving the most important problems—not just following trends.

    Conclusion

    The lesson of Moby-Dick is not just about obsession—it’s about losing sight of the true mission. Ahab’s relentless pursuit led to destruction because he refused to reassess his course, acknowledge new information, or accept that his goal was misguided. In business and technology, the same risk exists when companies prioritize solutions over problems and fixate on a specific technology rather than its actual impact.

    Generative AI holds incredible potential, but only when applied intentionally and strategically. The key is to stay grounded in business priorities, customer needs, and measurable outcomes—not just the pursuit of AI for AI’s sake. By regularly evaluating projects, questioning assumptions, and ensuring alignment with meaningful goals, teams can avoid chasing white whales and steer toward solutions that drive success.

    The difference between success and failure isn’t whether we chase a whale—it’s whether we’re chasing the right one.

    And I only am escaped alone to tell thee.7 – Herman Melville

    1. “Call me Ishmael.” This is one of the most famous opening lines in literature. It sets the tone for Ishmael’s role as the narrator and frames the novel as a personal account rather than just an epic sea tale. ↩︎
    2. https://www.cio.com/article/3608157/top-8-failings-in-delivering-value-with-generative-ai-and-how-to-overcome-them.html ↩︎
    3. Roadmaps are meant to be flexible and adjusted as priorities and opportunities change. ↩︎
    4. https://www.journalofaccountancy.com/issues/2025/feb/generative-ais-toughest-question-whats-it-worth.html ↩︎
    5. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025 ↩︎
    6. This quote from Ishmael reflects a spirit of perseverance and pragmatism, emphasizing the importance of effort and adaptability in the face of challenges. ↩︎
    7. The closing line of the novel echoes the biblical story of Job, in which a lone survivor brings news of disaster, underscoring the novel’s themes of fate, obsession, and destruction. ↩︎
  • In Defense of One-on-Ones

    In Defense of One-on-Ones

    Earlier this week, a former colleague forwarded me a video of Airbnb CEO Brian Chesky in an interview with Fortune saying he doesn’t believe in one-on-one meetings.

    The full context might reveal nuances specific to certain managerial levels. For example, he could have been referring to CEOs having one-on-ones with the rest of the C-suite who report to them. However, most of his references were to “employees,” and most of the comments on the video seem to generalize across all one-on-ones. Based on the video and related commentary, there appears to be growing skepticism about the value of one-on-ones.

    I’ve worked for bosses who didn’t see the value in one-on-ones, and I’ve worked for bosses who would use them to drive their agenda. When managers ignore or misuse one-on-ones, employees feel undervalued, disconnected, and unsupported.

    I’ve also been fortunate to work for bosses who modeled what a one-on-one should be. When managers prioritize regular one-on-ones, employees feel heard, supported, and valued. This fosters trust, alignment, and engagement, benefiting both the employee and the organization.

    Based on my experience, getting rid of one-on-ones is a terrible idea. (However, I favor getting rid of bad one-on-ones.)

    A few comments from the video highlighted misconceptions about one-on-ones or are signals of a bad one-on-one.

    “The employee owns the agenda. And what happens is they often don’t talk about the things you want to talk about.”

    One-on-ones are more than just about the agenda — they’re about building trust, understanding what motivates your team, and catching minor issues before they become big problems. Even if the employee’s agenda doesn’t directly overlap with your immediate goals, it gives you insight into what they’re thinking and feeling, which can help you guide them more effectively.

    That said, there are ways to make the meeting productive for both sides. The beauty of one-on-ones is that they’re a two-way conversation. While employees should have space to bring up what’s important to them, the manager also has an opportunity to steer the conversation toward topics they find valuable. It doesn’t have to be one or the other — it can be a balance.

    One way to address this is by co-creating the agenda. Before each meeting, you could ask the employee to suggest a couple of items they want to discuss, and you can add one or two topics that align with what you want to address. That way, both sides feel heard, and the meeting stays focused.

    In the spirit of the statement in the video, resist the temptation to control the full agenda. Remember, the one-on-one should be about the employee…not everything needs to be about you.

    “You become their therapist” and “They’re bringing you problems but often times they’re bringing you problems that you want other people in the room to hear. In other words, there’s very few times an employee should come to you one-on-one without other people.”

    One aspect of this comment I agree with is that some conversations are more appropriate in a team setting. Employees sometimes talk about their work or the project status they should bring up with the full team, such as surfacing a new issue. The nod to Jensen Huang’s quote, “I don’t do one-on-ones because I want everyone to be part of the solution and get the wisdom” is appropriate.

    But often, employees bring these topics up because they think that’s what their manager wants to hear. After all, that’s the only thing their manager asks about in one-on-ones.

    Sometimes, an employee, especially a junior one, doesn’t know how to bring a difficult topic up to the team. As a leader, those present opportunities to coach them and help shape how to bring those items to the team in a way that supports your organization’s culture.

    Finally, if an employee is bringing you items that are genuinely more appropriate for a therapist, you, as a leader, should set those boundaries and guide them to a more appropriate forum. However, don’t dismiss these topics when they relate to workplace well-being…the employee may be asking for accommodations, not solutions.

    “If they’re concerned about something, if they’re having a difficult time in their personal life, if they want to confide in something; they don’t feel safe telling a group. But that should be infrequent.”

    As I mentioned above, if the employee brings challenges in their personal life, look for opportunities to provide accommodations, not solutions. If the employee expects more and you are not willing, capable, or permitted to engage further, guide them to appropriate resources.

    But if they don’t feel safe bringing a topic to a group, coming to you is a gift. It’s a sign that your team has a perceived lack of safety or a potentially unhealthy dynamic that needs to be addressed.

    Also, while these items should be infrequent, this is not an exhaustive list of topics appropriate for a one-on-one conversation. Career development, goals, feedback, and recognition should be regular topics, too.

    Even with the expanded list of potential topics, there’s also no requirement that one-on-ones be weekly. It’s less about the frequency and more about the regularity and building a strong, trusting relationship that empowers the employee to thrive.

    A final note on bad one-on-ones…

    One of my first managers to schedule one-on-ones (probably from a corporate directive) said, “We’re going to have one-on-ones. Send me an agenda beforehand.”

    “Send me an agenda” is ambiguous and intimidating, especially for junior employees. I had no other context, no list of suggested topics, and no idea what I was doing. I would send a status-focused agenda because that’s all I knew. I don’t think either of us got much out of those meetings.

    Eventually, I reported to a different manager who also scheduled regular one-on-ones. When I sent the agenda, my manager stopped by to apologize for assuming that I understood the purpose of the meeting. They helped me move from a status-focused agenda to one that balanced my work, career, and where I needed help. I felt seen and supported, and that showed up in my work.

    While both the employee and the manager can be responsible for bad one-on-one meetings, the balance of responsibility skews toward the manager because they hold the leadership role and set the tone for the meetings.

    As a leader, take the responsibility and focus it on what is best for your employees and organization.

    Don’t abolish one-on-ones.

    Make them better.