Day 112: Error budgets in decisions
Using the error budget from Day 108, in practice
An error budget is only useful if it actually informs decisions. In practice: if the budget is healthy (mostly unspent), the team can ship a risky feature or run a bigger-than-usual chaos experiment. If it's nearly exhausted, the team explicitly deprioritizes new features in favor of reliability work — and this trade-off should be visible and agreed upon, not decided ad hoc by whoever is most anxious that week.
The cultural shift this enables
Without a quantified budget, 'should we slow down and focus on stability?' is a subjective, often political argument. With one, it's closer to a shared, visible number both engineering and product can look at together — reducing (not eliminating) the friction between shipping speed and reliability.
Key terms
- Error budget policy
- A team's agreed rule for what happens (feature freeze, extra caution) when the error budget nears exhaustion.
What is the practical purpose of having an explicit, agreed-upon error budget policy?
