When a team ships slowly, the cause is almost never the engineers. It is usually four or five specific pieces of friction that nobody has measured.
"The team is slow" is a symptom, and founders usually misdiagnose it as a people problem. In our experience it is nearly always a system problem: work waits in queues, changes are large and risky, deployment is scary, and nobody has numbers to argue with.
Start with four measurements
These four are well-established and, more importantly, they are diagnostic — each poor result points at a specific class of problem.
| Metric | What it exposes when poor |
|---|---|
| Deployment frequency | Batch size too large, deploys treated as events |
| Lead time for changes | Queue time — usually code review or QA waiting, not coding |
| Change failure rate | Weak testing or missing staging parity |
| Time to restore | No rehearsed rollback, poor observability |
The usual findings
Code review is a bottleneck, not a quality gate
- Pull requests are too large to review meaningfully, so review becomes approval theatre
- No expectation on review turnaround, so changes sit for days
- One senior engineer is the only approver — a queue with a single server
Deployment is an event
- Manual steps that only one person knows
- No rollback that anyone trusts, so releases get batched, which makes them riskier, which makes them rarer
- Deploys scheduled for quiet periods — a strong signal that the team does not trust the process
Work is not actually defined
- Tickets that require a conversation before anyone can start
- No shared definition of done, so work bounces between engineering and QA
- Too much work in progress — everyone busy, nothing finishing
What to change first
- Make deploys boring — automate, add rollback, practise it. Everything else improves once releasing is safe.
- Shrink batch size — smaller changes are easier to review, safer to ship, faster to diagnose.
- Set a review SLA — hours, not days, with a second approver so one person is never the bottleneck.
- Limit work in progress — finishing beats starting.
- Instrument what customers feel, so incidents are found internally rather than reported.
Speed and safety are not a trade-off in software delivery. Teams that deploy most frequently also have the lowest failure rates — because small, frequent, reversible changes are both faster and safer.
Sample work without turning metrics into rankings
Look for system constraints using comparable work items. A useful engineering audit explains waiting and rework without treating activity counts as individual productivity.
- Sample several completed changes, including an urgent fix.
- Measure queues, review cycles, handoffs and deployment friction.
- Trial one improvement with a baseline and a review date.
Frequently asked questions
How long does an engineering process audit take?
Typically one to two weeks: gathering delivery data, interviewing the team, observing an actual release, and reviewing the tooling. The output should be a small number of prioritised changes with expected impact, not a maturity-model score.
Will this tell us to adopt Scrum?
No. Methodology is rarely the constraint — queue time, batch size, and deployment risk are. Teams have shipped well under every framework and badly under all of them; changing the ceremony without changing those three things does nothing.
Our team says they need more engineers. Is that true?
Sometimes, but hiring into a process bottleneck makes things worse before better — more people producing more work-in-progress against the same review and deployment queues. Measure where time actually goes first; if most of it is queue time, hiring is not the fix.
Can we compare teams using raw delivery metrics?
Only with context about product, work type and operating constraints. Use trends to investigate bottlenecks; raw counts do not establish individual or team effectiveness.
Team shipping slower than it should?
We measure where the time actually goes and fix the top constraints — usually in weeks, not quarters.
Further reading
Postmortem Best Practices: Writing One People Actually Read
Most postmortems are archaeology: an accurate record of something nobody will change. A useful one produces a small number of things that actually get done.
MVP Technical Audit: What We Check in the First 48 Hours
Most MVP audits produce a document. A useful one produces decisions: what is on fire, what can wait, and what it costs to fix.