The four loops every org runs

Ask an engineering leader what's slowing their org down and you'll get an answer about delivery almost every time.

The build is too slow. Code review takes three days. We need better CI. Somebody wants to talk about story points.

Delivery is real.

It's also the loop everyone can see, which is exactly why it gets blamed for problems it didn't cause.

An engineering organisation doesn't run one loop. It runs four, and they don't share a clock.

The delivery loop is the one with a name everyone already knows. Decide, build, ship.

Somebody commits to building a thing, a team turns it into working software, it goes live. This loop has got dramatically faster in the last few years, because AI-assisted coding took time out of implementation that used to be unavoidable, and most orgs measure it obsessively: cycle time, deploy frequency, PR turnaround.

Its natural cadence is days. Sometimes hours.

The learning loop asks a different question.

Did the thing that shipped actually do what it was supposed to, and did anybody update their beliefs when the answer came back.

It should run on its own cadence, tied to when a feature has had enough exposure to produce a real signal rather than to a sprint boundary. In most orgs it doesn't run on any cadence at all.

It runs on whether somebody remembers to check. Mostly nobody does, because everyone's attention already moved to the next ticket in the delivery loop.

The people loop is judgment moving in and out of the org. Hiring, promoting, developing, losing your best senior engineer to a competitor with a nicer logo.

It runs in quarters and years, not sprints.

You cannot make it run faster by wanting to. A junior becomes a senior on a schedule set by experience rather than by managerial urgency.

The strategy loop is the slowest and the most avoided.

Is the thing we're building even the right thing to be building. Not "are we building it well," which is a delivery question. "Should we be building it at all," which is a leadership question most orgs answer once, at the start of a quarter or a year, and never revisit until a bad number forces it on them.

Re-litigating strategy every sprint is its own dysfunction, so this isn't an argument for that.

But an org that hasn't asked the question in twelve months is running on a plan nobody currently believes in. They've just stopped saying so out loud.

Four loops. Four different clocks.

Your org's actual throughput, meaning the rate at which real value reaches customers and compounds, is set by the slowest one rather than the fastest. A factory line doesn't move at the speed of its fastest station. It moves at the speed of the one everyone's waiting on.

Pour more speed into delivery while the learning loop stays broken and you haven't got faster. You've got better at generating bets nobody ever confirms.

You can only see one of these loops directly

Delivery has an artefact.

A pull request merges, a deploy goes out, and you can point at a dashboard and say: there, that happened.

The other three leave no trace like that, which is why they're so easy to ignore and so easy to get wrong.

You infer the learning loop from whether decisions actually change.

Pull the last six product bets your org made. Ask, honestly, how many were followed by somebody stating what they now believed was true or false as a result.

If most features ship and are never mentioned again, not because they succeeded quietly but because nobody checked, that's your answer.

You infer the people loop from your bus factor and your regret attrition. Not your headcount chart.

How many decisions of real consequence route through fewer than two people. How many of the last few departures were people you'd have fought to keep.

A people loop leaking judgment faster than it grows it does eventually show up in delivery. By then it's a lagging indicator rather than a diagnostic one.

The strategy loop gets a blunter test.

Can anybody in the room state, without checking a slide, why the current top priority is still the right one given what's changed since it was set.

Silence, or an answer that's really a restatement of momentum, means the loop hasn't turned in a while.

Finding the actual constraint

The diagnostic is simple to state and uncomfortable to run.

Pick a quarter. Ask which of the four loops, if it ran twice as fast, would change the org's output most.

Not the loudest one. Not the one with the most dashboards. Not the one your engineers complain about at standup. The one actually gating the others.

The honest answer is rarely delivery, precisely because delivery is the loop everyone's already watching. A loop under constant scrutiny tends to get faster over time just from the attention, that's what most of the cycle-time work of the last few years produced. The loops nobody's watching are still running on the cadence they had five years ago, and one of those, not delivery, is very likely your actual constraint this quarter.

Speeding up a loop that isn't the constraint doesn't help. It makes the real bottleneck's backlog grow faster. An org with a slow learning loop that ships twice as fast just accumulates twice as many unconfirmed bets. An org with a stale strategy that ships twice as fast just gets to the wrong destination in half the time.