Compound Conversations

Most organizations don't lose institutional knowledge when people leave. They lose it the day they stopped treating it as an asset.In this episode, Jesse and Julie break down the knowledge transfer problem that sits underneath nearly every stalled AI implementation and why it isn't an HR problem or a succession planning problem. It's a design problem. You'll walk away able to do three things: Identify the load-bearing roles in your organization before someone walks out the doorRun a structured knowledge capture interview that surfaces the judgment, exceptions, and rules of thumb that never make it into a job description. Sort what you've captured using the TML framework so your agents actually have what they need to execute.They also walk through the difference between documentation and capture, why transcripts are the highest-leverage starting point for any knowledge management discipline, and how to calculate the opportunity cost of the institutional knowledge that's currently living in someone's head without a backup. There's a downloadable interview worksheet with the questions — what decisions do you make that nobody else makes, what exceptions have you handled, what would a new hire get wrong — so you can run this on a real role before the week is out.TakeawaysInstitutional knowledge doesn't show up on the balance sheet, but it carries a real opportunity cost. The production you aren't getting from your AI agents is often a direct result of the knowledge you haven't captured yet.The load-bearing role in your organization isn't always the one with the most visible title. It's the one whose absence would cause the most people to stop working — the signature, the translator, the person everyone already knows to route things through.You cannot automate what lives in a person's head. The discipline of knowledge capture isn't a nice-to-have for successful AI implementation. It's the prerequisite.Chapters 00:00 The context problem underneath every AI failure02:24 The "Charlie" scenario07:05 When knowledge walks: a real story11:49 Institutional knowledge as a balance sheet asset18:52 Onboarding drag and why we don't have to accept it23:38 Knowledge isn't a continuity risk. It's the cake.33:13 Finding your load-bearing roles40:33 The interview questions that surface judgment47:45 Design before deployRegister for Live Conversations via the link.

Most leadership teams already know something is wrong. They can feel it. The list is full, the meeting cadence is spinning, and the same problems keep showing up week after week.What they don't realize is that the list itself is the problem.In this episode, Jesse and Julie break down the difference between a symptom and a constraint, and why solving symptoms is what keeps the list perpetual. You'll walk away able to do three things: identify whether your team is solving the real problem or just the most visible one, run the Five Whys to get past the emotional first layer and down to the structural root, and write a constraint statement that names the function, the failure, and the cost in one sentence your whole team can act on.They also walk through the Is vs Is-Not test, four signals that a constraint is hiding in plain sight, and why the role that turns over the most in your organization is usually the fastest path to finding what's actually broken. There's a downloadable constraint statement worksheet, so this isn't just a framework you can apply it to a stuck problem on your team before the week is out.TakeawaysSymptoms are visible. Constraints are structural. Solving symptoms keeps the list perpetual; solving the constraint makes the problem stop recurring.The Five Whys is uncomfortable by design. Most teams stop too early. Getting to the structural root requires pushing past the emotional first layer, where people apologize instead of diagnose.The constraint statement gives every level of your organization a shared language for naming what is actually in the way: function cannot desired outcome, because root cause, which costs approximately X per Y time period.Chapters00:00 Why the List Is Never the Answer02:16 Symptoms vs. Constraints: The Core Distinction04:43 How to Write a Constraint Statement09:24 The Real Reason Roles Turn Over14:17 Room Dynamics and the Dominant Personality21:32 Four Ways to Spot a Hidden Constraint28:48 What AI Actually Needs to Work33:26 The Constraint Statement, Step by Step• • 40:03 Making It a Cultural Shift

Most leadership teams already know something is wrong. They can feel it. The list is full, the meeting cadence is spinning, and the same problems keep showing up week after week.What they don't realize is that the list itself is the problem.In this episode, Jesse and Julie break down the difference between a symptom and a constraint, and why solving symptoms is what keeps the list perpetual. You'll walk away able to do three things: identify whether your team is solving the real problem or just the most visible one, run the Five Whys to get past the emotional first layer and down to the structural root, and write a constraint statement that names the function, the failure, and the cost in one sentence your whole team can act on.They also walk through the Is vs Is-Not test, four signals that a constraint is hiding in plain sight, and why the role that turns over the most in your organization is usually the fastest path to finding what's actually broken. There's a downloadable constraint statement worksheet, so this isn't just a framework you can apply it to a stuck problem on your team before the week is out.TakeawaysSymptoms are visible. Constraints are structural. Solving symptoms keeps the list perpetual; solving the constraint makes the problem stop recurring.The Five Whys is uncomfortable by design. Most teams stop too early. Getting to the structural root requires pushing past the emotional first layer, where people apologize instead of diagnose.The constraint statement gives every level of your organization a shared language for naming what is actually in the way: function cannot desired outcome, because root cause, which costs approximately X per Y time period.Chapters00:00 Why the List Is Never the Answer02:16 Symptoms vs. Constraints: The Core Distinction04:43 How to Write a Constraint Statement09:24 The Real Reason Roles Turn Over14:17 Room Dynamics and the Dominant Personality21:32 Four Ways to Spot a Hidden Constraint28:48 What AI Actually Needs to Work33:26 The Constraint Statement, Step by Step40:03 Making It a Cultural Shift

Most teams don't get stuck because they lack tools. They get stuck because they're answering the wrong question usually some version of "what do we build?" long before they've figured out what actually needs solving.In this episode, Julie and Jesse break down how to catch that wrong question in the moment, reframe it into the right one, and pressure-test where a problem really lives. You'll walk away able to do three things: spot a "tool question" before it sends you down the wrong path, apply the Two-Question Test to get to the real constraint, and use the Roll Split to separate structural gaps from behavioral ones because a structural gap can't be fixed with a behavioral fix.Along the way they connect it back to the difference between task orientation and goal orientation, and set up the idea of hybrid accountability that the rest of the series builds on. There's a worksheet and a real example to work through, so this isn't theory it's something you can run on your own stuck project this week.TakeawaysTask-oriented questions lead to emotional reactions and fear of job replacement, while outcome-oriented questions align with organizational goals and shared responsibilities.The future of work requires a shift from task-driven thinking to outcome-driven thinking, emphasizing the importance of human direction, understanding of outcomes, and alignment with organizational mission and values. Outcome-focused mindsetRole Splitter tool WorksheetChapters00:00 Mindset Shift for the Future of Work28:19 Deconstructing Roles and Tasks34:03 Mapping Roles to Human and Agent Columns41:47 AI Design and Shared Responsibility

When a pilot stalls, the instinct is to blame the people who are not using the tools. This episode makes the case that the failure almost always happens upstream, before the tool ever gets deployed. Clear outcomes, documented processes, and a named owner are not "nice to haves". They are the design.Jesse Flores and Julie Mann break down one of the most common misdiagnoses in AI implementation: the adoption problem that is actually a design problem.Chapters00:00 Preparing for Adoption07:56 The Human Role in System Design14:56 Outcome and Process Clarity42:53 Key Principles for Organizational Success

Jesse Flores and Julie Mann open Compound Conversations by tackling the headcount paradox: why companies that have spent money on AI still can't point to a measurable return.Julie brings decades of HR and organizational design experience, including time as a Chief HR Officer overseeing 44 countries. Jesse brings a background in software engineering and AI systems. Together they make the case that the failure isn't the technology — it's the organizational design around it.From the "tools and training reflex" to role deconstruction and the six-step Compound sequence, this first episode is about why leaders need to stop chasing capacity and start chasing clarity before AI can ever show up on the P&L.