Problem: a team’s releases take far longer than the actual work involved. Code is ready on Tuesday and reaches users the following week. The usual treatment is automation, and automation is often right. But before investing in it, a precise diagnosis of a slow release process frequently shows that the delay is not caused by missing tooling. It is caused by steps that should not exist. This article sets out a diagnostic sequence, the typical findings and the removals that follow, in the order a careful engineer would take them.
The symptom: elapsed time far larger than working time
Start by separating two quantities. Working time is the hours someone is actively doing something to a change. Elapsed time is the calendar time between “ready” and “live”. In a slow process the second is many times the first, and the difference is waiting. Waiting for a reviewer, for a window, for a meeting, for an environment, for a signature.
Automation addresses working time. It shortens the minutes a task takes. It does little for waiting, which is where most of the elapsed time sits. This is the first insight of the diagnosis: if you have not measured where the waiting happens, you cannot know whether a tool will help.
Diagnostic step 1: Trace one recent change end to end
Pick a single change that shipped recently and reconstruct its journey from timestamps: commit, review request, review complete, build, test, approval, deployment, confirmation. Write each handoff on a line with the elapsed time beside it. Do this for two or three changes of different sizes.
The output is a simple table, and it usually reveals two or three long gaps. Those gaps are your suspects. Hold off on repairs for now; at this point the job is simply to watch and record.
Diagnostic step 2: Classify each gap
For every long gap, assign one of four causes:
- Queue: the work sat waiting for a person or a shared resource that was busy.
- Batch: the work waited for other changes to accumulate before moving.
- Ritual: the work waited for a recurring event, such as a weekly approval meeting.
- Rework: the work moved backwards because something was found late.
Each class has a different remedy, and in three of the four the best remedy is removal. Queues shrink when you remove stages that need a person. Batches dissolve when you remove the rule that groups changes. Rituals disappear when you remove the meeting or replace it with a lighter check. Only rework typically needs something added, and even then it is often a smaller version of an existing test moved earlier.
Diagnostic step 3: Ask what each stage protects against
For each remaining stage, write down the specific failure it was created to prevent and the last time it caught one. Stages exist for reasons, usually an incident. The question is whether the reason still applies.
Three findings recur. First, a stage that guarded against a problem since eliminated by an architecture change. Second, a stage duplicating another, such as a manual smoke check after an automated one that covers the same ground. Third, a stage that records approval but cannot refuse, because nobody has ever declined a change at that point. The third is a ceremony. It adds elapsed time and produces a feeling of control while delivering none.
People moving into delivery roles from other backgrounds are well placed to spot these, since they often know the original reasons. If that describes you, a walkthrough for people crossing over from sysadmin and helpdesk work into delivery engineering speaks to the experience you bring when questioning inherited steps.
The solution: remove in order of lowest risk
With classified gaps and a list of questionable stages, sequence the removals from least to most risky.
- Rituals with no decision. If a recurring approval meeting has never rejected a change, replace it with an asynchronous notification and observe.
- Duplicate checks. Keep the one that is automated and fast; retire the manual twin.
- Batching rules. Allow single changes to ship independently once the earlier steps are reliable.
- Stages that protect against vanished risks. Switch them to advisory mode for a defined period, review the evidence, then delete.
Each removal should be made as a separate change, with the same elapsed-time trace repeated afterwards. If the number moves, the removal worked. If it does not, restore the stage and reconsider the diagnosis. This discipline keeps the process empirical rather than ideological.
What to do about the stages you cannot remove
Some stages are genuinely required, whether by regulation, contract or sound practice. For those, the question changes from “can we delete it?” to “can we remove the waiting around it?” A mandatory review can still be fast if reviewers have dedicated windows and the change is small. A required approval can be requested at the start of work rather than at the end, so the clock runs while development proceeds.
This is also where judgement separates experience levels. Spotting which constraints are real and which are inherited habit is a skill that develops over a career, and a map of the path from junior to senior engineer shows how that discernment tends to grow with responsibility.
A note on measuring without turning it into another burden
Diagnosis can itself become clutter if it demands a new tracking tool or a weekly report. Keep the measurement deliberately thin. Timestamps already exist in your version control system, build service and ticketing history. A one-off trace assembled from those sources is enough to begin. Only keep measuring regularly if the numbers prove useful, and retire the measurement the moment they stop informing a decision. Applying the principle of subtraction to the diagnostic work itself keeps the exercise honest.
Anticipating objections
“We added that gate after a serious incident.” Then the incident deserves a proper review: does the gate address its cause, or only a symptom? If the root cause has since been fixed, the gate is a memorial rather than a control.
“Removing a step feels reckless.” The staged approach, advisory first and then deletion, makes removal reversible. Recording each decision means the step can be reinstated quickly if evidence demands it.
“We do not have time to analyse this.” A traced change and a classified gap list take an afternoon. The elapsed time recovered in a single month usually exceeds that investment, though the exact amount varies by team.
Recording the findings
Keep a brief record of each removal: the stage, the reasoning, the evidence and the date. It protects the team against reintroduction by well-meaning newcomers. For teams that want to share anonymised lessons more widely, a blogging network such as BlogOrbix, positioned as a distraction-free destination for writers allows a blog on its own subdomain and more than one contributor, which suits a small group documenting its experience together.
Verification: how to know the diagnosis held
After the removals, repeat the end-to-end trace on fresh changes. Expect the long gaps to shrink or vanish and the ratio of elapsed time to working time to narrow. Equally important, check the downside: have defects reaching users increased? If quality indicators hold steady while waiting falls, the cuts were sound. If quality slips, identify which removal was responsible and restore only that one.
Be wary of declaring success on speed alone. A process that is fast and careless has simply moved its costs somewhere less visible.
Summary of the diagnosis
- Measure elapsed time against working time for a few recent changes.
- Classify each long gap as queue, batch, ritual or rework.
- For each stage, record what it protects against and when it last did.
- Remove from lowest risk to highest, one change at a time.
- Reduce the waiting around the stages that must stay.
- Re-trace, verify quality and document the decisions.
Automation has its place, and it works best on a process already stripped of needless steps. Automating a bad process only produces bad outcomes faster. Remove first, then automate what remains, and the tooling you eventually build will be smaller, cheaper and easier to trust.