# Delivery Performance Report — Sample **This is an illustrative example.** The teams, numbers and incidents below are invented to show the shape of a report that leads somewhere. Copy the structure, not the figures. A delivery report exists to answer one question: *is the distance between a change and a customer getting shorter?* Everything below serves that. Output measures — story points, tickets closed, commits — are deliberately absent, because they can improve while delivery gets worse. --- ## Engineering delivery — July 2026 | | | |---|---| | Period | 1–31 July 2026 | | Teams | Payments, Catalogue, Platform | | Source | Deployment log and incident record — no new tooling | | Prepared for | Engineering leadership, monthly | ## 1. The four measures | Measure | Payments | Catalogue | Platform | June, all teams | |---|---|---|---|---| | Deployments per week | 11 | 2.5 | 0.8 | 3.9 | | Lead time, merge to live | 6 hours | 3 days | 11 days | 4 days | | Change failure rate | 9% | 21% | 33% | 18% | | Time to restore | 22 min | 4 hours | 2 days | 6 hours | Read the rows together. **Payments deploys most often and breaks least often** — the relationship that surprises people who assume frequency and risk move together. It does not happen by luck: frequent deployment forces small changes, and small changes are easier to verify, easier to review and far easier to reverse. ## 2. Platform needs attention, and not the kind it is asking for Platform's numbers are the worst on every row. The request currently on the table is more staff. The record does not support that as the first move. | Where Platform's 11-day lead time goes | Median | |---|---| | Merge to build complete | 40 min | | Waiting for a shared test environment | 4 days | | Manual regression pass | 2 days | | Waiting for the Thursday release window | 3 days | | Deploy and verify | 90 min | **Under two hours of the eleven days is work.** The rest is waiting — for an environment, for a manual pass, for a window. Adding people to a queue makes the queue longer. The two-day time to restore has a single cause, stated plainly in the incident notes: the rollback procedure has never been run, and the last two attempts to use it failed because the previous artefact had been cleaned up. ## 3. Incidents | | Count | Notes | |---|---|---| | Customer-affecting incidents | 6 | Down from 9 in June | | Caused by a deployment | 4 | All 4 in teams deploying less than weekly | | Caused by a dependency | 2 | One upstream provider, one certificate expiry | | Resolved by rollback | 1 | The only one under 30 minutes | The certificate expiry is worth naming because it is entirely preventable and recurred: it is the third expiry-related incident this year, and there is still no expiry monitor. ## 4. What changed this month - Payments moved to **build once and promote**, removing per-environment rebuilds. Lead time fell from 2 days to 6 hours in three weeks. - Catalogue added a **post-deploy verification step**. Two bad releases were caught before traffic reached them; neither appears in the incident count above, which is the point. - Platform's improvement work was **deferred again** for delivery commitments — the third consecutive month. ## 5. The uncomfortable observation Catalogue's change failure rate rose from 16% to 21% this month, and it is the healthiest signal in the report. The team started deploying more often — 1.1 to 2.5 per week — and more deployments surfaced problems that were previously batched, hidden and attributed to something else. Their time to restore fell from 9 hours to 4 in the same period. **More failures, resolved faster, is the better position.** A report that only tracked failure rate would have recorded this as a regression and pushed the team back toward large, infrequent, terrifying releases. ## 6. Recommendations 1. **Give Platform an ephemeral test environment**, created from code per change. Removes 4 days of the 11 and needs no additional staff. 2. **Test Platform's rollback on an ordinary Tuesday**, with the artefact retention it depends on. This is the two-day restore time, and it is a half-day of work. 3. **Retire the Thursday release window** for changes that pass verification. It exists because rollback is not trusted; fix that and the window has no purpose. 4. **Add certificate expiry monitoring.** Third occurrence, entirely preventable. 5. **Do not add staff to Platform this quarter.** Revisit once queue time is out of the lead time, when the measurement will mean something. ## 7. Next month Report the same four measures. Add cost per deployment for the teams now deploying daily, and split lead time into work and wait for every team — Platform's split was the most useful number in this report and the other teams do not have it. --- ## Notes on using this format **Four measures, no output metrics.** The temptation is to add velocity or ticket counts. They answer a different question and they dilute this one. **Split lead time into work and wait.** It is the single most persuasive table here, because it turns "we need more people" into "we have a queue", and those have different remedies. **Report the uncomfortable observation.** A rising failure rate that reflects more frequent deployment is good news that looks like bad news. If the report cannot say so, it will drive the behaviour it exists to prevent.