Approval Loops: diagnosing the Architecture that makes finished work feel provisional

Approval Loops are the second most frequently occurring Frustration Architecture in our deployment data, and the one teams find hardest to name while they are inside one. The reason is phenomenological: from inside an Approval Loop, each individual review cycle feels legitimate. Legal has a point. Marketing has a point. The regional VP has a point. It is only when you count the rounds — and notice that the loop has not converged after five of them — that the structural pattern becomes visible.

That invisibility is what makes Approval Loops so corrosive. The team cannot point to a single person or forum that is the problem. Each reviewer is doing their job. The problem is the structure that gives multiple reviewers sequential access to the work without a converging rule — without a defined point at which one person's judgement closes the loop.

The precise definition

An Approval Loop is a structural pattern in which a piece of work circulates through multiple approvers in a sequence that does not converge: each approver introduces feedback that requires modification, and modification re-opens the work to earlier approvers, who may then introduce further feedback. The loop closes only when one approver gives up, the deadline forces a release, or someone with sufficient authority imposes a definition of done.

Three variables define the loop: the approver set (who is in the sequence), the convergence rule (what constitutes done and who can declare it), and the re-open trigger (what causes the loop to restart). A process with a large approver set but a clear convergence rule and no re-open trigger is not an Approval Loop — it is a sequential review process that ends.

Approval Loop vs legitimate quality review

A sequential review process — legal reviews, then compliance signs off, then finance approves — is not an Approval Loop if each reviewer has a bounded scope (legal reviews only the legal exposure, not the product design), a convergence rule (legal sign-off is final on legal matters), and no re-open trigger (a legal sign-off cannot be undone by a product design objection).

An Approval Loop emerges when scope boundaries between reviewers are absent or ignored, when any reviewer can reopen the work on any grounds, or when the definition of done is implicit and contested. The difference is not the number of reviewers — it is whether the process can converge.

Why Cross-Functional Listen data is diagnostic

Approval Loop clusters in a Listen share a distinctive linguistic pattern: a count of rounds ('fifth time through,' 'been back three times'), a multiplicity of names ('legal then marketing then the regional lead'), and a failure of convergence ('still not final,' 'no one will call it done'). Statements that contain all three are high-confidence Approval Loop classifications. A single round of feedback, even if painful, is not an Approval Loop — it is a review event.

Three structural types of Approval Loop

Scope-overlap loop

Multiple approvers have overlapping authority over the same dimension of the work. Legal and marketing both believe they own brand standards; product and engineering both believe they own the feature scope. When both reviewers touch the same dimension, each revision to satisfy one reopens the issue for the other. The loop is maintained by the scope overlap, not by individual bad behaviour.

Three Doors response: Remove by assigning each dimension of the work to a single owner with final authority over that dimension. Defer With Clarity by freezing scope at the start of the review cycle and committing that scope changes reset the clock, not the round count. Accept by naming the overlap explicitly and creating a standing arbitration role.

Escalation loop

The approver set has no senior member with authority to close the loop, so disagreements between reviewers escalate upward to a leader who is not in the formal approval sequence — and the leader's intervention introduces new feedback that restarts the sequence. The loop is maintained by the absence of a designated convergence authority inside the review set.

Three Doors response: Remove by designating a DRI inside the approval set with explicit authority to close. Defer With Clarity by setting a round limit after which the loop owner makes a unilateral call. Accept by explicitly assigning the escalation to the senior leader and acknowledging the time cost.

Standard-drift loop

The standards the work is reviewed against are not fixed at the start of the review cycle. Each round of review introduces new or revised standards that the prior round did not satisfy — not because the standards changed externally, but because reviewers applied different standards in different rounds. The team experiences this as goalpost-moving; reviewers experience it as improving the work.

Three Doors response: Remove by publishing fixed review criteria before the cycle begins and restricting feedback to criteria violations. Defer With Clarity by accepting the current version as a timestamped release and running a separate cycle with fixed criteria for the next version. Accept by declaring the work permanently iterative and removing the fiction of a final approval.

Diagnosing from Cross-Functional Listen data

The key distinction between an Approval Loop and a Decision Bottleneck is motion versus stagnation. A Decision Bottleneck stalls at one point — the work is waiting for a decision that has not been made. An Approval Loop keeps moving — the work is in review, reviews are happening, but the work keeps cycling back. Teams in a Decision Bottleneck are idle; teams in an Approval Loop are busy with revisions that do not converge.

In Listen data, this produces a different tonal signature. Decision Bottleneck statements express frustration with waiting. Approval Loop statements express frustration with effort that feels wasted — 'we keep redoing this,' 'every time we think we're done,' 'I have no idea what good looks like to them.' The emotion is not impatience; it is futility.

Applying Three Doors to an Approval Loop

The Three Doors discipline requires a specific commitment for each cluster. For an Approval Loop, the minimum viable decision is: identify the loop type, name the door, and name the structural change that prevents the loop from reforming.

1. Remove: 'We are assigning [name/role] as the single accountable owner of this review. Their decision is final from [date]. Review criteria are published at [location] and locked for this cycle.'
2. Defer With Clarity: 'We are shipping the current version as a time-bound release by [date]. A new review cycle with fixed criteria will begin on [date].'
3. Accept: 'This work is permanently iterative. There is no final approval. We will version and date releases and remove the expectation of a converging review.'

The common failure mode is an Accept response delivered as if it were a Remove: 'We'll get this sorted out and aim for a clean approval next time.' That is not a structural commitment; it is a hope. The team has heard versions of it at the end of every prior cycle.