Accelerate: four metrics FDEs can use to measure software delivery speed and stability
First published in 2018, the book by Nicole Forsgren, Jez Humble and Gene Kim gives you hard numbers for the question clients ask most often: how fast and how reliably does our team get changes into production?
In brief
- Accelerate (IT Revolution, 27 March 2018) draws on four years of research using data from the State of DevOps reports.
- The four metrics are deployment frequency, lead time from commit to production, the rate of deployments that cause failures, and time to restore service.
- DORA now splits its metrics into a throughput group and an instability group, and has added deployment rework rate to make five.
Put the two columns side by side so no one can show off speed while hiding what the incidents cost.
Graphic: FDE Times
Many client meetings get stuck on the same complaint: “Our team deploys too slowly.” Slow compared with what? How slow? Nobody in the room has a number. Accelerate teaches you to turn that complaint into four numbers anyone can check.
The authors are Nicole Forsgren, Jez Humble and Gene Kim. The subtitle promises a scientific approach to Lean and DevOps for building and scaling high-performing technology organisations. IT Revolution published the book on 27 March 2018, and it won the Shingo Publication Award.
For an FDE, the book’s value lies not in its age but in the skill it builds: measuring an organisation’s software delivery capability before recommending anything. You are on the client’s site, and the first question is always where their team stands today.
What data is the book built on?
According to IT Revolution’s description, the book is the product of four years of research using data collected for the State of DevOps reports. The publisher promises that readers will learn how to measure their team’s performance and which capabilities to invest in.
Behind those numbers is DORA, a multi-year research programme run to academic standards. As early as its 2015 report, DORA found that high-performing IT organisations far outpaced their competitors on four key software delivery metrics. Accelerate tells the story of those findings in book form.
Four numbers, tried on a real client
Google Cloud, introducing DORA’s “Four Keys”, defines the metrics as follows. Deployment Frequency is how often an organisation successfully releases to production. Lead Time for Changes is the time it takes for a commit to get into production.
Change Failure Rate is the percentage of deployments that cause a failure in production. Time to Restore Service, also called MTTR, is how long it takes an organisation to recover from a failure in production.
Imagine you have just arrived at a logistics company. Over 30 days, their team made 20 successful production deployments. Deployment Frequency is 20 per 30 days, or on average one release every day and a half.
Three of those 20 caused incidents, so Change Failure Rate is 3/20, or 15%. Do not measure lead time on a single commit: calculate it for each change and take the median. Say the median comes out at about four days, meaning a typical commit written on Monday morning reaches customers on Friday afternoon.
Time to restore works the same way. The three incidents took 30 minutes, 1 hour and 6 hours. The median is 1 hour and the mean is 2.5 hours; using the 6-hour case alone as “time to restore” paints the client’s team as worse than it is. The worst case deserves to be told as a story of its own, not reported as the metric.
With those four numbers, the meeting changes character. Instead of “deploys are slow”, you say “a typical commit takes four days to reach customers, and 3 in every 20 deployments cause an incident”. That is a problem you can scope, not a feeling.
Three ideas to take to the client’s site
The first lesson is simple: measure first, then recommend. The book’s promise is to help you know which capabilities to invest in, and that only holds if you have baseline data. On site, the first job is to get the deploy log and the incident history, not to start debating tools.
The second idea comes from how DORA now organises its metrics: one group shows the throughput of software changes, the other shows instability. Reading both groups together keeps you out of a familiar trap: increasing the number of deployments and declaring victory while the incident rate climbs too.
The last idea is a shared language with management. IT Revolution says plainly that the book is ideal for managers at every level. FDEs often have to persuade both the CTO and the head of operations, and the four metrics are something both sides can read without an explanation of the architecture.
Why open dora.dev before opening the book?
“Four metrics” is a 2018 figure. DORA has since expanded to five metrics, adding deployment rework rate. If you quote the book in a client meeting without knowing this, a careful listener will catch the error at once.
So the sensible order is to read the “DORA metrics: the four keys” page on dora.dev first, to get the current definitions. Then read Accelerate to understand why these numbers can be trusted. Finally, read Google Cloud’s post “Using the Four Keys to measure your DevOps performance” to see how measurement is done in practice.
The book suits developers with two to eight years of experience who are comfortable with CI/CD but have never had to explain to non-technical people why the pipeline matters. If you are aiming for an FDE role, this is the step from someone who “knows how to deploy” to someone who “can measure an entire organisation’s ability to deploy”.
Real logs are never clean: an exercise
Deploy logs on a client’s site are rarely as tidy as the example above. Below is a hypothetical week of logs, deliberately messy. Work out all four metrics yourself before reading the answer below.
| Deploy time | Environment | Result | Earliest commit | Notes |
|---|---|---|---|---|
| Mon 09:10 | production | success | Sun 22:00 | — |
| Mon 09:12 | production | success | Sun 22:00 | job re-run, duplicate build |
| Tue 14:00 | staging | success | Tue 10:00 | — |
| Wed 16:30 | production | failed in pipeline | Wed 11:00 | never reached production |
| Wed 17:45 | production | success | Wed 11:00 | caused an incident, restored 18:30 |
| Fri 10:00 | production | success | Thu 15:00 | — |
Answer: clean first, calculate second
The cleaning step decides everything. Drop the duplicate re-run, drop staging, and drop the pipeline failure because it never reached production. That leaves 3 successful releases, so deployment frequency is 3 per week.
One of the three caused an incident, so the change failure rate is 1/3, about 33%. The lead times of the three are 11 hours 10 minutes, 6 hours 45 minutes and 19 hours, giving a median of 11 hours 10 minutes.
Time to restore is 45 minutes. If you mistakenly count 6 deployments, frequency doubles, the failure rate drops to about 17%, and the client’s team looks twice as stable as it really is.
Turn it into an edge when job hunting
When reading FDE or solutions engineer job descriptions, look for phrases such as “deployment”, “time to production” or “measuring delivery effectiveness”. They signal that the employer wants someone who can talk in numbers.
On a CV, a line like “cut median lead time from commit to production from four days to under one day” carries far more weight than “experienced in DevOps”. The numbers must be your own, measured on a real project, and you must be able to explain how you cleaned the log when asked.
Accelerate does not teach you to write any particular pipeline. It teaches you to walk into an unfamiliar organisation and know within the first week where it stands, which is exactly what clients pay FDEs to bring.