Compound Conversations

Jesse Flores and Julie Mann
  • 0.0 (0)
  • Business

Most leaders running growing companies have bought the AI tools, hired the consultants, run the pilots, and still have nothing to show for it. The Compound podcast is for operators who are tired of that story. Every episode covers what actually changes when a growing company redesigns how its people and AI work together: the constraints worth solving, the organizational structures that make AI stick, and the education that turns a skeptical team into one that thinks AI before headcount. This isn't a show about what AI can do. It's a show about how to build a business where it does. Hosted by Jesse Flores and Julie Mann at Compound, the organizational design firm for AI.

Episodes

  1. 2d ago

    Compounding vs. scaling

    Most organizations are chasing scale. Scale is a rate, not a structure. Chase it before the structure exists and it breaks under its own weight. In this episode, Jesse Flores and Julie Mann break down the difference between scaling and compounding, and why treating the two as the same thing is the most expensive mistake in the current AI conversation. You will walk away understanding why scale is a byproduct of structure rather than a goal to pursue directly, what actually compounds from one sprint to the next, and how to spot vendor language that sells scale while calling it compounding. They also walk through all six stages of the Sequence: Signal, Source, Design, Build, Deliver, Compound. The infrastructure a sprint leaves behind, not the agent or workflow it produces, is what makes the next sprint cheaper to run. Takeaways Scaling is a rate. Compounding is a structure. Treating them as the same thing is why so many AI investments plateau instead of building on themselves. The real output of a sprint is not the agent or the workflow. It is the infrastructure that sprint leaves behind, which is what makes the next sprint cheaper to run. Compounding growth is geometric, not linear. That is the entire reason a fourth sprint costs a fraction of what the first one did. Chapters 0:00 Scale is a rate, compounding is a structure 2:23 The untrained marathon 7:13 Why compounding is geometric, not linear 14:27 The paradox of slowing down to speed up 24:04 What sprint one actually leaves behind Connect with Compound https://linktr.ee/compoundorg

  2. Aug 6

    Deployed is not the same as adopted

    Most organizations celebrate going live. Nobody plans for what comes after. That is where the investment quietly dies. In this episode, Jesse Flores and Julie Mann break down the difference between deployment and delivery — and why confusing the two is the most expensive mistake in AI implementation. You will walk away understanding why going live is a technical state and adoption is an organizational one, what changed handoffs, retraining, and real cost measurement actually look like in practice, and how to tell the difference between a project that launched and a workflow that landed. They also walk through the five dimensions of delivery — changed handoffs, retraining people, cost measurement, trust and adoption, and the shadow process — and why each one has to be tracked, not assumed. Takeaways Deployment is an event. Delivery is the phase nobody plans for. The three to four weeks after go-live is where most AI investments quietly stop compounding and start collecting dust. Changed tooling and changed behavior are not the same thing. Installing the tool is the easy part. Getting people to actually work differently is where the real adoption work begins — and it takes repetition, structure, and a culture that makes it safe to try and fail. If people are still doing something in secret that the new workflow was supposed to replace, that shadow process is not a problem to punish. It is the most valuable signal you have about where your delivery phase broke down. Chapters 0:00 Deployment as an event versus delivery as a phase 4:39 Where the investment quietly dies 11:56 Deployment is a technical state. Adoption is an organizational state. 21:58 The five dimensions of delivery 32:37 Trust, culture, and the shadow process Connect with Compound https://linktr.ee/compoundorg

  3. Jul 30

    Build, but not the way you have been pitched

    Most teams don't struggle with build. They struggle with everything they skipped before it. In this episode, Jesse Flores and Julie Mann break down exactly where build fits in the broader design sequence — and why the decision to buy off the shelf, blend tools with low-code, or build custom should come from your design, not from whoever called you last. You'll walk away knowing how to identify which path fits your situation, how to spot when a vendor call is doing the deciding for you, and how to walk into procurement with your problem already defined so you're the one doing the vetting. Jesse walks through building a full HR maturity assessment — the kind of tool a client uses to understand where their people practices actually stand — using nothing but Claude, with no developer involved. What made it work was that months of scattered knowledge got organized into a real measurement design before a single prompt asked for anything to be built. Takeaways The three build paths — off the shelf, low-code, hand-built — are not interchangeable. Each one fits a specific type of problem. Picking the wrong one because a vendor demo was compelling is how you end up rebuilding six weeks later. Vibe coding a real system without a locked design means the AI answered your question correctly — you just hadn't finished asking it. Bloated, insecure tools come from incomplete specs, not from bad AI. A locked design spec is what keeps vendors from selling you the wrong thing. When you walk in already knowing what problem you're solving, the call becomes evaluation instead of education. Chapters 0:00 Why build isn't the hard part 2:08 The three paths: buy, blend, or build 10:28 The HR assessment built with no developer 17:09 Off the shelf — and when it actually fits 21:20 How a locked spec changes a vendor call 41:31 When hand-building is worth it Connect with Compound https://linktr.ee/compoundorg

  4. Jul 2

    Design before deploy

    If you're running the Entrepreneurial Operating System, you already have an accountability chart. It names who owns what outcome. But the moment an agent or an agent team enters the work, that chart goes silent. No box, no owner, no accountability. In this episode, Jesse and Julie introduce the hybrid accountability chart, a layer that runs on top of the one you already have. It maps a dual workforce, human and agent, so every outcome carries four things: the outcome itself, the agent or agent team doing the work, the human supervisor who owns it, and the level of autonomy that team is allowed to operate at. They walk through it with two real examples from inside Compound: a small agent team that files video footage so nobody burns an afternoon hunting for a clip, and a daily Facebook ads report that lands by text every morning at 7am. Same structure both times. Name the outcome, name the team, name the human who's accountable when something breaks. They also cover where this goes wrong. What it means to match the right human to the right agent team, and why Jesse wouldn't hand his ad reporting team to someone without the context to judge its output. Why agents have a maturity curve just like people do. What happens when an agent hits an input it wasn't built for, told through the story of a prompt injection that nearly booked a hundred fake appointments across a quarter of Jesse's calendar. And why "how can we use AI" is the wrong first question, every time. Design before deploy. Know the outcome, name the owner, then decide what to build or buy. The goal isn't just accountability, it's a structure you can see and one that holds up. Stop transforming. Start compounding. Click Here to Connect with Compound --- Chapters 00:00 — If you run EOS, you already have this chart. It just doesn't account for AI.02:26 — The four parts of a hybrid accountability chart04:53 — Example: the video filing agent team07:21 — Example: the daily ad performance report09:43 — Individual efficiency vs. operational efficiency17:00 — Name your agent teams before you lose track of them19:25 — Buy, try, scale is backwards. Design before deploy.24:09 — When Claude went down for an hour, and why you need fail safes28:42 — Naming a human orchestrator (first and last name)29:30 — Agents have a maturity curve too31:00 — Fit matters: why the wrong human on the wrong agent team is a mismatch33:27 — Teaching judgment, not tasks38:08 — The prompt injection story: 100 calendar invites42:52 — Governance: data access, approvals, kill switches45:10 — Recap: visible and durable, not just accountable

  5. Jun 25

    What your judgment heavy role is actually doing all day

    Every senior role has a job description. Almost none of them reflect what that role is actually doing all day. In this episode, Jesse and Julie break down the 60-30 pattern, the diagnostic signal that surfaces when you look at how judgment-heavy roles actually spend their time. The finding is consistent: these roles spend sixty percent of their time on coordination, routing, documentation, and policy questions, and only thirty percent on the actual judgment they were hired to exercise. And that ratio is one of the clearest signals that your organization isn't ready to compound. You'll walk away able to do three things: Categorize your organization's knowledge systems into the three buckets that determine how AI can use them: systems of record, systems of knowledge, and systems of semantics.Apply the 60-30 diagnostic to identify where senior capacity is being absorbed by work that belongs somewhere else.Map your sources, assess API and MCP connectivity, and tier your automation decisions so your design matches the actual work. They also walk through the real cost of disorganized knowledge, not just the human cost of wasted time, but the token cost your AI workforce incurs every time your data isn't clean. Jesse shares a real story about a $2,000 surprise token bill in six days and what it revealed about the gap between how humans tolerate messy systems and how AI prices them. There's a downloadable systems map worksheet so you can run this on a real process before the week is out. Chapters 00:00 The knowledge problem underneath every AI implementation02:27 Three categories: record, knowledge, and semantics04:52 Why systems fail when the business process doesn't change07:16 What the role is actually doing vs. what the job description says09:37 Systems of knowledge and the document discipline problem12:03 Structuring the unstructured14:27 Two workforces, two cost structures16:48 The token bill that's coming19:14 The $2,000 surprise21:34 The key bowl: a simple analogy for knowledge discipline23:53 Every place AI has to look costs you something26:18 Design steps: list your sources28:46 APIs, MCPs, and connectors explained31:09 Tiering your systems: assisted, notified, or automated33:19 What's missing and how to find it35:43 The 60-30 pattern38:02 Why humans almost never need to do data entry40:12 Making the design decisions42:37 Stop transforming. Start compounding. Register for Live Conversations via the link. https://compoundorg.com/webinars

  6. Jun 18

    Knowledge that walks

    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. Takeaways Institutional 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 failure 02:24 The "Charlie" scenario 07:05 When knowledge walks: a real story 11:49 Institutional knowledge as a balance sheet asset 18:52 Onboarding drag and why we don't have to accept it 23:38 Knowledge isn't a continuity risk. It's the cake. 33:13 Finding your load-bearing roles 40:33 The interview questions that surface judgment 47:45 Design before deploy Register for Live Conversations via the link.

  7. Jun 18

    Symptom vs Constraint

    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. Takeaways Symptoms 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. Chapters 00: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

  8. Jun 4

    The wrong question, and the right one

    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. Takeaways Task-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 Worksheet Chapters 00: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

  9. Jun 1

    Adoption is not the problem. Design is.

    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. Chapters 00:00 Preparing for Adoption 07:56 The Human Role in System Design 14:56 Outcome and Process Clarity 42:53 Key Principles for Organizational Success

  10. May 29

    Why your AI investment is not showing up on the P&L

    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.

  • 10 Episodes

About

Most leaders running growing companies have bought the AI tools, hired the consultants, run the pilots, and still have nothing to show for it. The Compound podcast is for operators who are tired of that story. Every episode covers what actually changes when a growing company redesigns how its people and AI work together: the constraints worth solving, the organizational structures that make AI stick, and the education that turns a skeptical team into one that thinks AI before headcount. This isn't a show about what AI can do. It's a show about how to build a business where it does. Hosted by Jesse Flores and Julie Mann at Compound, the organizational design firm for AI.

Information

  • Creator
    Jesse Flores and Julie Mann
  • Years Active
    2026
  • Episodes
    10
  • Rating
    Explicit
  • Copyright
    © 2026 Jesse Flores and Julie Mann
  • Show Website
    Compound Conversations