You have a team. They're working hard. They're not shipping as fast as they should.

The diagnosis matters more than the prescription. Most teams treat "ship faster" as a universal instruction: work harder, work smarter, add process, remove process. It rarely works because it's aimed at the wrong target.

This post is an audit framework. The goal is to identify specifically where your system is slow, which is different from where the frustration is loudest. Then intervene specifically, not generally.

Work through it in order. The early questions tend to reveal the higher-leverage problems.

Step 1: Identify Your Real Constraint

Review the five features again. For each one, identify the critical path — the sequence of steps that determined the actual elapsed time.

What was the step that everything else waited for? Where did the queue pile up?

Common constraints and how to recognize them:

Product decision latency: Features pile up waiting for product calls that haven't been made. The queue is in the "ready" or "design" state, not "in development." Engineering velocity looks fine; nothing is moving to "in development."

Design review: Design is a small team and work backs up in front of them consistently. The design team is not behind because they're slow — they're behind because there's more demand than their capacity.

A specific person: A single engineer's name appears on every critical path. Not because they're the only one who can do the work, but because of implicit ownership, unclear delegation, or a release process that routes through them.

QA or testing: Features pass engineering and immediately enter a long QA queue. Engineering velocity is good; shipping velocity is not.

CI or environment availability: Work finishes but can't be tested because environments are occupied or CI is backed up. The mechanical infrastructure is the constraint.

Pick the one that appears most consistently across the five features. That's your constraint.

Step 2: Assess Decision Rights Clarity

For each significant decision that had to be made in the last five features, ask:

  • Who made the call?
  • How long did it take to make?
  • Was the right person making it?
  • Was the timeline appropriate for the reversibility of the decision?

Look for patterns: are decisions consistently delayed because decision rights aren't clear? Are too many people being consulted? Is consensus being required for decisions that don't need it?

The output of this step is usually a list of decision types and who should own them, with explicit time bounds for each.

Step 3: Identify the Loops

Systems have feedback loops. Some amplify problems; some contain them.

Reinforcing loops that slow you down:

  • More work in flight → longer queues → more context switching → slower decisions → longer queues → ...
  • Rework → schedule pressure → scope cuts → quality problems → more rework → ...

Balancing loops that constrain the damage:

  • Features shipping badly → user complaints → scope discipline increases → fewer features, more stability → ...
  • Problems in production → investment in testing and observability → fewer problems → ...

The question: are the reinforcing loops you're running stronger than the balancing ones? Most teams that ship slowly have reinforcing loops that aren't being interrupted.

Identify one or two reinforcing loops that are active in your system. What's the intervention that breaks the loop? Usually it involves reducing WIP, stabilizing scope before handoff, or protecting review and decision time.