Reporting and culture
Making SLOs visible — reviews, release freezes, and reliability as a shared product concern.
SLOs fail quietly when they live only in a monitoring tool nobody opens in planning.
Make status obvious
Show current SLI, remaining error budget, and burn on a team dashboard and in release reviews. If product managers never see budget, they cannot trade features for reliability.
Regular reliability review
A short recurring review: budget spend, top burn incidents, SLO changes proposed, reliability backlog progress. Keep it factual — not a blame session.
Tie to shipping
When budget is low, change the default: smaller releases, more canaries, reliability-themed sprints. When budget is healthy, say so — fear without data is also costly.
Blameless use of numbers
SLOs measure systems and processes. Use them to prioritize fixes and improve design. Using them as individual performance weapons destroys honest reporting.
Document for the next incident
Link each SLO to runbooks, owners, and dashboards. New on-call should find “what is red and what do I do” without archaeology.