Your team has finished coding a feature, yet the customer still cannot use it. The change is waiting for review, another test run or a release decision. Another developer might help with the next feature. Will that hire move this one through the queue?
Before opening another general developer role, trace a few changes from a clear request through to customer availability. Find the step that holds up delivery, then decide whether it needs more capacity, smaller changes or a decision someone has not made.
Eight working days for a small feature
Consider a fictional SaaS team adding a CSV export. This is a simplified diagnostic example, not a client story, benchmark or tested improvement.
The change moves through four sequential stages:
- Implementation takes two working days.
- It waits three working days for review.
- Review and testing take one working day.
- It waits two working days for release.
That is eight working days, including five spent waiting. Assume that deployment and customer availability happen together at the end of the final stage. The example excludes weekends and overlapping activity.
Even if coding took less time, those five waiting days would remain unless something changed downstream. They are arithmetic for this example, not a forecast of recoverable time. The review may be waiting for an available engineer, missing test evidence or a decision about the export's permissions. Each cause needs a different response.
The three days in implementation, review and testing describe elapsed stage time. They do not establish three person-days of labor. A ticket can sit in a stage while its owner attends to other work.
For this team, I would inspect the review wait first. I would ask the developer and reviewer what prevented the review from starting, then check whether other changes show the same pattern.
Trace shipped work and work that is still waiting
Choose one product or service and a few changes with similar scope and risk. Include recently shipped changes and unfinished ones, especially work that has been waiting a long time. Looking only at completed tickets leaves those outstanding delays out of the diagnosis.
Bring together the people who request, build, review, test and release the changes. Walk through what happened using tickets, pull requests and deployment records. Where a timestamp is missing, record it as unknown or label the team's estimate. A precise-looking board history is not useful if its statuses were updated late.
DORA's value-stream mapping guide recommends mapping delivery steps, handoffs and waiting time, then testing an improvement against a specific outcome. A simple shared map is enough to begin; you can investigate a troublesome step in more detail once you know where it is.
Use this short worksheet for each change:
- Record the change, the customer outcome and the date the request was clear enough to start. Note the agreed scope and acceptance conditions.
- Mark when coding started, when the change was ready for review and when review actually started. Keep separate timestamps for test-ready and test-start when testing has its own queue.
- Record release-ready, production deployment and customer availability separately. A feature behind a disabled flag, or in a limited rollout, may be deployed before the intended customers can use it.
- For each wait, name the next action, its owner and the blocker. Record approvals, external dependencies, missing information and priority changes. Preserve each return for correction instead of replacing the original dates.
- For unfinished work, record its current stage and how long it has been there as of the review date. Leave future completion times blank.
- Note rework, failed releases and recovery alongside elapsed delivery time. Add labor effort only when you have separate evidence for it.
Define the boundaries consistently. For example, "ready for review" should mean the reviewer has the change and the evidence needed to examine it. Otherwise, the same label may cover both incomplete preparation and a reviewer queue.
Do not add overlapping intervals as though they happened one after another. Keep the working-day convention consistent, and check the recorded reason before labeling an entire interval as waiting.
Choose the fix that matches the delay
Changes wait for review
Check whether reviewers have time reserved, whether the change is small enough to understand, and whether its author supplied context and test evidence. A reviewer shortage and an incomplete handoff can look identical on a board.
If availability is the repeated problem, try protecting review time. If each review requires understanding several unrelated changes, split future work into smaller, independently reviewable pieces where that is safe. A split should still make sense to test and release; creating more tickets does not resolve a coupled change.
Testing repeatedly sends work back
Read the reasons for the returns. Are acceptance conditions unclear? Does the test environment differ from production? Does a change in one component break another?
Choose a response to the observed cause: clarify the expected behavior before coding, improve a missing test or investigate the dependency. More implementation capacity will not settle an unresolved product decision. If the testing queue itself lacks capacity, that may justify additional people or specialist support.
Release-ready changes sit in a queue
Identify what the release is waiting for and what risk that step controls. A required security review, a coordinated migration and a manual deployment task are different constraints.
Keep necessary security and compliance checks. Look for preparation that can happen earlier, clearer approval ownership, or repeatable release work that can be automated safely. If several changes must ship together because of a shared dependency, investigate whether that coupling can be reduced. Some migrations will still need coordination.
An architecture review can be useful when the repeated delay crosses system boundaries and the team needs to understand that dependency before changing it.
Work keeps losing its place
When priorities change mid-flight, record what was paused and who authorized the new work. Count production support and incident work too. Otherwise, the map may suggest idle capacity that the team never had.
Try completing a smaller set of agreed priorities before starting more. DORA's guidance on work-in-process limits supports making work visible and matching concurrent work to capacity, including support and other commitments. It does not give every team the same suitable limit.
Implementation capacity is the constraint
Hiring deserves serious consideration when well-defined, ready work repeatedly waits for skills or time the team does not have, while downstream capacity can handle the additional work. Persistent on-call demands or a missing specialist can make that shortage more urgent.
Describe the role in terms of the constraint it should address. That might be implementation capacity, release engineering, testing expertise or someone able to share a specialist review load. Also identify who will onboard the person and what work that takes from the current team.
A few tickets can suggest a hiring hypothesis. They cannot establish a permanent bottleneck, justify a blanket hiring freeze or rank individual developers. DORA's work-visibility guidance warns that improving a step outside the bottleneck may do little for overall delivery time. Check the whole path before committing substantial effort to one part of it.
Run one bounded experiment
Suppose the trace shows that comparable changes repeatedly wait for an available reviewer. For the next two working weeks, assign a reviewer and backup to a protected daily review slot for that service. Keep the review requirements intact. This is a proposed experiment, not a tested prescription.
Record review-ready and review-start for every eligible change, including those still waiting at the end. Compare the waits with the earlier, comparable work. Check whether delay moved into testing or release, whether corrections increased, and what the review slot displaced from the reviewers' other commitments.
Track customer availability as well as deployment. Review any failed deployment and the time needed to recover. DORA's delivery-metrics guide, updated January 5, 2026, uses five metrics and recommends assessing one application or service in context. Its change lead time starts at a code commit and ends at production deployment. The request-to-availability worksheet here has wider boundaries.
At the end of the experiment, decide whether to keep the slot, change it or investigate a different cause. Fewer comparable changes or unusual incident work may leave the result inconclusive. A shorter review queue is useful only if the overall path improves without unacceptable quality problems or displaced work.
Use any evidence of a remaining capacity shortage to define the hire. When the decision spans staffing, priorities and ownership, a fractional CTO can help a founder work through it.