When Releases Slip — Is It The Team, The Code, Or The Disease?

It always starts the same way. A date that was committed in a board deck quietly becomes a date with an asterisk. The asterisk becomes a "revised timeline." The revised timeline becomes a story about the team — they're not senior enough, they're not moving fast enough, they don't have enough urgency. By the time it reaches the CEO, the diagnosis is already written: we have a delivery problem, and the team is the cause.

In a decade of looking under the hood of growth-stage companies, this is one of the most consistent — and most expensive — misdiagnoses I encounter. The instinct to blame the team feels intuitive, because the team is what the CEO can see. The architecture is invisible. The deployment pipeline is invisible. The operating cadence that decides what gets built is invisible. So the visible thing takes the blame.

The problem is that you cannot fix an invisible disease by replacing the visible people. New people inherit the same broken system and slow down inside it just as the last ones did. So before you reorganise, replace a leader, or "raise the bar," it's worth asking the harder question: is this effort, or is this a disease?

Three diseases hide behind one symptom

Slipping releases is a symptom — a single visible signal. Underneath it usually sit one or more named diseases from very different families. Treating them as the same thing is how companies spend a year fixing the wrong layer.

• Architecture coupling (Family F03). When components are tangled together, a change in one place forces changes — and re-testing — everywhere else. Teams aren't slow; the system makes every small change expensive. Velocity drops as the codebase grows, which is the tell that this is structural, not human.
• Weak delivery and DevOps (Family F04). Manual deployments, flaky tests, long-lived branches, no real CI/CD. The work is done, but getting it safely to production is a high-friction ritual. Releases batch up, risk concentrates, and every launch becomes an event instead of a routine.
• A broken operating model (Family F06). Priorities change weekly. Three stakeholders each believe they own the roadmap. Decisions take days to make and are then re-litigated. The team ships less not because they're slow, but because they're constantly redirected.

These look identical from the boardroom — releases are late — and demand completely different treatments. Replacing engineers does nothing for any of the three. That is why naming the disease matters more than naming a culprit.

How to tell the difference

You don't need to read code to distinguish these. You need to read the pattern. A few questions usually separate them quickly:

• Does velocity fall as the codebase grows? If small features now take far longer than they did two years ago, you're likely looking at architecture coupling, not a motivation problem. Effort is being consumed by the system, not the scope.
• How long from "code complete" to "live in production"? If the work finishes on time but sits in a queue for days waiting on manual testing, approvals and a risky deployment window, the disease is in delivery and DevOps — not in the people who wrote the code.
• How often does the plan change after work has started? If teams are routinely told to drop what they're doing, the slip is an operating-model disease. No amount of individual talent survives constant context-switching.
• Do different functions blame each other? Engineering blames product for shifting scope; product blames engineering for slow delivery; both blame "the team." When everyone is partly right, the disease is almost always the system that connects them, not any one group inside it.

If a new hire would slow down inside the same system, the system is the disease — not the person you were about to replace.

Why firing the wrong cause is so costly

Replacing people to fix a structural disease is the most expensive treatment available, and it rarely works. You lose institutional knowledge, you spend months recruiting and onboarding, and the new arrivals walk into the exact same coupling, the same pipeline, the same chaotic cadence. Six months later the releases are still slipping, the conclusion is "we hired wrong again," and the real disease has compounded the whole time.

Meanwhile the genuine fix — decoupling a few high-traffic seams, building a real deployment pipeline, or installing clear decision rights and a stable planning cadence — was almost always cheaper, faster and more durable than the reorganisation. The treatments aren't exotic. The hard part is correctly naming which disease you have before you spend.

This is why a real disease-led diagnosis looks at the whole chain — architecture, delivery, and operating model together — rather than stopping at the first plausible story. Symptoms point in many directions at once. The diagnosis is the discipline of connecting them to one named root cause.

What a CEO should actually ask

The next time a release slips, resist the reflex to ask "whose fault is this?" Ask instead:

• Is this slip the same shape as the last three slips? Repeated patterns are diseases, not accidents.
• Where exactly does the time go — building, testing, deploying, or waiting for decisions? Each answer points at a different family.
• If I replaced the team tomorrow, would the new team move faster inside this system? If the honest answer is no, stop talking about the team.

Slipping releases are real, and they deserve a real response. But the response that works is the one aimed at the disease, not the one aimed at the people standing closest to the symptom. Name the disease first. Then the treatment — and the cost — finally makes sense.