Why does working with SLOs and an error budget make delivery cheaper and faster than aiming for perfection?

It removes the pressure to be perfect. Every extra "nine" of reliability costs much more, so a team that only has to meet an agreed target can spend the remaining budget on shipping changes.

* Each extra nine leaves ten times less room for failure: from 7.2 hours a month down to 26 seconds. *

Reliability gets more expensive with every nine. Going from 99% to 99.9% is hard, and going from 99.9% to 99.99% usually needs redundant sites, slower release processes and much more testing. Users often cannot even tell the difference, because their own network or device fails more often than that.

The error budget turns reliability into a resource to spend:

• Budget left: the team may release faster, run experiments and take risks.
• Budget used up: releases slow down or freeze, and the effort goes into stability.

This also defuses the Dev versus Ops conflict. Instead of developers wanting change and operations wanting none, both sides look at one shared number and agree on what happens next. The method can therefore steer the pace and scope of development so that it stays appropriate to what the business really needs.

Go deeper:

• Google SRE book — Embracing Risk — the cost of each nine and the error-budget mechanism.
• Google SRE workbook — Error Budget Policy — a real policy: what happens when the budget is spent.