Why is software delivery slow—and would more engineers help?

1. Agree what “delivered” means

A team can finish implementation while the business is still waiting for a usable result. A feature may be coded but awaiting review, tested but waiting for a release slot, or deployed but unavailable to the customer until configuration and training are complete.

Choose a start and end point for the question you are investigating. A founder concerned about a customer commitment may need to examine the path from agreement to operational use. An engineering team examining its release process may use a narrower window. Label those measures clearly so they are not mistaken for the same thing.

Write down one specific concern: a type of change that repeatedly takes too long, a commitment that keeps slipping, or finished work waiting to be released. Start with that path and the people involved. A broad statement that “engineering is slow” gives the team little to investigate.

2. Follow a few real changes

Choose a small, varied selection of recent work: something routine, something delayed and something that required correction. Treat this as a way to find hypotheses, not as a statistical representation of the whole organisation. Ask the people involved to reconstruct what happened and check the account against the available records.

For each item, record when it became ready, when someone actively worked on it, where it waited, why it moved backwards and when it became usable. Include time with product, customers, suppliers and operations. Record uncertainty rather than inventing precision from incomplete ticket histories.

Then look for a repeated queue or decision. Does work accumulate before a specialist review? Does acceptance change after implementation? Is the same environment unavailable? Is a release event so expensive that changes are held until there are enough to justify it? The pattern suggests what to test next.

3. Match the response to the constraint

Different causes can produce the same visible symptom: a late roadmap item. Use the evidence to choose an intervention and be prepared to revise it. Several constraints may coexist, so decide which one most affects the outcome you are trying to improve.

Unclear priorities or acceptance

Work changes direction or is rejected after substantial effort. Agree the problem, decision owner and acceptance criteria earlier; protect the next small piece of work from avoidable priority changes.

Too much started at once

People divide attention across many unfinished items. Make commitments visible and agree which work should finish before more begins. Include support and urgent interruptions in that conversation.

A repeated dependency or approval wait

Work queues for another team, specialist or decision-maker. Test whether clearer criteria, delegated decisions, scheduled collaboration or targeted capacity would shorten the wait.

Release and verification overhead

Completed changes wait for an expensive or risky release event. Investigate what the checks establish, where confidence is missing and which steps can safely become repeatable or automated.

A sustained capacity or skill gap

Clear, valuable work waits for a capability that remains scarce even when avoidable queues and rework are addressed. A targeted hire, specialist or delivery partner may be justified.

4. Look beyond the coding stage

At Pina Vida, James joined a multi-year modernisation programme where changes could be written, tested and then shelved for months. A deployment slot needed project-manager sponsorship. Each release involved overnight opening of specialist facilities, security cover and overtime for engineers and testers.

He prioritised understanding why on-site verification was required, building confidence through automated verification and moving towards smaller, more frequent releases. Verification eventually became fully remote. Releases moved from roughly quarterly to weekly, sometimes more often, with approximate savings of several thousand pounds per release.

The team also spent less time revisiting old work, repeating checks and switching context. These outcomes are based on James’s first-hand account of a hands-on engagement and shared team contributions. The example shows why the investigation needs to reach beyond development; it does not establish the cause of delay in another business.

5. Test an improvement you can learn from

Choose a bounded intervention that addresses the observed constraint. Name the owner, the work it applies to and the evidence you expect to see. Keep the change small enough to understand what happened, while making it representative enough to test the real problem.

Suppose completed changes repeatedly wait for one reviewer. An illustrative experiment could reserve review capacity and agree criteria for a narrow class of changes. Track the queue, corrections and operational outcomes before and during the trial. Record changes in demand or work mix that make the comparison less reliable.

Agree when to review the trial and what would make you stop, adapt or extend it. If a queue shrinks but failures or repeated work grow, investigate before declaring improvement. If the delay moves elsewhere, follow the work again; increasing one stage’s output does not guarantee faster completion overall.

6. Use measures to support the conversation

For the chosen path, watch elapsed time, time waiting, repeated work and operational quality together. Show the spread and the unusual items as well as a typical value. A few easy changes can improve an average while the commercially important work remains blocked.

Discuss the information with the people doing the work. Use it to investigate the delivery system and compare a team’s own progress in context. Individual ticket counts, lines of code or comparisons of story points across teams can distract from whether useful work is reaching customers.

DORA’s delivery metrics focus on software delivery outcomes and are best applied to an application or service. They can complement your investigation, but a delivery metric with a defined engineering boundary does not capture every delay from a business request to customer use.

7. Decide where additional people would help

Make the hiring case specific. Identify the work that is waiting, the capability required and why current capacity cannot meet the continuing demand. Explain who will onboard the person, what decisions they can make and whether the downstream process can absorb the additional output.

Adding capacity is more credible when priorities are clear, the work is ready and the constraint genuinely sits in that capability. It may also be the right immediate action where a critical operational responsibility lacks cover. Include the time existing staff will spend onboarding and supporting the new person.

If the evidence instead shows unresolved approvals, repeated scope changes or a release queue, fund a response to those constraints and reassess capacity afterwards. Your next decision should specify the intervention, owner, expected effect and review point. That gives both the business and the team a way to learn whether the change is helping.