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, 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. Every item is finished. 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.
If I counted the times I left at 5:30 in the eighteen months before I started deploying these systems versus the six months after, 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 (software that hold a goal and run a sequence of steps on their own — not chatbots you prompt one question at a time; covered in depth in the Build chapter) 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 Source 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. The agents in that story are AI systems that hold a goal, run a sequence of steps toward it, and adjust based on their own outputs. They’re not chatbots that answer one question at a time. Every successful business runs on some kind of quarterly rhythm: EOS calls it the quarterly operating session, Scaling Up calls it quarterly planning, 4DX has its own cadence. The Compound stage is the AI operating layer running the same beat: stop, look at what the last 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 that learning forward. The companies that revert didn’t.
The retrospective looks at the design, not the people. The chart entries, the workflow, the Source map — those get reviewed. The question isn’t who didn’t perform. It’s what the design assumed that turned out to be wrong. Companies that do this get better every quarter. Companies that skip it repeat the same design errors in slightly different configurations.
Compound produces three deliverables. Don’t skip any.
An updated Constraint Backlog — the running, prioritized list of validated constraints your organization is working through. Signal generated the constraint that drove this Sprint; the Sprint generated new information about the rest of the backlog. Compound is where you re-rank the backlog against what you now know.
An updated Hybrid Accountability Chart. The chart gained entries when Design produced accountabilities for this Sprint. By the end of Deliver those entries were real — named agent teams, named human supervisors, positions on the AI-assisted-to-automated spectrum, and documented outcomes against the constraint. In Compound, you make those entries permanent and review any neighboring rows for second-order effects from the Sprint that just completed. (If you run EOS, the Hybrid Accountability Chart extends your Accountability Chart — it adds agent roles and their human supervisors alongside your existing seats.)
A Sprint Outcome Record: one sentence that captures what changed. The constraint, the before-and-after cost, the specific result. “Standard quote turnaround reduced from 3.8 days to 4.2 hours. Elena’s quoting time from 15 hrs/wk to 5. Throughput doubled.” That record is filed in the Hybrid Org Today and becomes the first row of the Compounding Scorecard (the blank scorecard template sits in the Rhythm chapter; add this Sprint’s row to it before the session ends). It is how you know, six Sprints from now, what each one produced.
These three deliverables slot into the living document described in the next chapter — the Hybrid Org Today, the current operational picture of the Co-Intelligent Company. The Constraint Backlog and the Hybrid Accountability Chart are both slices of it. Compound is where those slices get updated.
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 (the operator who runs the redesigned workflow and supervises its agents day-to-day — detailed in the Designing the System chapter), and every supervisor who owned a Sprint accountability. If it’s not scheduled before the Sprint ships, it won’t happen after.
Run the Sprint Retrospective honestly
How to run the Sprint Retrospective honestly
- Ask: what worked? — Names the specific design decisions that paid off — mechanism, not sentiment — so they can be intentionally repeated.
- Ask: what didn’t work? — Surfaces broken handoffs, dirty inputs, and wrong cadences — the honest friction every Sprint produces.
- For each failure, ask: what would have to be true for this not to happen again? — Reframes blame into design fix — converts observations into actionable constraints on the next Sprint’s design.
- Ask: what one design change would make the next Sprint better? — Forces prioritization before the session ends; feeds directly into the Install One Design Change step.
- Measure what compounded (three compounding questions) — Distinguishes output (Sprint delivered something) from compound interest (the Sprint built infrastructure the next Sprint inherits).
The Sprint Retrospective is one of two instruments in the Compound stage. It’s the structured review of the Sprint that just shipped, and it asks the same three questions every time.
Question one: what worked? The specific design decisions that paid off. Not “the team did great.” The workflow that cut quoting time from four hours to twenty minutes. The ops manager who served as Human Orchestrator because she knew every pricing exception. The agent’s access to three years of historical data that made the estimates accurate. Name the mechanism, not the sentiment.
Question two: what didn’t work? The handoffs that broke, the inputs that turned out dirtier than Source claimed, the supervisor reviews that got skipped because the cadence was wrong. For each item, the facilitator asks one question: “What would have to be true for this to not happen again?”
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 is not 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.
Question three: what one design change would make the next Sprint better? This gets its own section below, because the discipline behind it is load-bearing.
You run the retrospective with your Human Orchestrator and any supervisors who owned Sprint accountabilities. The room has to be safe enough for honest answers.
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
Beyond the Sprint outcome you measured in Deliver, Compound asks three additional questions. The answers are the compound interest.
What does the organization know now that it didn’t know before this Sprint? Meridian learned that 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 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.
What capability exists now that didn’t exist before? A working quoting agent team that cut standard quote turnaround from 3.8 days to 4.2 hours. Elena’s quoting time dropped from fifteen hours a week to five. Throughput doubled. That capability doesn’t disappear when the Sprint ends. It’s infrastructure — and it produced $47K in new revenue in the first month.
What is the next Sprint starting with that the first Sprint didn’t have? Three trained agents, 112 validated pricing rules, three years of indexed ERP job data (organized and tagged so the agents can search and retrieve it quickly), and a sales team that’s been using the new intake workflow for six weeks. Sprint two starts from that baseline, not from zero.
If you can’t answer these three questions, the Sprint delivered output but didn’t compound.
Install one design change. Just one.
How to install one design change
- Survey everything the Sprint surfaced — the team scans all retrospective items — Source gaps, wrong cadences, broken handoffs, dirty inputs — before picking, with the Human Orchestrator surfacing what broke inside the workflow.
- Name the single change that will most improve the next Sprint — The discipline of one defeats the ‘lessons learned list’ failure mode; forces a real priority decision.
- Write the four-field change card (What / Who / How you’ll know / By date) — Makes the change specific and testable; any blank field signals the change is too vague to install.
- Install the change structurally before the next Sprint begins — An insight that doesn’t change the design isn’t worth recording — the change must land in the chart, workflow, or Source map.
- Verify the change using the ‘how you’ll know’ criterion — Closes the loop — confirms the change is working before Sprint two kicks off, not assumed.
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.
Compound is finished when that one design change is installed. The change has to be structural: a chart entry revised, a workflow step added, a guardrail tightened, a Source map updated. It is something the next Sprint inherits as part of how the company now operates. An insight that doesn’t change the design isn’t worth recording.
The discipline of one design change defeats that failure mode. You look across everything the Sprint surfaced: the Source phase that ran too thin, the supervisor cadence that was wrong, the handoff between the agent team and the human reviewer that broke once, the input format that turned out to need cleaning nobody scoped. Much of that gets flagged by the Human Orchestrator, who lived inside the workflow. Then you name the single change that will most improve the next Sprint.
Meridian’s one design 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. The agent uses it when selecting historical matches. You know it’s working when you 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.
Your change doesn’t have to touch an agent at all. It might be a workflow step, a revised prompt, or a tightened handoff — whatever the retrospective showed will most improve the next Sprint.
One design change per Sprint is small. Eight Sprints of one good design change each is substantial. Skip the discipline and you get the same agent team you always had.
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 |
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; Mark 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 |
Re-rank the Constraint Backlog on what the Sprint taught you
How to re-rank the Constraint Backlog on what the Sprint taught you
- Ask: did the Sprint reveal new information about any other constraints? — Solving one constraint exposes the real cost of another — the backlog order the company entered the Sprint with may no longer be correct.
- Ask: did any constraints get partially resolved as a side effect? — Recognizes spillover value and adjusts rankings to reflect what actually changed, not just what was targeted.
- Ask: did any new constraints surface during the Sprint that weren’t on the original list? — Prevents new constraints from falling through the cracks by capturing them at the moment of highest clarity.
- 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. A constraint that unlocks several others gets priority over a constraint that stands alone, regardless of relative cost. Apply eligibility first, then this question; use cost only as a tiebreak when no constraint clearly governs.
- Ask: given what you now know, which constraint should the next Sprint solve? — Converts the re-ranked backlog into a decision — the governing constraint becomes the input for the next Signal conversation.
- Name the next Sprint’s Human Orchestrator and write it down before leaving the room — Identifies who’ll operate the next workflow before the Compound session ends; without a named Orchestrator the next Sprint has no operator lined up.
The second instrument in Compound 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 — about what the data really looks like, which accountabilities have unexpected friction, which constraints turned out to be symptoms of a deeper constraint. You take the backlog into that new information and reorder it.
Five questions drive the re-rank:
Did the Sprint reveal new information about any of the other constraints? Solving one constraint frequently exposes the real cost of another. Meridian’s 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 HubSpot-to-JobBOSS data sync, previously ranked third on the backlog, jumped to first.
Did any constraints get partially resolved as a side effect of this Sprint? Production scheduling had been ranked second. It didn’t get less important, but the quoting Sprint partially addressed it — Carlos now had pipeline visibility from faster quotes that enabled proactive scheduling instead of reactive. It moved to fourth.
Did any new constraints surface during the Sprint that weren’t on the original list? 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.
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. The HubSpot-to-JobBOSS 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. That’s the governing constraint. When one candidate clearly governs, it wins regardless of whether another item looks cheaper to solve.
Given what you now know, which constraint should the next Sprint solve? The governing constraint — the one that passes the eligibility filter and the load-bearing test — becomes the input for the next Signal conversation. Cost settles tiebreakers when no single constraint clearly governs. Meridian’s answer: the HubSpot-to-JobBOSS data sync. Mark assigned Elena as Human Orchestrator. Sprint two kicks off at the next quarterly planning 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 using the five questions. Name the governing constraint. Assign a Human Orchestrator for the next Sprint. Write both down before you leave the room.
Update the three living documents before the room empties
Three artifacts get updated at the end of every Compound session. Don’t skip this. The documents are the institutional memory that makes compounding possible.
The Hybrid Accountability Chart — any entry that was temporary for the Sprint becomes permanent if the workflow is staying. Any entry that didn’t work gets revised. Meridian made the quoting row permanent: three agents (Quote Research, Quote Pricing, Quote Assembly), with Elena confirmed as Human Supervisor at the AI-Assisted level. They also reviewed neighboring rows for second-order effects. Carlos’s production scheduling entry got a note that 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 moved to the top. Customer pricing standardization entered at second. Specialty materials pricing moved up to third.
The Sprint Outcome Record — the one-sentence outcome from Deliver, filed for future reference. “Standard quote turnaround reduced from 3.8 days to 4.2 hours. Elena’s quoting time from 15 hrs/wk to 5. Throughput doubled. $47K new revenue in month one.”
These updates take fifteen minutes. Without them, you run the same discovery phase from scratch every quarter.
At the end of the Compound session, update all three living documents before anyone leaves the room. Chart row made permanent, backlog re-ranked, Sprint outcome recorded in one sentence. Fifteen minutes. No exceptions.
Infrastructure compounds. Each Sprint inherits the last.
Sprint one’s Source phase 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 phase 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 Writer learned the company’s conventions in Sprint one and applies them automatically in Sprint two. Training material from Sprint three’s Deliver phase becomes the onboarding for Sprint seven. Real artifacts, sitting inside the company, accelerating the next Sprint.
A company six Sprints in finds the Source phase of their seventh Sprint taking days instead of weeks. The constraint they’re working on now is sharper, because three Sprints’ worth of Sprint Retrospectives taught them what kinds of constraints actually move the needle. 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, the skill is building the document. Attendees. Problem inventory. Knowledge inventory. Current tools. Connected data sources. Key themes. All of it accumulating sentence by sentence as the conversation happens, 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 phase starts from that map — not from zero. Three weeks of discovery that used to happen at the start of every engagement now happens once, and then gets updated at the edges. That’s the 45-minute session doing compounding work across every Sprint that follows it.
The coordinator’s knowledge base I described in the Design chapter is still working too. We extracted it before she left and 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, thirteen people to eight, double-digit growth on billings and profitability, didn’t come from a single Sprint. They came from the stack of infrastructure each Sprint left behind.
Compound bends the headcount 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. Source runs on maps that already exist, Build applies conventions the company already validated, Deliver inherits training material from previous Sprints. 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 what bends the slope Chapter 1 named — revenue grows while headcount grows slower. The longer the company runs the Rhythm, the wider that gap gets.
One Sprint, one Compound stage
One Sprint produces one Compound stage. That’s the unit. You run the Sequence on one validated constraint, you ship the work, and you close it in a single Compound session that leaves the room with:
- the Sprint Retrospective run and compounding measured,
- the Constraint Re-rank done and the Constraint Backlog re-ranked,
- one design change installed,
- the chart updated and the living documents current,
- the next constraint named and the next Human Orchestrator assigned.
That is a complete pass through the system.
The chapter that follows is the Rhythm — what happens when this stage runs quarterly and becomes how the company operates. One Compound stage proves the mechanism works on one Sprint. The Rhythm is what turns the mechanism into a business outcome. It’s also where the headcount math from the opening of this book gets answered, in the language of a company that’s been running the Sequence long enough that the answer is no longer hypothetical.
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?