Compound: Turn One Sprint Into Infrastructure
Compound is the sixth stage of the Sequence — the one that turns a delivered Sprint into the foundation of the next one. You run a Sprint Retrospective, re-rank your Constraint Backlog against what the Sprint taught you, install one design change, update the chart, and name the next constraint. The Sprint that skips this stage shipped a project. The Sprint that runs it built infrastructure.
I’m a compulsive worker. I’ve always known that about myself, and I manage it rather than fix it. For most of my career, I was never actually done for the day. “Done” was just what I said when I ran out of energy. The list never cleared. The inbox never reached zero. There was always another thread to pull, another problem to work, another thing that would get worse if I left it overnight.
Then something changed.
I’m looking at the clock. It says 5:30. I do what I always do: I scan the list of everything that was supposed to happen today. The reports that needed to ship. The reviews I was supposed to run. The decisions sitting in my inbox waiting for me to resolve them.
It’s done. All of it.
The list is empty. Nothing slipped to tomorrow.
I close the laptop. I go home. I have dinner with my family.
It happens again the next night. And the night after that.
Count the times I left at 5:30 in the eighteen months before I started deploying these systems against the six months after, and the gap is embarrassing. The work was the same. The industry was the same. I was still moving fast. What changed is that the infrastructure I’d built was doing work in parallel. That work used to wait for me. It was queued behind my availability.
Each Sprint I ran built on the last. The agents knew the company’s conventions because they’d learned them in an earlier Sprint. The tools knew the formats because we’d built the templates. The Knowledge Maps from the first Sprint were sitting inside the system, accelerating the fifth. None of that had to be rebuilt. It just ran.
I could stop because it ran.
That’s what Compound is for.
Compound runs as one working meeting: the Compound session, held in the days after Deliver, where the team that ran the Sprint closes it. Every established operating system has a quarterly review beat; EOS and Scaling Up both run one. Compound is that discipline applied to the Sprint that just shipped: stop, look at what the Sprint produced, identify what the design got wrong, install one specific improvement, and carry it into the next Sprint. The companies that sustain this kind of change built a mechanism to learn from the work and carry the learning forward.
This isn’t the quarterly operating session you’ll meet in the next chapter, and the split matters. The Compound session closes the Sprint and nominates the next one: the governing constraint plus a proposed Human Orchestrator. The quarterly operating session is where those get committed, along with the Sprint Lead, the budget, and the start date.
The session reviews the design: the chart entries, the workflow, the Knowledge Map. The question isn’t who didn’t perform. It’s what the design assumed that turned out to be wrong. Companies that run this session get better every quarter.
Compound runs on two instruments, the Sprint Retrospective and the Constraint Re-rank, plus one discipline that sits between them: the single design change. And the session ends with three deliverables the room can’t leave without.
Compound produces three deliverables. Don’t skip any.
The three Compound deliverables:
- An updated Constraint Backlog, re-ranked against what the Sprint just taught you.
- An updated Hybrid Accountability Chart: the Sprint’s temporary entries revised or proposed permanent, with neighboring rows reviewed for second-order effects.
- A Sprint Outcome Record: the one-sentence outcome written in Deliver, filed here. The constraint, the before-and-after cost, the specific result.
The first two are slices of the living document described in the next chapter, the Hybrid Org Today: the current operational picture of the Co-Intelligent Company. Compound is where those slices get updated. The Sprint Outcome Record files alongside them and becomes this Sprint’s row on the Compounding Scorecard (the blank scorecard sits in the Rhythm chapter; add the row before the session ends, or start the scorecard here if this is Sprint one). It’s how you know, six Sprints from now, what each one produced.
If your Sprint ends and the backlog isn’t re-ranked, the chart hasn’t been updated, and no next constraint is named, the Sprint didn’t finish.
Before the Sprint enters Build, put the Compound session on the calendar. Include the Sprint Lead who runs the session, the Human Orchestrator, and everyone who owned a Sprint accountability. If it’s not scheduled before the Sprint ships, it won’t happen after.
The first instrument is the Sprint Retrospective.
The Sprint Retrospective is the structured review of the Sprint that just shipped. It asks the same three questions every time: what worked, what didn’t work, and what one design change would make the next Sprint better; the third question is a discipline in its own right, not a third instrument. Two more moves finish the retrospective: a reframe that turns question two’s answers into design fixes, and a measurement of what compounded beyond the Sprint outcome.
You run the retrospective with your Human Orchestrator and everyone who owned a Sprint accountability.
How to run the Sprint Retrospective honestly
- Ask: what worked? — So what paid off gets repeated on purpose.
- Ask: what didn’t work? — The full friction list, unfiltered.
- For each failure, ask: what would have to be true for this not to happen again? — The reframe: blame becomes design fix.
- Ask: what one design change would make the next Sprint better? — Feeds the Install One Design Change move.
- Measure what compounded (three compounding questions) — Output versus the infrastructure the next Sprint inherits.
Ask: what worked?
The specific design decisions that paid off. Not “the team did great.” The answers should name mechanisms another Sprint can deliberately repeat:
- The intake form that forced clean inputs, so the sales-to-delivery handoff held for the whole Sprint.
- The daily exception review that caught agent errors within hours instead of at month-end close.
- The decision to give the onboarding agents write access to the checklist, so it stayed current without anyone maintaining it.
Name the mechanism, not the sentiment. “The handoff held because the intake form forced clean inputs” can be repeated on purpose. “Everyone stepped up” can’t.
Ask: what didn’t work?
The honest friction every Sprint produces:
- The handoff that broke: drafts piled up because the review queue lived in an inbox nobody owned.
- The inputs that turned out dirtier than Source claimed: half the records were missing the field the agent matched on.
- The Orchestrator reviews that got skipped: the check lived in a separate Thursday meeting nobody protected.
Write them all down. Filtering happens in the next move, not here.
For each failure, ask: what would have to be true?
The Sprint Lead takes each item in the “didn’t work” column and asks one question: “What would have to be true for this to not happen again?” The question converts blame into design. Watch what it does:
- “Drafts piled up in an unowned inbox” becomes “review would have to run through one queue with a named owner.”
- “Half the records were missing the matching field” becomes “the data pipeline would need a sample-and-verify step before Build starts.”
- “Reviews got skipped” becomes “the review would have to sit inside a meeting that already exists, not on a new calendar slot.”
Each answer points at one of two targets, and the distinction decides where the fix lands. If what would have to be true is a document, a data source, or context the system didn’t have, it’s a knowledge gap: the fix feeds Source, and the Knowledge Map gets updated. If it’s a handoff, a cadence, a permission, or a workflow step, it’s a design gap: the fix lands in the chart or the workflow itself.
Meridian’s retrospective surfaced three items
Meridian’s retrospective surfaced three items in the “didn’t work” column. Dave Kowalski, the senior design engineer, went first: the agent’s historical matching pulled comparable jobs correctly about 85% of the time, but missed complexity. A bracket with twelve bends and tight tolerances isn’t the same as a bracket with four bends and standard tolerances, even if they’re both steel brackets. Elena was correcting about one in eight quotes. The fix: the agent needed fabrication complexity indicators (bend count, tolerance class, surface finish), not just material and dimensions.
Second, Ty admitted he’d forwarded three RFQs to Elena the old way in week one out of habit. The fix: the old email path needed to be killed on day one, not left open as a fallback.
Third, Carlos flagged that every Inconel or titanium job still routed to Elena for manual pricing because the materials database didn’t cover specialty alloys. The fix: the five most common non-standard materials needed to be added before Sprint two.
If your retrospective produces zero “what didn’t work” items, you didn’t run it honestly. Every Sprint has friction. The question is whether your team feels safe enough to name it.
Measure what compounded beyond the Sprint outcome.
The retrospective closes here. Beyond the Sprint outcome you measured in Deliver, Compound asks three more questions. The answers are the compound interest.
What does the organization know now that it didn’t know before this Sprint? Not the outcome; the knowledge. The real exception rate in a process. The actual state of a data source everyone assumed was clean. Which approvals turned out to be theater.
What capability exists now that didn’t exist before? A working agent team is the obvious one. A cleaned and indexed dataset counts. So does an operator who can now run and supervise an agent workflow, because that skill transfers to every Sprint after this one.
What is the next Sprint starting with that this one didn’t have? The inheritance. Trained agents, validated rules, indexed data, a team already fluent in the new way the work moves. The next Sprint starts from that baseline, not from zero.
What compounded at Meridian
Meridian’s answers, in order. Knowledge: Elena’s Customer Notes spreadsheet (147 rows of pricing exceptions on her desktop) contained only 112 validated rules; thirty-five were duplicates or outdated. The Sprint also separated the standard-spec quotes the agent handles cleanly (about 70% of volume) from the complex fabrication and specialty-alloy quotes that still need Elena’s review. Capability: the working quoting agent team — the outcome sentence from Deliver carries the numbers. Baseline: Sprint two starts with three trained agents, 112 validated pricing rules, three years of indexed ERP job data, and a sales team already fluent in the new intake workflow.
If you can’t answer the three questions, the Sprint delivered output but didn’t compound.
Install one design change. Just one.
After every Sprint, you answer one question: what one design change would make the next Sprint better?
The answer is one. One committed design change, installed before the next Sprint begins.
The temptation after a good Sprint is to list every observation the team made and call the list “lessons learned.” That list never lands. It’s too long to install, too unprioritized to argue about, and too vague to enforce. By the time the next Sprint begins, the lessons file is closed and the same mistakes are being made in slightly different configurations. The discipline of one defeats that failure mode.
The change has to be structural: something the next Sprint inherits as part of how the company now operates. Compound is finished when that one change is installed.
How to install one design change
- Survey everything the Sprint surfaced — The full list, with the Human Orchestrator naming what broke inside the workflow.
- Name the single change that will most improve the next Sprint — The priority decision.
- Write the four-field change card (What / Who / How you’ll know / By date) — The specificity test.
- Install the change structurally before the next Sprint begins — Into the chart, the workflow, or the Knowledge Map.
- Verify the change using the ‘how you’ll know’ criterion — Closes the loop.
The change doesn’t have to touch an agent at all:
- A workflow step: a sample-and-verify pass added before any dataset feeds a build.
- A revised prompt: the research agent asks for a missing attribute before it matches.
- A tightened handoff: drafts reach review through one queue instead of three inboxes.
- A cadence fix: the Orchestrator’s review moves inside a meeting that already exists.
- A kill switch: the legacy intake path shuts off on day one instead of lingering as a fallback.
Pick the one standing in the next Sprint’s path. Not the biggest observation, and not the easiest fix.
Verification is the card’s third field doing its job. Before the next Sprint kicks off, run the “how you’ll know” test and confirm the change held. A change that was installed but never verified is a lessons-learned list with better formatting.
One design change per Sprint is small. Eight Sprints of one good design change each is substantial. Skip the discipline and Sprint eight ships the same agent team Sprint one did.
Meridian’s one design change
Meridian’s card came straight out of the retrospective. The change: add fabrication complexity indicators (bend count, tolerance class, weld count, and surface finish) as matching criteria in the Quote Research Agent. Dave Kowalski provides the classification framework from his thirty-one years of fabrication experience; Elena, as Human Orchestrator, configures the criteria in the agent, and Mark Ellison, Meridian’s CEO, signs off. The verification test: re-run the eight quotes from the previous month where Elena corrected the agent’s match, and at least seven of eight produce the correct comparable. Installed before Sprint two kickoff.
Meridian’s card, Sprint one:
| Field | Fill in |
|---|---|
| What the change is | Add fabrication complexity indicators (bend count, tolerance class, weld count, surface finish) as matching criteria in the Quote Research Agent |
| Who installs it | Dave Kowalski provides the classification framework; Elena configures it in the agent |
| How you’ll know it’s working | Re-run the 8 quotes Elena corrected last month — at least 7 of 8 produce the correct comparable job match |
| By date it’s installed | Before Sprint two kickoff |
After the retrospective, write the one design change on a card with four fields. If any field is blank, the change isn’t specific enough.
| Field | Fill in |
|---|---|
| What the change is | |
| Who installs it | |
| How you’ll know it’s working | |
| By date it’s installed |
The second instrument is the Constraint Re-rank.
The Constraint Backlog that existed at the start of the Sprint was built on the information your company had at that moment. The Sprint produced new information: what the data really looks like, which accountabilities have unexpected friction, which constraints turned out to be symptoms of a deeper constraint. The Constraint Re-rank holds the backlog up against that new information and reorders it. Five questions drive it, plus one assignment before the room empties.
How to re-rank the Constraint Backlog on what the Sprint taught you
- Ask: did the Sprint reveal new information about any other constraints? — The new-information check.
- Ask: did any constraints get partially resolved as a side effect? — The spillover check.
- Ask: did any new constraints surface during the Sprint that weren’t on the original list? — The capture check.
- Ask: does one candidate constraint govern the others — would solving it unblock or clarify what the rest of the backlog should be? — The load-bearing test.
- Ask: given what you now know, which constraint should the next Sprint solve? — The decision; the governing constraint becomes the input for the next Signal conversation.
- Nominate the next Sprint’s Human Orchestrator and write it down before leaving the room — The assignment.
Did the Sprint reveal new information about any of the other constraints? Solving one constraint frequently exposes the real cost of another. The workflow you just fixed was hiding a manual re-entry step downstream. The report you automated revealed that its data source updates weekly, not daily. Expect at least one ranking to move.
Did any constraints get partially resolved as a side effect of this Sprint? Some constraints get cheaper without being targeted. Faster output upstream gives a downstream team slack it never had. A dataset cleaned for this Sprint takes a bite out of a reporting constraint two rows down. Adjust the rankings to what actually changed, not just what was targeted.
Did any new constraints surface during the Sprint that weren’t on the original list? The team that lived inside a workflow for the length of the Sprint saw things no Signal session would have surfaced. Capture them now, while the evidence is still in front of you.
Does one candidate constraint govern the others? The load-bearing test, the same one Signal ran. Would solving this candidate unblock or clarify what the rest of the backlog should be? A constraint that unlocks several others gets priority over a constraint that stands alone, regardless of relative cost. Apply eligibility first (eligible means a named owner and a cost estimate — the filter from Signal), then this question. Cost settles ties only when no constraint clearly governs.
The assignment: nominate the next Sprint’s Human Orchestrator. Before the room empties, put a name next to who’ll operate the next workflow. Without one, the next Sprint arrives at the quarterly session with no operator lined up.
Meridian re-ranks the backlog
Meridian walked into the re-rank with the backlog the Sprint had left behind: the quoting bottleneck solved and struck at the top, production scheduling second, the HubSpot-to-JobBOSS sync third, Elena as single point of failure fourth, specialty materials pricing fifth.
The first question moved the most weight. The quoting Sprint exposed that every quote the agent generated still had to be manually entered into JobBOSS, their ERP, when the quote converted to a job. Ty was entering the same data twice: once in HubSpot for the quote, again in JobBOSS for the job record. The manual job-costing candidate from the original Signal session turned out to be downstream of the same gap: quotes convert to jobs through manual re-entry, and costing inherits whatever the re-entry gets wrong. The sync jumped from third to first.
Production scheduling didn’t get less important, but the Sprint partially addressed it: Carlos now had pipeline visibility from faster quotes, which enabled proactive scheduling instead of reactive. It moved to fourth. Elena as single point of failure slid to fifth, because the quoting Sprint had already distributed the biggest piece of her undocumented context.
One constraint entered new. Meridian discovered that 40% of their quotes went to three customers who negotiated the same terms every time. Customer pricing standardization, pre-negotiated tiers for those three accounts, hadn’t been on the backlog at all. It entered at rank two. Specialty materials pricing moved up to third: the retrospective had already flagged every Inconel and titanium job still routing to Elena for manual pricing.
Then the governing test. The sync wasn’t just expensive on its own; it was the bottleneck that kept the quoting Sprint from fully propagating into operations. Every subsequent Sprint that touched a downstream process would inherit that gap. It had a named owner and a cost estimate, it governed the rest, and cost never entered the decision. Meridian’s answer to the fifth question: the HubSpot-to-JobBOSS data sync. Mark proposed Elena as Human Orchestrator for the sync Sprint; the commitment lands at the next quarterly operating session.
If you’re picking the same constraint for Sprint two that you picked for Sprint one, the Sprint didn’t deliver. Go back to the operational log and figure out what’s still broken before you run the same play again.
Pull the Constraint Backlog. Re-rank it with the five questions. Name the governing constraint. Nominate a Human Orchestrator for the next Sprint. Write both down before you leave the room.
Update the three Compound deliverables before the room empties.
The three deliverables get updated at the end of every Compound session, before anyone leaves. They’re the institutional memory that makes compounding possible, and the updates take fifteen minutes. Here’s how the session closed at Meridian.
The Hybrid Accountability Chart. Any entry that was temporary for the Sprint gets proposed permanent if the workflow is staying; any entry that didn’t work gets revised. The same nominate-then-commit split that governs the constraint governs the chart: the quarterly operating session makes the row permanent once the outcome has held at target for the quarter. Meridian proposed the quoting row permanent: three agents (Quote Research, Quote Pricing, Quote Assembly), with Elena confirmed as Human Orchestrator at the AI-Assisted level. They reviewed neighboring rows for second-order effects, and Carlos’s production scheduling entry got a note: faster quoting was creating more jobs, and scheduling hadn’t kept pace.
The Constraint Backlog. Re-ranked per the Constraint Re-rank: HubSpot-to-JobBOSS data sync at the top, customer pricing standardization second, specialty materials pricing third.
The Sprint Outcome Record. The one-sentence outcome written in Deliver, filed: “Three-agent quoting pipeline removed Elena as the bottleneck on standard work, cut turnaround from 3.8 days to 4.2 hours, and produced $47K in new revenue in month one.” Six Sprints from now, that sentence is how Meridian knows what this one produced.
Without those fifteen minutes, you run the same discovery work from scratch every quarter.
At the end of the Compound session, update all three deliverables before anyone leaves the room: chart row proposed permanent, backlog re-ranked, Sprint Outcome Record filed. Fifteen minutes. No exceptions.
Infrastructure compounds. Each Sprint inherits the last.
Sprint one’s Source stage produced a Knowledge Map for the client delivery function: three weeks of mapping what the function actually knows, where the data lives, what’s undocumented, what depends on which person’s head. That Knowledge Map doesn’t disappear when the Sprint ends. It lives inside the company. Sprint six in the same function inherits it. The Source stage that took three weeks the first time takes three days the sixth time, because the map already exists and the work is mostly updating the edges.
The same is true of every artifact in the Sequence. The Hybrid Accountability Chart has one row after Sprint one and a dozen after Sprint twelve; each new Sprint inherits the chart as context for the design decisions it has to make. The build-spec conventions the company validated in Sprint one carry into Sprint two without being re-argued. Training material from Sprint three’s Deliver stage becomes the onboarding for Sprint seven. Real artifacts, sitting inside the company, accelerating the next Sprint.
A company six Sprints in works differently. The constraint they’re working on now is sharper, because three Sprints’ worth of Sprint Retrospectives taught them which constraints actually change a number. The Hybrid Accountability Chart entry they draft in Design takes an afternoon, because they’ve drafted six of them. That’s the infrastructure compounding. It’s what the work feels like in the seventh Sprint, compared to the first.
Forty-five minutes that saved weeks
I’m running a Source session with a client group. Multiple people on a video call. The goal is to map where their information lives — what data they have, who owns it, how often it’s updated, what an agent can actually access.
I ask the first question. Someone answers. Someone else adds a correction. A third person remembers something they’d forgotten to include. People interrupt each other, and problems get added to the pile mid-session.
But the whole time, an AI skill (a small, purpose-built agent listening to the call and assembling the document as the conversation happens) is doing the writing. Attendees. Problem inventory. Knowledge inventory. Current tools. Connected data sources. Key themes. All of it accumulating sentence by sentence, without anyone in the room writing a word.
Forty-five minutes later, we’re done. I pull up the document. It has everything — the complete Source picture for this organization, structured and ready to use. I send it to them. The response from the person who’d been expecting a conversation: “This is great. I spent zero time creating it.”
That document is still inside their company. The next Sprint they run, the Source work starts from that map, not from zero. That’s the 45-minute session doing compounding work across every Sprint that follows it.
The project coordinator’s knowledge base from the Design chapter is still working too — where the client files lived, which contacts needed extra lead time, the unwritten rules for each account, all of it documented before she left. We built the agents on top of it. The next Sprint runs on it. The knowledge we mapped became infrastructure that each Sprint added to. The numbers in the next chapter didn’t come from a single Sprint. They came from the stack of infrastructure each Sprint left behind.
Compound is the mechanism behind the slope.
Every vendor uses “scale” to sell more of the same thing. It’s a quantity claim with no architecture behind it.
Compound is specific. The friction per Sprint decreases, because each Sprint inherits the last one’s maps, conventions, and training material. The return per Sprint increases, because the constraints get more strategic as the easy ones come off the backlog and leadership runs Design with more precision each pass.
Compound is the mechanism behind the slope Chapter 1 named: revenue grows while headcount grows slower. The Rhythm, the next chapter, is what bends it. The longer the company runs the Rhythm, the wider that gap gets.
The Canvas closes; the next Sprint opens.
One thing remains before the session ends. The Sprint Planning Canvas has carried this Sprint since Signal wrote the constraint at the top of it. The Compound row asks the Canvas’s last question: what did you learn, and what changes for the next Sprint? Fill it with the Sprint Outcome Record and the named next constraint. That completes this Sprint’s Canvas, first row to last, and the re-ranked Constraint Backlog seeds the next one.
The chapter that follows is the Rhythm: what happens when Compound runs quarterly and becomes how the company operates. It’s also where the headcount math from the opening of this book gets answered.
Reflection Questions
- Run the Sprint Retrospective questions on your most recent AI initiative: what specifically worked, what specifically didn’t, and — for each item in the “didn’t work” column — what would have to be true for it to not happen again? Does the reframe point to a design fix or a knowledge gap?
- Answer the three compounding questions: what does your organization know now that it didn’t know before? What capability exists now that didn’t exist before? What will the next Sprint start with that this one didn’t have? If you can’t answer all three, the Sprint produced output but didn’t compound.
- What is your one design change for the next Sprint — not a list, one? Write it on a card with four fields: what the change is, who installs it, how you’ll know it’s working, and the date it’s installed by. If any field is blank, the change isn’t specific enough.
- Re-rank your Constraint Backlog using the five Constraint Re-rank questions. Did the Sprint reveal new information that moves any constraint up or down? Is there a constraint that surfaced during the Sprint that wasn’t on the original list? Does one candidate govern the others — would solving it first unblock or clarify what follows?