Your development team is slowing down: look at what it is waiting for

A ticket is started and finished on a Tuesday. The review happens on Thursday: the reviewer was busy. The team deploys on Tuesdays, so the change reaches production the following Tuesday. One day of work, one week of delay. Double your developers’ speed and you save half a day. The change still ships the following Tuesday.

The example is fictional; the mechanism is not. When I investigate why a team is slowing down, I start with what it is waiting for. In this case: a review, an approval, a release slot, the availability of the one person who knows that module. And the most common reaction to a slowdown, hiring, feeds that waiting.

I understand the reflex. A late feature is visible; the waiting that produced it is not. A founder sees a team of six delivering like a team of three, and the only action he can take alone, without opening the code, is to add a person.

Now look at what a newcomer does in their first months. They ask their questions of the people everyone already turns to. They write code that must be reviewed by the reviewer who is already behind. They wait for the same release slot. You have added work to the bottleneck without widening it. If the role does not relieve that bottleneck, completing onboarding will not be enough to increase delivery throughput. If you must hire anyway, do it in small rounds, with onboarding prepared.

The slowdown is in everything around the ticket: the review, the fix after a failed deployment, the interruptions the expert absorbs, the meetings that chop up the day. None of that shows up in an estimate. All of it shows up in the delivery date.

Take a few weeks, a stable scope, tickets that shipped normally as well as late ones. And separate working time from elapsed time: a ticket open for ten days is rarely ten days of development. It is one day of development and nine days of waiting.

Symptom	Where to look	What I suspect
Code finished, delivery late	Review, approval and deployment dates of the same tickets	Review queue or infrequent release slot
Tickets reopened after delivery	Reopening reasons, linked incidents	Unclear criteria, critical paths without tests
One person blocks several projects	What waits while they are away	Knowledge too concentrated
Much started, little finished	Who interrupts, and why	Too much work in progress
A newcomer takes long to contribute	Access, setup, first deployment	Incomplete handover
The team delivers but is burning out	Meetings, unusual hours, departures	A pace that will not last

The symptom I meet most often is the third: one person everything goes through. I do not infer bad will: I look at their workload and the role they are being offered after the handover. You will not fix that by instructing them to document, but by giving them something else to carry. And do not remove a slow review before you know what it protects: you would be moving the problem into production.

To get past impressions, there is a public framework. The DORA metrics guide, from DevOps Research and Assessment, keeps five: change lead time from commit to production, deployment frequency, failed deployment recovery time, the change fail rate and the deployment rework rate. These metrics describe delivery speed and stability; they do not count development hours. A team that deploys once a month with three weeks between commit and production has a waiting problem, however talented its developers.

The team health radar follows the same two-part reading, pace and stability. Two questions cover deployment frequency and recovery time directly, using the levels of the 2024 Accelerate State of DevOps report; two others come close, including the time from ticket to production, which starts earlier than change lead time: it includes the waiting before the first line of code. Precisely the waiting you care about.

Two caveats. The radar’s answers are self-reported ranges, not values pulled from your tools. And the guide warns: these metrics apply to an application or service, in its context. They help track its progress, rather than set teams in competition; comparing very different applications can mislead. Turning the metrics into targets can also encourage people to optimise the figures rather than the work. A team told to deploy more often will deploy more often. That is not the same as delivering more.

Ask your team why the last feature took two months, and ask yourself the same question, separately. You will see the date promised and the date met. They will see the specification changed twice, the review that waited a week, the approval that arrived on a Friday evening. Nobody is lying. You are not looking at the same part of the ticket.

That is what the comparison in the team health radar is for: each side answers without seeing the other, then you lay the two radars side by side. It is not a verdict, not a ranking of developers, not a DORA measurement. It is an excuse for a conversation nobody dares to open, with a precise gap to explain. For each gap, go back to a trace: a finished fix waiting to be shipped is organisational debt; an automation held back because a decision never arrives is autonomy debt.

Do not launch five initiatives. Take the bottleneck that explains the most waiting work and deal with it alone: spread the reviews, write down the critical path, clarify one approval, cap the tickets in progress. One owner, one review date, a snapshot of the situation before. At the review, look at lead time and stability together: a ticket shipped faster but followed by an incident is not progress, it is displacement.

Before deciding which role to hire for and when the person should start, I would check whether that role will relieve the observed bottleneck. Someone able to share the review workload may help where an additional developer would wait for the same approvals. Interviews can proceed during that investigation; what needs clarifying is the expected effect of the hire. When an outside eye helps to see the bottleneck the team no longer sees, that is the point of the technical and organisational diagnostic; the team organisation situations describe what I work on.