A team hits every quarterly value target and still can't move faster next quarter. It never invested in the capacity to sense or act, only in shipping the next increment of value. Any board that's sat through the "why does every launch take longer than the last one" conversation has watched this happen from the other side of the table.

Tying back to the ladder and the queue

A value loop is what runs through a rung, the actual work moving up the ladder we mapped in Part 1. A capacity loop is an investment that changes the rung itself, shrinking its queue or speeding its check, for every future piece of work that passes through it, not just the one sitting in front of you right now.

Two loop types, both vocabularies

A value loop asks: does what we're building, at the level we're building it, actually produce value? In business terms, this is anything that shows up on the P&L this quarter, a feature, a campaign, a price change. It's the loop Part 3 already told you to check before you enter it.

A capacity loop asks something different: can we build or improve the systems — tooling, observability, evals, agents, pipelines — that let us get and act on information faster next time? In business terms, that's the CRM overhaul. The ops hire. The onboarding rebuild, the BI dashboard, the training program — the classic "infrastructure spend" every board argues about against "growth spend." Different budget line. Same basic bet.

This split already has real names

Worth citing instead of coining a new one. James March's 1991 paper "Exploration and Exploitation in Organizational Learning" is the foundational academic version. Exploitation — refining and running what already works — is our value loop. Exploration — building new capability for uncertain future payoff — is our capacity loop. It's a simulation model, not a field study, but the mechanism it identifies is worth taking seriously: exploitation's faster, more certain returns can starve exploration out, and how badly that happens depends on things like how fast people turn over and how quickly new hires get socialized into "the way we do things." Tushman and O'Reilly's later work on "organizational ambidexterity" is the practical follow-on — how to structurally run both loops at once instead of letting one crowd out the other.

On the practitioner side, Gartner's Run-Grow-Transform budget taxonomy, and the Run-the-Business-versus-Change-the-Business framing popularized in IT circles, name the identical fork again, this time as the actual line item a CFO or a board argues over. Three fields, one recurring argument.

The four-stage information cycle

Worth telling as its own sub-model, twice over. It's a cousin of John Boyd's OODA loop, Observe, Orient, Decide, Act, though narrower: it's aimed specifically at the moment a team notices its current information-processing system can't keep up and has to build a new one, a step OODA never calls out on its own.

First, getting information — sensing, instrumentation, observability. In business terms: market research, win-loss calls, support tickets, churn interviews. Second, processing that information with the system you already have: an engineer reading logs, or an ops team reading a dashboard someone already built. Third, using what you've processed to actually decide and act — shipping a fix, making a pricing call. And fourth, building a new information-processing system once the current one can't keep up. A new eval suite. A new CRM. Because the old one can't answer the question fast enough anymore.

Stages one through three are "run the loop you have." Stage four is the capacity loop from above, just not labeled as one, and it's the stage teams and companies alike most often skip, or bolt on far too late.

Why treating the two as one breaks roadmaps and budgets

A capacity investment — a new eval suite, a faster deploy pipeline, a new CRM, a new ops hire — doesn't look like "value" on a quarterly scorecard or a board deck. So it gets starved. Until the value loop itself grinds to a halt for lack of the capacity to run it fast — on the engineering side or the revenue side, doesn't much matter which.

The diagnostic question, for any initiative, technical or commercial: is this trying to prove something's worth doing, or trying to make us faster at proving things are worth doing? Most initiatives, features and campaigns alike, are secretly one or the other. Rarely both.

That sets up the harder question, the one every board eventually asks out loud: when is it actually worth pausing value delivery to go build capacity, and how do you tell that apart from procrastination? That's Part 5.

Value Loops vs. Capacity Loops