Signs your delivery problem is not an engineering problem

When a team stops shipping predictably, the first explanation offered is almost always capacity. We need more engineers. We need better engineers. The current team is not fast enough.

Occasionally that is true. Far more often, engineering throughput is fine and the constraint sits somewhere else in the system — before work reaches engineers, or after it leaves them. Adding capacity to a system whose bottleneck is elsewhere does not increase output. It increases work in progress, which usually makes things worse.

The four places the constraint actually lives

Intake — how work enters the backlog

If anyone can add work to the backlog and priority is decided informally, engineers spend their judgement on triage rather than building. The symptom is a team that is visibly busy with low observable output.

Diagnostic: ask three engineers what the most important thing to ship this month is. If you get three different answers, intake is your problem.

Specification — whether work is defined well enough to build

When a ticket says "improve onboarding" and nothing more, someone has to decide what that means. Usually an engineer, mid-sprint, without the context to decide well. The result gets built, reviewed, rejected and rebuilt.

Diagnostic: take ten recently completed tickets. How many had explicit acceptance criteria written before work started? If it is under half, specification is your constraint, and it will look exactly like an engineering speed problem from the outside.

Flow — where work sits waiting

Most work items spend the majority of their lifespan waiting rather than being worked on. Waiting for review, for a decision, for a dependency, for a deploy window. Cycle time is dominated by queues, not by effort.

Diagnostic: pick a recently shipped feature. Map the calendar days from first commit to production, then subtract the days anyone actively worked on it. The gap is your real problem, and hiring engineers does not shrink it.

Verification — how "done" gets decided

If there is no shared definition of done, "finished" becomes a negotiation. Work moves to done, gets contested, moves back. This appears in metrics as slow delivery when it is actually rework.

Diagnostic: how often does something marked complete return to the board within two weeks? Anything above occasional means verification is broken.

Why capacity gets blamed instead

Three reasons, and they are worth naming because they are structural rather than anyone's fault.

1. 01Engineering is the most visible part of the system. When output is low, the visible part gets blamed.
2. 02Everyone else in the process has an incentive not to identify their own step as the bottleneck.
3. 03Hiring is a legible, satisfying action. Fixing intake is unglamorous and produces no announcement.

Adding engineers to a system constrained by specification quality produces more half-defined work being built in parallel — and more rework.

A cheap test before you spend anything

Run this over an afternoon. Take the last ten things your team shipped and, for each, record four numbers: days from request to backlog, days sitting in backlog, days actively worked, days between "done" and actually live.

Then total each column. Whichever is largest is your constraint. In most teams that have never done this exercise, active work is not the largest column — and often not close.

That result is worth knowing before you write a job description. Hiring against the wrong constraint costs a year and a salary, and leaves you exactly where you started.

What fixing it usually looks like

None of these fixes require new headcount. They require someone owning the process end to end.

• Intake: a single prioritised queue with one person accountable for order.
• Specification: acceptance criteria written and agreed before work is scheduled.
• Flow: explicit limits on work in progress, and a named owner for each dependency.
• Verification: one shared definition of done, applied consistently.

These are unexciting. They are also, reliably, where the recovered time comes from.