Compound Conversations

Most organizations have plenty of AI opinions. What they don't have is an AI rhythm. Opinions don't compound. Rhythms do.

In this episode, Julie Mann and Jesse Flores close out Season 1 of Compound Conversations with the step that makes everything else in the framework stick: the rhythm. You'll walk away knowing the four steps of the quarterly rhythm review, why most organizations are operating at the chatbot level without realizing how much value they're leaving behind, and what to do with the time AI frees up when you're running it as an organizational discipline rather than an individual tool.

If you've been following this series, this is the episode where the whole framework clicks into place.

Takeaways
Most companies say they're using AI and mean they have a chatbot. That's individual acceleration, not organizational transformation. The compounding value starts when you redesign the work itself, not when you prompt your way to a better output.

The quarterly rhythm has four steps: evaluate the last sprint at the outcome level, update your signal backlog with what surfaced during the sprint, commit the next sprint based on what still carries the highest business value, and update the hybrid accountability chart. Skipping the last step is how governance quietly falls apart.

When AI starts working at the organizational level, it will free up real time. Leadership needs to plan for that surplus before it arrives. Employees who suddenly have 10 or 15 hours a week back don't automatically know what to do with it, and figuring that out is a leadership decision, not a personal one.

Chapters
0:00 What the rhythm is and why it has to be operational
4:39 Why most organizations still aren't prepared to move past chatbots
9:13 The four steps of the quarterly rhythm review
14:03 The gap between using AI and compounding with it
26:01 Planning for the time AI gives back
40:23 Embedding this alongside EOS, Scaling Up, or any operating system

Connect with Compound
https://linktr.ee/compoundorg

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

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

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

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 chart
• 04:53 — Example: the video filing agent team
• 07:21 — Example: the daily ad performance report
• 09:43 — Individual efficiency vs. operational efficiency
• 17:00 — Name your agent teams before you lose track of them
• 19:25 — Buy, try, scale is backwards. Design before deploy.
• 24:09 — When Claude went down for an hour, and why you need fail safes
• 28:42 — Naming a human orchestrator (first and last name)
• 29:30 — Agents have a maturity curve too
• 31:00 — Fit matters: why the wrong human on the wrong agent team is a mismatch
• 33:27 — Teaching judgment, not tasks
• 38:08 — The prompt injection story: 100 calendar invites
• 42:52 — Governance: data access, approvals, kill switches
• 45:10 — Recap: visible and durable, not just accountable

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 implementation
• 02:27 Three categories: record, knowledge, and semantics
• 04:52 Why systems fail when the business process doesn't change
• 07:16 What the role is actually doing vs. what the job description says
• 09:37 Systems of knowledge and the document discipline problem
• 12:03 Structuring the unstructured
• 14:27 Two workforces, two cost structures
• 16:48 The token bill that's coming
• 19:14 The $2,000 surprise
• 21:34 The key bowl: a simple analogy for knowledge discipline
• 23:53 Every place AI has to look costs you something
• 26:18 Design steps: list your sources
• 28:46 APIs, MCPs, and connectors explained
• 31:09 Tiering your systems: assisted, notified, or automated
• 33:19 What's missing and how to find it
• 35:43 The 60-30 pattern
• 38:02 Why humans almost never need to do data entry
• 40:12 Making the design decisions
• 42:37 Stop transforming. Start compounding.

Register for Live Conversations via the link.
https://compoundorg.com/webinars

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 door
• Run 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.

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 Answer
• 02:16 Symptoms vs. Constraints: The Core Distinction
• 04:43 How to Write a Constraint Statement
• 09:24 The Real Reason Roles Turn Over
• 14:17 Room Dynamics and the Dominant Personality
• 21:32 Four Ways to Spot a Hidden Constraint
• 28:48 What AI Actually Needs to Work
• 33:26 The Constraint Statement, Step by Step

• • 40: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.

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 mindset
• Role Splitter tool Worksheet

Chapters

• 00:00 Mindset Shift for the Future of Work
• 28:19 Deconstructing Roles and Tasks
• 34:03 Mapping Roles to Human and Agent Columns
• 41: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.

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